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

[Fernando Gont <[e-mail]>]

On 06/11/2017 02:51 AM, Brian E Carpenter wrote:
[...]
>>> 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.

Not sure I follow.

Router advertised Prefix/N (where N is nowadays hardcoded to be "64",
but need not). Host eploys RFC7217, and grabs 128-N random bits from F()
to generate the IID/address.

Why does N need to be set on a per-link-type basis?



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

Well, on such links the local router would advertise a /80 rather than a
/64. Why should the clients need to worry about this?



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

+1

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492