ietf
[Top] [All Lists]

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

2017-02-17 11:33:00
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(_at_)employees(_dot_)org> 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(_at_)umn(_dot_)edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================
<Prev in Thread] Current Thread [Next in Thread>