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

[Brian E Carpenter <[e-mail]>]

On 11/06/2017 01:14, [e-mail] wrote:
> 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?

This has two aspects for me:
1) It's simply out of place to define an arbitrary constant
in something called "architecture".

2) By defining it globally we forbid using some other value
on a future link-layer where a different value might be better.
A 'should' could cover that, of course, which is why I accept
the current 4291bis text.
 
> 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.

Yes, but for products to work out of the box without setting
a value, you need a fixed value per link type. I can't see any
practical alternative.

> 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.

No, for the out-of-the-box reason. I can't see any practical alternative
to a fixed length per link type.

>> 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.

That is what the current standards say, yes.


> And it has to be consistent across 4291, 4862 and IPv6 over foo documents.

No, it only has to be consistent within a given link type (and that applies
whether the link type is physical or virtual). It's an unnecessary restriction
to say that it must be equal for all link types.

> 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.

Nothing in any current implementation.

    Brian