On Sat, Feb 18, 2017 at 2:32 AM, David Farmer <farmer@xxxxxxx> 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.