Re: Updated IID length text

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

On 20/01/2017 23:29, [e-mail] wrote:
> Brian,
> 
>>>> 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?
> 
> This isn't the right place to change the consensus that has held since 3513.

I agree with that, and it isn't my intention.

> Making this change would require a much deeper analysis of why the reasons outlined above don't apply anymore.
> You are essentially proposing to redefine the meaning of "Global Unicast".

Well, I don't agree. I was just trying to confirm that the current rule applies
to the whole of 2000::/3, without closing off future options.

Actually it might have been better if this magic number had been left out
of the addressing architecture and included in the SLAAC specification, but
it's years too late to change that.

> And please note that 4291 already has provisions for this:
> Section 2.4:
>    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.

Right. So 4000::1234 is clearly a unicast address, but if not used for
SLAAC, it doesn't need a defined IID length. That's where we have muddled
things a bit between the addressing architecture and the SLAAC spec.

    Brian