Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by September 13, 2023

[Bernie Volz <[e-mail]>]

Which came first? The chicken or the egg?

In the original v6 model there was stateless and stateful. If one wanted to use stateful only, it required turning off stateless. That however became an issue once a significant number of devices did not support stateful.

There’s no disagreement that some networks indeed might want both and not allowing stateless would preclude some clients, but that choice for many networks was no longer possible when a large population on devices they wanted to allow to connect forced use of stateless or resulted in loss of connectivity. The stateful choice was removed by the device vendor and when done by a major vendor had a significant impact on lots of networks.

7934 was already influenced by the state of the world at the time.

While I have no data to support my view, I do believe this harmed v6 deployment.

But we have debated this before and my personal view has not changed.

- Bernie Volz

On Sep 12, 2023, at 10:49 AM, Lorenzo Colitti <[e-mail]> wrote:



On Tue, Sep 12, 2023 at 11:15 PM Bernie Volz <[e-mail]> wrote:

I am not, however, a big supporter of this work. If all clients fully supported the “full” DHCPv6 protocol, there would be no need to configure prefixes for both managed and stateless as is now often the case to support “all” clients.

All clients, including those that support DHCPv6, also support SLAAC. Those clients will often prefer SLAAC over DHCPv6, for example because they want to generate and rotate privacy addresses.

So even for clients that support stateful DHCPv6 address allocation, there is still a need for a mechanism to register SLAAC addresses.

Unless you're saying that networks should use DHCPv6 for address allocation only, and should not use SLAAC at all. But that goes against the recommendations of RFC 7934.