Re: Updated IID length text

[[e-mail]]

Brian, et al,

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

Ah, excellent that wasn't clear to me.

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

 - There is no magic number in 4291 (The format prefix was removed in 2373 -> 3513.)
 - The global unicast address space is defined as everything else than (000, etc)
 - The 64-bit boundary applies to _all_ of the global unicast address space
 - SLAAC is _not_ restricted to only 2000::/3
 - IANA only assigns addresses out of 2000::/3

There was an explicit change to avoid implementations building in knowledge about global unicast format prefixes.
That means that today, all of the global unicast address space (the 7/8ths) has the 64-bit boundary and of course can be used by SLAAC.

If we got the addressing model (and the 64-bit boundary) wrong:
- the safety valve is that addresses are only currently assigned from 2000::/3.
- a new document replacing 4291 would be required
- implementations would have to be updated and a new format prefix would be used

Can the 64-bit boundary be changed within 2000::/3?
Possibly, but someone would have to write a draft on that.
This isn't a change that can be snuck in between working group last call and IETF last call.

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

As currently specified, if the IETF's action was only to make  e.g. 4000::/3 available for the IANA for assignment, it would be address space behaving exactly like 2000::/3.

Ole