Re: Updated IID length text

[Lorenzo Colitti <[e-mail]>]

As Brian says, we can't change the normative effect in the context of
promoting the document to full standard.

As for making room for exceptions: isn't it a given that any standards
track document can update RFC 4291? (Assuming 6man has either reviewed and
gotten consensus on it, or not requested to review it)

On Fri, Jan 20, 2017 at 2:25 PM, David Farmer <[e-mail]> wrote:

>
>
> On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti <[e-mail]>
> 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].
>>
>> Cheers,
>> Lorenzo
>>
>
> How should that be interpreted? Do my Point-to-Point links need addresses
> that begin with binary 000? How do I get an allocation of those?  Because
> it says I must use a 64 bit IID with the Global Unicast Allocation that I
> got from ARIN.
>
> Here is another problem, RFC 6164 probably should have updated 4291 for
> that reason.  And if there are any future exceptions should update 4291bis,
> for similar reasons.
>
> There are lots of good reasons to use 64 bit IIDs almost everywhere, but
> there are exceptions.  However this text doesn't leave room for any
> exceptions, even the one that it cites.
>
> Again keeping "required" I believe is a false imperative.  If we can't fix
> that by going to "should", can we at least make room for official standards
> track exceptions, like the one cited and any future ones we agree on?
>
> Thanks
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>