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)?
>>> 
>>> At the time of this writing, we should probably be in the camp of "If
>>> you do slaac, better stick to 64, since it's know to work with legacy
>>> implementations, and besides, allows for sparse allocation (reduced
>>> collisions of IIDs when you pick a random one, resistance to address
>>> scans, etc.).
>>> 
>>> There's no compelling technical argument for mandating /64 (i.e., such
>>> specific value) if you do manual configuration or, for instance,
>>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to
>>> do with backwards compatibility than with anything else.
>> 
>> your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?
>> I intended the question for Brian, as he seemed to be of a different view.
> 
> It's hard to track this conversation, but anyway IMHO 2464bis should specify
> /64 as if the addressing architecture didn't even mention it. It has
> to specify something for SLAAC to work, and we have 20 years of deployed
> code based on /64. So we don't have the luxury of changing it, even
> if we want to.

This is confusing.
On one hand you argue we have 20 years of deployed code base and that we cannot change it, on the other hand you want to remove the 64 bit boundary from the addressing architecture, presumably with the goal of changing it?

The argument that SLAAC needs an standard-set per data-link type fixed IID length is a tenuous argument. The only technical requirement for SLAAC to work is that the the IID length is the same across all nodes on a given link.

If we remove the 64 bit boundary from 4291, then an update of 2464 will likely result in the removal of any bit boundary there as well.

> I'm not aware of any technical changes needed in 4862. Jinmei-san has
> convinced me off line that 4862 does logically require the IID length
> for link-local addresses and global-scope SLAAC addresses to be the same.
> I wish the text stated this explicitly, but that's an editorial issue.
> Apart from that, it leaves the IID length as a parameter and that's
> as it should be.

RFC4862 says:
Note that the address architecture [RFC4291 also defines the length of the interface identifiers for
some set of addresses, but the two sets of definitions must be
consistent.  In many cases, the identifier will be derived from
the interface's link-layer address.

The IID length in the IPv6 architecture is fixed. And it has to be consistent across 4291, 4862 and IPv6 over foo documents.
Feel free to look at it as a parameter, and you can pick any value you like from the 0-128 range as long as you pick 64.
That's the current state. And that is what every implementation does. If you want to _change_ that. Then you need to consider that in the light of 7421 and of the wider consequences for the Internet.

I am still confused what this draft proposes to change.

Ole