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

[David Farmer <[e-mail]>]

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, <[e-mail]> 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:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================