Re: Updated IID length text

[Brian E Carpenter <[e-mail]>]

On 20/01/2017 10:02, Manfredi, Albert E wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>>
>> Brian,
>>
>> [...]
>>
>>> NEW NEW
>>>   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
>>>   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
>>>   links. However, correct use of Stateless Address Autoconfiguration
>>>   (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
>>>   of Interface ID. Furthermore, to guarantee robust interoperability of
>> SLAAC,
>>>   a consistent length of Interface ID is desirable. For this reason, the
>>>   Interface ID of all currently allocated unicast addresses, except those
>> that
>>>   start with the binary value 000, is required to be 64 bits long.
>> Background
>>>   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
>>
>> By changing "For all unicast addresses" to "all currently allocated unicast
>> addresses",
>>
>> Are you proposing to reverse the decision that was made back when RFC3513
>> updated RFC2373?
>> Change log:
>> -  Revised sections 2.4 and 2.5.6
>>  to simplify and clarify how
>>       different address types  are identified.  This was done to insure
>>       that implementations do not build in any knowledge about global
>>       unicast format prefixes.  Changes include:
>>          o  Removed Format Prefix (FP) terminology
>>          o  Revised list of address types to only include exceptions to
>>             global unicast and a singe entry that identifies everything
>>             else as Global Unicast.
> 
> Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes."
> 
> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years.

Indeed. I've taken out the explicit text that people objected to, but if another /3
is released to IANA and the RIRs, don't we want to keep our options open?

    Brian