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

[Lorenzo Colitti <[e-mail]>]

On Tue, Sep 12, 2023 at 3:09 PM Ole Trøan <otroan=
[e-mail]> wrote:

> I must be missing something here regarding expected host behavior. If the
> M-flag is set the host will do normal dhcp surely?
> What if there is no A-flag in PIO or no PIO, then the client should
> certainly not run the new address notification protocol.
>

>
 It’s unclear from the document what expected client behavior is and how it
> interacts with the normal dhcp.
>

Right. The host might or might not support and run stateful DHCPv6. If it
does, and it gets an address, then it MUST NOT (see section 4) register it
using this protocol. Obviously, M=1 doesn't control whether the host runs
SLAAC as well. If A=1 and the client obtains addresses using SLAAC it will
register them using this protocol, even if it also got addresses from
DHCPv6. If A=0 then the host won't run SLAAC and it won't use this
protocol, except maybe in the unlikely case that someone manually
configures an address.

What should the draft say to clarify? It already says "The client MUST NOT
send the ADDR-REG-INFORM message for addresses configured by DHCPv6." That
seems to cover all the cases above, no? The rest is already specified by
RFC 4861 / 4862 / 8415.


> Finally- we need a way to provide forensic abilities for SLAAC addresses.
> The IETF does not recommend running DHCPv6-only networks for general
> purpose devices (RFC 7934 section 8.2), so SLAAC will be in use even on
> networks that support stateful DHCPv6 (e.g., because implementations will
> use privacy addresses in preference to DHCPv6 addresses). Network operators
> that want to track usage of SLAAC addresses don't have a tool to do so, and
> that is a gap in the IPv6 deployment story that we are trying to fill.
>
>
> What the IETF does or doesn’t recommend I would be a little careful in
> asserting. Especially referencing a document you have yourself authored. :-)
>

Why does it matter who the authors were? The text at the top of RFC 7934
says that it documents an Internet Best Current Practice and that
it represents the consensus of the IETF community, so I think it's
appropriate to cite it. And I am not the only author, either...

If a network needs address tracking:
> 1) use DHCPv6 address assignment
> 2) if not use savi/fhs with tracking from the network
>
> It’s not obvious to me that providing yet another way to do the same thing
> is good for IPv6.
>

As for #1 - if you mean "use DHCPv6 address assignment and SLAAC", then
this protocol is still necessary because otherwise SLAAC addresses will not
be tracked - and implementations might well prefer SLAAC addresses over
DHCPv6, e.g., because they prefer privacy addresses. If by "use DHCPv6
address assignment" you mean "use DHCPv6 only and disable SLAAC", then that
is not recommended by the IETF for general purpose devices (RFC 7934) so it
should not be something that we suggest.

As for #2, we've heard from operators that it is not easy or feasible.
Providing this information via DHCPv6 makes it much easier because that is
where today they have information about clients that use DHCPv6 address
assignment.