Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[David Farmer <farmer@xxxxxxx>]

I had an epiphany this morning and I have to jump back to Brian's proposed text. 

On Wed, Feb 15, 2017 at 3:34 PM, <otroan@xxxxxxxxxxxxx> wrote:

>> Do you think this change is appropriate in the context of advancing 4291?
>
> I don't think I have suggested text that would lead to a single instruction in
> running code being changed.

CURRENT (RFC4291bis):

   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]

PROPOSED:

    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 unicast
   addresses used for Stateless Address Autoconfiguration [RFC4862] is required
   to be 64 bits long. The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]


My reading of the proposed text, which certainly may be wrong, given that English is not my first language, is that it leaves the Interface-ID length of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any other way to interpret this sentence?

I would add ", in all other cases it is recommended to be 64 bits long."  

 

The proposed text appears to make the Interface-ID length an operational choice.
How is that _not_ changing the 64 bit boundary?

This has always been an operational choice.  You are mis-interrupting the intent of the 64 bit boundary, you seem to be saying it intends to specify the IID length for every interface on the Internet. If that was the intent, then RA's would never have needed a prefix length, nor would you need to specify a prefix length when manually configuring an interface.  If this requirement intended to specify the IID length of every interface on the Internet, then the requirement would have been sufficient by itself, we would have been done at that point. However, the fact that RAs have prefix lengths, and we specify a prefix length when manually configuring an interface, belies the argument that this was not intended to be an operational choice from the beginning.

 

So, for other than SLAAC, the 64 bit boundary has only ever been in operational guidance, there are serious consequences to not following the IETF's operational guidance in this regard, this is discussed in [RFC7421].  However, it is an operational choice to follow that guidance or not. Interpreting this requirement as ever taking away that operational choice, shows this as a false imperative.   

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
===============================================