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

[Lorenzo Colitti <[e-mail]>]

On Thu, Sep 14, 2023 at 8:08 PM Ole Troan <[e-mail]> wrote:

> - in SLAAC only networks, M or O flag has to be set, leading to clients
> having to try DHCPv6 address assignment or acquiring configuration
> information where there is none. I.e abuse of M/O flags
>

This draft is not targeted to SLAAC-only networks. It's targeted to
networks that use both SLAAC and DHCPv6, and that thus have a DHCPv6
server. That's very much intentional because DHCPv6 is very widely
deployed. You've been arguing that all networks (or enterprises) use DHCPv6
(or should use it). Therefore, a DHCPv6 server is always present, and
making this mechanism rely on DHCPv6 makes this proposal easier to deploy
than any similar proposal that uses any other server or protocol.

>
> - No way to only use this mechanism for hosts that do not support DHCP
> address assignment
>

That statement doesn't make sense. On a network that has A=1, all devices
will form addresses using SLAAC, regardless of whether they support DHCP
address assignment or not. It doesn't make sense to say that
non-DHCPv6-capable devices should register their SLAAC addresses, but
DHCPv6-capable devices should not.


> The “address that”, is simply to enable the DHCPv6 code in Android.
> It’s sad that we let one vendor run over the rest of the community like
> this.
>

Blaming vendors and individuals is easy, but the fact is that there is an
IETF best practice that recommends against requiring DHCPv6 only. The
reason we have that best practice is that there are real downsides to
requiring hosts to supplicate for addresses. Those arguments are written in
RFC 7934 and as WG and as a community we looked at those arguments and got
consensus on them and published them. Saying that everything should use
DHCPv6 means accepting all those downsides everywhere.