RE: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

["Manfredi, Albert E" <[e-mail]>]

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter

> I think that the discussion on the IETF list has already shown that there is
> no
> consensus for the current text. I don't agree with it any more, either. It
> hides
> the tension between CIDR and the consistent length needed for SLAAC.
> 
> Hence I'm still proposing that we change it. I think the median view at the
> moment
> is for the version that runs
> 
>   ...  For all currently
>    allocated unicast addresses, except those that start with the binary
>    value 000, that length should be 64 bits.

I think that as things are today, for unicast addresses allocated that may use SLAAC, the "should" might not be strong enough. We have no other implementation of SLAAC, other than one that uses 64-bit IIDs. But I agree with you, when you said that future implementations may not require 64-bit IIDs for SLAAC.

But I completely concur with your point about tension with CIDR. In fact, one thing that has always bothered me about the wording "all currently allocated unicast addresses, except those that start with the binary value 000," is that it sounds like the 64-bit IID rule holds for the majority of the unicast address space. But that's not true. Only 1/8 of the total address space is "currently assigned to unicast," and a subset of that 1/8th has the stipulation that the IIDs can be of any length.

But the majority of the unicast address space is unconstrained, as it should be. Somehow, it always ends up sounding the 64-bit IID is a fixture, in most IPv6 unicast.

Bert