Re: Updated IID length text

[Bob Hinden <[e-mail]>]

Brian,

I will work on some new text, but won’t submit anything till after I get a go ahead from Suresh.  Like the other changes from Brian Haberman’s review.

Bob

> On Jan 20, 2017, at 6:16 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Bob,
> 
> Yes, I take your point. Maybe we can all close this thread now and you
> can decide what to put in the next draft.
> 
> Regards
>   Brian
> 
> On 21/01/2017 12:53, Bob Hinden wrote:
>> Brian,
>> 
>>> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter <[e-mail]> wrote:
>>> 
>>> On 20/01/2017 17:38, Lorenzo Colitti wrote:
>>>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <
>>>> [e-mail]> wrote:
>>>> 
>>>>> 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,
>>>> 
>>>> 
>>>> I object to the text "for this reason", because SLAAC is not the only
>>>> reason. There are many reasons, many of which are written in 7421, and two
>>>> sentences in this paragraph are not sufficient to describe them. I propose
>>>> the following alternative, which I believe to be normatively identical:
>>>> 
>>>>  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, 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. The rationale for the 64 bit boundary in IPv6 addresses can be found in
>>>>  [RFC7421].
>>> 
>>> Yes, I'll buy 'however’.
>> 
>> I am generally OK with the text above, but wanted to point out that Section 2.4. "Unicast Addresses” there is more than one place where 64 IIDs are mentioned.  This discusion has been about the forth paragraph in 2.4.1. "Interface Identifiers”.  It is also mentioned in the second paragraph of 2.4.4. "Global Unicast Addresses”.  I assume this would have to be modified if the w.g. decides to adopt this text.
>> 
>> As Ole pointed out there is text that discusses future changes:
>> 
>> 2.3.  Address Type Identification
>>   Future specifications may redefine one or more sub-ranges of the
>>   Global Unicast space for other purposes, but unless and until that
>>   happens, implementations must treat all addresses that do not start
>>   with any of the above-listed prefixes as Global Unicast addresses.
>> 
>> 2.4.  Unicast Addresses
>>   There are several types of unicast addresses in IPv6, in particular,
>>   Global Unicast, Local unicast, and Link-Local unicast.  There are
>>   also some special-purpose subtypes of Global Unicast, such as IPv6
>>   addresses with embedded IPv4 addresses.  Additional address types or
>>   subtypes can be defined in the future.
>> 
>> I think that this makes it clear that things are allowed to change in the future.  I don’t think we have to capture this in the single paragraph in 2.4.1, and there could be other kind of changes as well.
>> 
>> Thanks,
>> Bob
>> 
>> 
>> 
>> 
>> 
>> 
>