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

[Fernando Gont <[e-mail]>]

Hello, Brian,

On 06/13/2017 04:26 AM, Brian E Carpenter wrote:
> 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 that RFC4291 should simply say that the RECOMENDED value is 64,
leaving the door open to other values. With RFC8064 in place, there's
not much reason for this value to be per-link. BUt that doesnt' mean
that a specific value should be mandated (MUST).



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

Exactly. SLAAC should be able to work with non-64 bits. Implementations
should be made made flexible with that in mind, no matter we keep 64 as
RECOMMENDED.



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

Agreed.

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