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

[[e-mail]]

Brian,

>> I would argue that we should not make any changes to this text (apart from the eui-64 part).
> 
> 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.

The 64-bit boundary is hard to defend technically. It is for example trivial to make SLAAC deal with variable length prefixes.
Our strongest argument is probably 8+8 aka ILNP.

The other side "the CIDR argument" has no technical argument foot to stand on either. There is no technical argument why the network / routing side would require more than 64 bits.

Given that what we are left with is policy, I think it is quite harsh of you to declare that there is no consensus on the current text on the IETF list.
There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost. There is a justified fear that allowing the 64 bit boundary to slide, we will end up in a situation similar to IPv4 addressing. E.g. charging per address.

This is where the IETF has to perform a fine balancing act. On one side ensure that the 64 bit boundary stands, at the other side ensure that all implementors do not enshrine a hard-coded boundary in their implementations.

O.