Re: draft-bourbaki-6man-classless-ipv6-00

[[e-mail]]

Brian,

>> Me, I don't think there's a reason to keep the 64 bit constant in
>> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no
>> reason why the IID should be link-type dependent.
> 
> I believe that is simply false unless you want to go back to the era
> of DIP switches with instructions to users to
> a) choose an IID length for their new subnet
> b) set the DIP switches on every device to select that length
> c) then plug and play.

That's a gross misrepresentation of what would happen.
For the LL we would agree on a fixed IID length of 64 (could be 118).
For addresses generated from PIO, the host will dynamically generate an IID of length 128 - prefix length.

> Otherwise LL addresses cannot be formed consistently on the
> whole link.

Trivial to solve.

> OK, that is caricature, but without a substantial reworking of
> RFC4862 I believe that is essentially what we would need, in
> an automated version, before SLAAC can start.
> 
> Anway, all this is empty talk as long as the addressing architecture
> *requires* 64 bits rather than *recommending* 64 bits.

This is what _will_ happen as soon as we start chipping away at the boundary by changing the addressing architecture from requires to recommended.

The last stand for the 64 bit boundary will then be interoperability.

Ole