Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device

On 04-Aug-23 05:25, Owen DeLong wrote:
> /64 also provides a sufficiently large space that the odds of a collision among randomly generated addresses are sufficiently small as to allow address autoconf to have a high success rate on the first attempt.

There's that, and a similar argument about privacy/guessability of IIDs. When we looked at this for RFC7421, we concluded that 40 bits was enough, so /80 or even /88 subnets would be reasonable.
(https://www.rfc-editor.org/rfc/rfc7421.html#page-16)

> 
> Walking further right to work around stingy provider’s bad allocation policies is a step in the wrong direction, IMHO.
> 
> That said, I do agree that /64 shouldn’t be hard coded anywhere and that prefix size should be an operator choice. I think it is useful for /64 to remain a strong recommendation.

So perhaps 6man should adopt draft-bourbaki-6man-classless-ipv6?

    Brian

> 
> Owen
> 
> 
>> On Aug 3, 2023, at 08:52, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>>
>> +295147905179352825856
>>
>> I believe that neither any new spec nor any new implementation should have 64 hardcoded in it anymore. There should be a MUST in a BCP for that.
>>
>> There are some chains of inheritance that should be broken before they hurt too much, e.g., https://garethdennis.medium.com/the-not-so-glamourous-origins-of-standard-track-gauge-2b5f1ae7e3bc.
>>
>> Though the horse tall tale might be overrated, I still believe in the one that says that the 64 value was not defined for the best of admins, but to allow SLAAC using the MAC address as IID even in L2 networks using the MAC-of-the-future, of 64 bits. Firewire is dead, and 15.4 is the only major L2 left with 8 bytes MACs. The IETF now discourages MAC for IID anyway.
>>
>> 64 is thus only useful because of some existing SLAAC implementations and should be considered as a special value only in that context, to be provisioned accordingly by the admin that really wants SLAAC and those devices (admittedly, my home gateway is like that).
>>
>> NetOps who are not in that context should be able to build the network they want with minimum constraints. There should not be constraints that are there only to fit the taste or the limitations of the protocol designers. A touch of humility and a good dose of separation of power & responsibility would serve us well here.
>>
>> All the best,
>>
>> Pascal
>>
>>
>>> -----Original Message-----
>>> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
>>> Sent: Wednesday, August 2, 2023 11:38 PM
>>> To: Ole Trøan <otroan@employees.org>
>>> Cc: v6ops@ietf.org list <v6ops@ietf.org>
>>> Subject: Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device
>>>
>>>> On 03-Aug-23 09:20, Ole Trøan wrote:
>>>> Brian,
>>>>
>>>>> On 2 Aug 2023, at 23:10, Brian E Carpenter <brian.e.carpenter@gmail.com>
>>> wrote:
>>>>>
>>>>> On 02-Aug-23 18:55, Ole Trøan wrote:
>>>>>>> With all due respect, etc. etc., very few people on this list have a
>>> typical home network. If we are talking about customers of an ISP that only
>>> offers a /60, it's a different world to ours. I am *not* defending such ISPs,
>>> far from it, but the CEs that they provide are highly unlikely to enable
>>> dhcp-pd-per-device.
>>>>>> If this proposal results in an address assignment approach that cannot
>>> even number a home network that has been assigned 295147905179352825856
>>> addresses, at least an outsider would start wondering what we were smoking.
>>>>>
>>>>> Well yes, but aren't you agreeing with me? A CE that only has a /60
>>> probably shouldn't support a delegation method that assigns a whole /64 to a
>>> single device. (Unless the CE also knows that the device is capable of
>>> assigning longer prefixes to subsidiary devices, which is essentially what
>>> Pascal was saying.)
>>>>>
>>>>> Or in other words, the dhcp-pd-per-device mechanism is only useful for
>>> networks that know how to use it.
>>>>
>>>> Yes, that we agree on.
>>>> DHCP PD as a delegation method supports any prefix length.
>>>
>>> So does RFC 8992, as it happens. I had fun in my toy implementation
>>> supporting any prefix length.
>>>
>>>> The size of the assigned prefix should be an operational choice. I am not
>>> sure this document needs to say more than if the prefix is longer than 64
>>> then further sub-assignment to other hosts will not support SLAAC. If even
>>> that.
>>>
>>> Yes.
>>>     Brian
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 