Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Martin Huněk <[e-mail]>]

On 21. 12. 22 8:55, Lorenzo Colitti wrote:
> On Wed, Dec 21, 2022 at 4:19 PM Ole Troan <otroan=
> [e-mail]> wrote:
> 
>>> IMO that is actually one of the best things about this draft: it
>> provides a way to do the same in IPv6, while giving those unlimited devices
>> true end-to-end-connectivity, and without costing any more network
>> resources than if there was just one device. The lack of permissionless
>> network extension is a major feature gap between IPv6 and IPv4. This draft
>> doesn't just bridge that gap, it's actually a major improvement, because
>> unlike IPv4, the permissionless extension provides end-to-end connectivity.
>>
>> There’s nothing permission-less about DHCP-PD. It has to be explicitly
>> configured and each individual request granted by policy. By the network.
>> HNCP is further along the permission-less scale.
>>
> 
> Yes, of course PD needs to be explicitly configured, just like DHCPv4. But
> I'm not referring to how the device gets connectivity - that is never
> permissionless, even with SLAAC - rather to how it shares that connectivity
> to downstream devices. If you have an IPv4 or IPv6 address, you can extend
> the network, but you can't provide end-to-end connectivity to the devices
> you share the address with. If you have an IPv6 address via SLAAC or DHCPv6
> it's the same. But with DHCPv6 PD, you can extend the network *and* provide
> end-to-end connectivity.
> 
Now, I'm really confused. From the draft, I thought that it was talking about a device getting addresses for itself rather than for other devices connected to it.

However, now you are talking about a device that is actually a router. From what I know, the routers are using the DHCPv6-PD already, and they do not need to modify their behavior based on this draft. And even more, they probably should not.

Router/CPE usually autoconfigures itself (SLAAC or DHCPv6) and then asks for DHCPv6-PD for its downstream interfaces. This is almost the same behavior as it is in the draft except for disabled auto-config. I don't think that this is actually beneficial to save one global unicast address, so a router had to use one prefix to address itself from those provided for downstream interfaces. Ain't broke, don't fix it.

Also, as ISP, I don't care about what customers are connecting to the network. However, in the enterprise network, I really do care. Premission-less seems to me as a kind of Wild West in networking. As a network administrator in an "enterprise" network, I want to know if someone connected a router to the network even when not allowed to do so or runs a hypervisor in his/her office. I don't see it as the "best thing" to do in the corporate network you are targeting with this draft.

Now I know that if it asks for a PD, it is a router. If your draft gets implemented and the device asks for /96 PD, then I can presume that it is some ordinary (Google) device. If it asks for /64 or bigger, it could be a router, but is it really? As a result, I would have less information available, not more.

Martin