Re: Updated IID length text

[David Farmer <[e-mail]>]

I think the reference to RFC6164 need to be included within the exception
to the 64 bit requirement, something like the following;

IPv6 routing is based on prefixes of any length up to 128 [BCP198]. However,
the Interface ID of all currently allocated unicast addresses, except those
that start with the binary value 000 or when use to address point-to-point
link [RFC6164], is required to be 64 bits long. The rationale for the 64
bit
boundary in IPv6 addresses can be found in [RFC7421].

This is still a false imperative, but at least it is consistent with the
intent of RFC6164.


On Thu, Jan 19, 2017 at 11:55 PM, Lorenzo Colitti <[e-mail]>
wrote:

> 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] <(612)%20626-0815>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
>> ===============================================
>>
>
>


-- 
===============================================
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
===============================================