ietf
[Top] [All Lists]

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

2017-02-19 19:14:38
On Sat, Feb 18, 2017 at 2:32 AM, David Farmer <farmer(_at_)umn(_dot_)edu> wrote:

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.


The fact that (most) glonal unicast IIDs are 64 bits is not an operational
choice, it is defined by the standards. The reason that it is a parameter
in various parts of the protocol is *not* that it is an operational choice;
the reason is to leave open the protocol to a future change in the
standards and future address allocations where IIDs are not required to be
64 bits long.
<Prev in Thread] Current Thread [Next in Thread>