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

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

Fernando,

On 12/06/2017 12:47, Fernando Gont wrote:
> 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?

It doesn't *need* to be. But SLAAC by design assumes that it is
set per link-type; that is architectural flexibility which is 
removed by RFC4291, which IMHO is a bad message to send to the future.

I think this is the main reason the IESG sent draft-ietf-6man-rfc4291bis
back to us, and the main reason I signed on to draft-bourbaki-6man-classless-ipv6
> 
> 
> 
>>> 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?

Because SLAAC wouldn't work, because the addressing architecture
forbids SLAAC from working in this case.

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

Well actually, my statement was wrong. rfc4291bis needs a s/required/recommended/
to remove the inflexibility.

    Brian