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

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

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

Correct. The second (consistent with IPv6/foo) is necessary. The first is
an artificial constraint IMHO.

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

I was thinking of rfc4291bis at that point. Of course, RFC4291 provides
a historical reason: compatibility with modified EUI-64. That's gone
from rfc4291bis.
 
>> 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).

I'd say stub networks, not end hosts, but yes. And the privacy argument now strengthens
that. There are a lot of reasons why we need much more than 8 bits. Whether we need
more than about 40 is an open question, however.

> 2) SLAAC

Of course. Again, enough bits are needed.

> 3) 8+8

Which is really 6+2+8. But again, what's important is having enough bits,
not any specific number.

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

I believe there is: so that SLAAC can work with devices out of the box, without
having to set the IID length.

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

That's correct. By dropping modified EUI-64 we have removed a
noticeable dependency. But who's to say there won't be a future
link type whose deployment scenario is better suited by, say,
80 bit prefixes and 48 bit IIDs? I have no idea about that.

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

Removing some unnecessary inflexibility. Exactly what the words in rfc4291bis do.

Regards
    Brian