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

[[e-mail]]

Brian,

>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?
> 
> My rationale is that
> 
> a) RFC4862 describes it very carefully as a parameter.

And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents.

> b) The addressing architecture describes it as a parameter ("n"),
> and then suddenly defines n=64 for no reason.

No reason? Please.
Read RFC7421.

> c) It gives no reason because the true reason was the obsoleted EUI-64 mechanism.

No, that's too simple a view of history.
There were at least 3 driving reasons.

1) The compromise of choosing 128 bit addresses instead of 64 bit or variable length.
    It was quite clear that 64 bits was plenty, so it made sense to tilt the playing field to ensure that we wouldn't repeat the IPv4 mistakes   of not giving end-hosts enough addresses. This was done for only 1/8th of the address space (later changed).
2) SLAAC
3) 8+8

> d) There is no physical reason for n to have the same value on different link media.

There is no technical reason why IID length is tied to the datalink type.
There was at some point when we thought it was a good idea to embed L2 addresses in the network layer address.
Even so, it would be trivial to make implementations deal with arbitrary IID lengths.

> e) Future link media might more appropriately use a different value.

See above. <n> has very little to do with data-linkt type.

> f) Therefore the addressing architecture should only define n=64 as a default
> recommendation for IPv6-over-foo documents.

I don't think that follows from the arguments laid out above.
We can (if we want to), make SLAAC work with any IID length. Including 0.

I still don't understand what the goal is here. What problem are you solving? What is the proposal?

Ole