On Fri, Feb 17, 2017 at 6:46 AM, tom p. <daedulus@xxxxxxxxxxxxx> wrote:
From: <otroan@xxxxxxxxxxxxx>
To: "james woodyatt" <jhw@xxxxxxxxxx>
Cc: <draft-ietf-6man-rfc4291bis@ietf.org >; "6man WG" <ipv6@xxxxxxxx>;
"IETF-Discussion Discussion" <ietf@xxxxxxxx>; <6man-chairs@xxxxxxxx>
Sent: Friday, February 17, 2017 7:44 AM
> James,
>
> 4291:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.
>
> 4291bis:
> IPv6 unicast routing is based on prefixes of any valid length up to
> 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes
> on inter-router point-to-point links. However, the Interface ID of
> all unicast addresses, except those that start with the binary
value
> 000, is required to be 64 bits long. The rationale for the 64 bit
> boundary in IPv6 addresses can be found in [RFC7421]
>
> Proposal:
> IPv6 unicast routing is based on prefixes of any valid length up to
> 128 bits [BCP198]. However, as explained in [RFC7421], the Interface
ID
> of unicast addresses is generally required to be 64 bits in length,
with
> exceptions only provided in special cases where expressly
recognised
> in IETF standards track documents.
>
> I think that's a good proposal.
> Perhaps with s/is generally required to be/are/
Ole
I would go further on the grounds that this is still somewhat woolly. I
would say
Proposal':
IPv6 unicast routing is based on prefixes of any valid length up to
128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID
of unicast addresses is required to be 64 bits in length; any
exceptions
must be specified in IETF standards track documents.
It would be nice to have something IANA-like with different categories
of what can update what, with this being at the higher level, the bar
set higher for an Interface ID that is not 64 bits in length, but when
we say 'standards track' we are calling for IETF consensus and IESG
approval and it is hard to see what more could be called for, unless we
say that this is architectural and so the IAB must approve it!
I don't think the intent of that language is to define or constrain our processes. As I see it, the purpose of that text is to make it clear the IID length is and has always been a parameter, which operators are constrained by this text to to set at 64 bits, but this value cannot be embedded as a magic value in code, because there are cases where its not 64 bits, even beyond addresses that start with 000.
I'll conceded, whether 64 bit boundary is a requirement, or more appropriately a recommendation, is probably beyond the scope of a bis document. However, clarifying who the requirement is directed at, is most certainly within scope and I think imperative. I have never heard anyone claim this requirement is to be put in code, in fact quite the contrary, everyone seem to agree it should NOT be put in code, and therefore by reduction it is intended to be an operational constraint. Or in other word, the requirement is primarily directed at operators of IPv6 networks, and not implementers of IPv6.
The following takes the essential text from from RFC4291, rearranges it a little and wraps it with clarifying language, which is what we should be doing in a BIS document. Now those of us that want more significant changes, it's incumbent on us to write standards track documents, and get consensus for them, like it has always been. But in the mean time implementations are put on notice that 64 bit boundary is primarily an operational constraint and not something that can safely be embedded in code.
So I suggest the following;
IPv6 unicast routing is based on prefixes of any valid length up to 128
[BCP198]. However, as discussed more thoroughly in [RFC7421], the length
of the Interface ID is a parameter, that is required to be 64 bits for
all unicast addresses, except those that start with the binary value 000,
with additional exceptions provided in other standards track documents.
Other than it's implications to Stateless Address Autoconfiguration(SLAAC)
[RFC4862], this requirement's primary effect is operational, as
implementations of IPv6 must not ignore or override the local
configuration of this parameter, even if it conflicts with this
requirement. The rationale for the 64 bit boundary in IPv6 addresses
can be found in [RFC7421].
However, the text we have been discussing is the second paragraph of section 2.4 of the draft, but if preferred these last two, sentences could be broken out and integrated in section 2.4.1
Leaving the second paragraph of 2.4 something like this;
IPv6 unicast routing is based on prefixes of any valid length up to 128
[BCP198]. However, as discussed more thoroughly in [RFC7421], the length
of the Interface ID is a parameter, that is required to be 64 bits for
all unicast addresses, except those that start with the binary value 000,
with additional exceptions provided in other standards track documents.
With the forth paragraph of 2.4.1 something like this;
As noted in Section 2.4, the length of the Interface ID is a parameter,
IPv6 unicast routing is based on prefixes of any valid length up to 128
[BCP198]. However, as discussed more thoroughly in [RFC7421], the length
of the Interface ID is a parameter, that is required to be 64 bits for
all unicast addresses, except those that start with the binary value 000,
with additional exceptions provided in other standards track documents.
Other than it's implications to Stateless Address Autoconfiguration(SLAAC)
[RFC4862], this requirement's primary effect is operational, as
implementations of IPv6 must not ignore or override the local
configuration of this parameter, even if it conflicts with this
requirement. The rationale for the 64 bit boundary in IPv6 addresses
can be found in [RFC7421].
However, the text we have been discussing is the second paragraph of section 2.4 of the draft, but if preferred these last two, sentences could be broken out and integrated in section 2.4.1
Leaving the second paragraph of 2.4 something like this;
IPv6 unicast routing is based on prefixes of any valid length up to 128
[BCP198]. However, as discussed more thoroughly in [RFC7421], the length
of the Interface ID is a parameter, that is required to be 64 bits for
all unicast addresses, except those that start with the binary value 000,
with additional exceptions provided in other standards track documents.
With the forth paragraph of 2.4.1 something like this;
As noted in Section 2.4, the length of the Interface ID is a parameter,
that is required to be 64 bits for all unicast addresses, except those
that start with the binary value 000, with additional exceptions
provided in other standards track documents. Other than it's
implications for Stateless Address Autoconfiguration(SLAAC)[RFC4862],
this requirement's primary effect is operational, as implementations
of IPv6 must not ignore or override the local configuration of this
parameter, even if it conflicts with this requirement. The rationale
for the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
this requirement's primary effect is operational, as implementations
of IPv6 must not ignore or override the local configuration of this
parameter, even if it conflicts with this requirement. The rationale
for the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
Thanks
Tom Petch
> Best regards,
> Ole
>
>
===============================================
David Farmer Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
David Farmer Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
==============================