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

["Pascal Thubert (pthubert)" <[e-mail]>]

Lorenzo >   The draft does say that the server must hand out a prefix of sufficient size to support SLAAC. There's a good reason for this: SLAAC is the only address assignment mechanism that is mandatory to implement, and in large numbers of hosts, it's the only one that is implemented.

Even that, Lorenzo, does not convince me. Because it really depends on what attaches to that node and in that case it does not have to be generic. Jen mentioned a box she opened in her home, with devices embedded at manuf. Do they need SLAAC? I’d bet they have hardcoded addresses and every box shipped has exactly the same.

That’s at least what industrial production lines do. They hardcode RFC 1918 addresses when they design one line and then build as many lines as they need identically. Since it’s all v4, there’s a NAT at the end of the line. To migrate to v6, it would make sense to replace the NAT by a CLAT and delegate it a /96. This way a /64 can cover all the parallel lines and a lot more stuff.

I also saw a useful application of the delegation to provide addresses to apps inside a device; the apps do not do SLAAC, they get what the OS will give them. For privacy, see next point, if it is known that a /48 is used for delegating /64s and above, then the guessability plays in the bits between 48 and 64, which means that there’s no privacy at all.

And it’s never too late to start defining an autoconf mechanism that works on other plen too, as long as we make DAD fast and solid in the process.

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

And by that we mean that the space where different hosts get different addresses is the bits between say 80 or 88 and 128. Not to be confused with what I said above, that is, if hosts get delegated a /80 out of a /64 for internal usage, then the space to differentiate hosts is between 64 and 80 and that’s only 16 bits, way below the required 40.

IOW: if you delegate to routers that serve other devices in a CIDR fashion, you can give them /80s to build /88 subnets. If you delegate to hosts that will use all available addresses for internal addressing, give them /96s out of a /56 and /104 and longer out of a /64 so there’s still 40 bits to hide this host into… We must be able to signal what can of length we want because really depends on the use case.

regards,

Pascal
From: Lorenzo Colitti <lorenzo=[e-mail]>
Sent: Friday, August 4, 2023 4:51 AM
To: Brian E Carpenter <[e-mail]>
Cc: Owen DeLong <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>; [e-mail] list <[e-mail]>
Subject: Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device

Let's not fall into another debate about the /64 boundary :-) The draft does not have /64 hard coded anywhere in it, so if and when we change the subnet size supported by SLAAC to something else, the document will not need to be modified.

The draft does say that the server must hand out a prefix of sufficient size to support SLAAC. There's a good reason for this: SLAAC is the only address assignment mechanism that is mandatory to implement, and in large numbers of hosts, it's the only one that is implemented.

Yes, this does mean that this draft is not applicable on all networks. But to be realistically, I see no way that we could get consensus on *any* method that would support end-to-end connectivity and permissionless network extension on all networks. If anyone can think of one, please do share and we'll go off and do that instead :-)

In the meantime, this draft is what comes closest to that goal. It meaningfully increases the capabilities of large networks by allowing unlimited end-to-end extension, and that's a huge improvement. Let's not be the perfect be the enemy of the good.

Cheers,
Lorenzo

On Fri, 4 Aug 2023, 05:30 Brian E Carpenter, <[e-mail]<mailto:[e-mail]>> wrote:
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian E Carpenter
>>> Sent: Wednesday, August 2, 2023 11:38 PM
>>> To: Ole Trøan <[e-mail]<mailto:[e-mail]>>
>>> Cc: [e-mail]<mailto:[e-mail]> list <[e-mail]<mailto:[e-mail]>>
>>> 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 <[e-mail]<mailto:[e-mail]>>
>>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops