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

[Ted Lemon <[e-mail]>]

FWIW I support this work, and prefer this model to IA_NA. I think using
address registration plus SLAAC actually gives us what we wanted from DHCP
without the limitations that DHCP has in terms of database management, so
if I were deploying in an environment where this kind of tracking was
required, I think this would be a better technical approach than IA_NA. I'm
sure there are cases where this would not be true—I'm not trying to suggest
otherwise—but if this could work, I'd rather use it than IA_NA because I
think there are fewer failure modes.

That said, I have questions.

First, the term "Client Identifier" is used throughout the document. What
is meant here?  Do you mean the DUID? Also, I see some normative language
that is probably unnecessary, e.g.:

DHCPv6 relay agents and switches that relay address registration messages
> directly from clients SHOULDinclude the client's link-layer address in
> the relayed message using the Client Link-Layer Address option ([RFC6939
> <https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-04.html#RFC6939>
> ]).


It doesn't really make sense to say this here, because this is a document
about clients and servers, not about relay agents. I don't think we can
assume that relay agents either do or do not support this option, and I
don't think this document can meaningfully place requirements on relay
agents. What might make sense to have here would simply be a recommendation
for operators that they use relay agents that implement this RFC, as
opposed to normative language recommending that relay agents implement this.

Regarding retransmission and acknowledgment, it's not clear to me that this
is a good idea. If the server doesn't support this message type, and isn't
going to respond to it, as seems likely, then what we really want is to
signal this to the client in the RA rather than having the client send
useless multicast messages, particularly given that multicast is expensive
in some settings, and also some clients may be battery-operated and we'd
prefer they not send useless data. For this reason, I think you really need
a flag in the PIO that indicates that this service is wanted by the
network. If that flag isn't present, the client doesn't attempt to register.


>    - If the network never changes the lifetime, or stops refreshing the
>    lifetime, then only one refresh ever occurs. The address expires.
>
> Should this say "the client stops refreshing the lifetime?" I think this
text isn't correct.

The other issue I have with this is that I think it's likely to be a common
flow that the client wants information from the DHCP server in addition to
registering its address. In this case, two approaches could work: add an
option to the "information request" that adds the registration
functionality, which would also mean that we'd get an affirmative response
from the server in all cases. Or, have this new "address registration"
function allow an ORO and have the server return the same information as in
an information request if the ORO is present. I don't care one way or
another, but I will say that since we can probably safely assume that an
Information Request will get a reply when the 'O' bit is set, the reply can
indicate that the registration was accepted, and this eliminates the need
for a PIO flag.

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

> Nicely put. I’m just not as favorable on the work as you are.
>
> And, managed addresses (DHCP) by themselves offer no added “security” as a
> device could just configure an address it wants to use directly.
>
> - Bernie Volz
>
> On Sep 12, 2023, at 10:54 AM, Sheng Jiang <[e-mail]> wrote:
>
> 
> Hi, Bernie,
>
> First, I would like to express my prefer for managed address model. It
> gives network management more authorization on network access and certainty
> on the user of addresses. And it does not reduce the autonomic or user
> transparant experience giving our feeling on using DHCP(v4). However, no
> matter the reason what have happened regarding to DHCPv6 deployment, it is
> the current situation that stateless address model are in dominant. Giving
> the limitation of reality, the notification mechanism of this document, as
> least, suppliments the lack of motheds that the network management can
> obtain the information of in-used addresses. Therefore, I support to move
> this document forward as a co-auhtor.
>
> Regards,
>
> Sheng
>
>
> ------------------ Original ------------------
> *From: * "Bernie Volz"<[e-mail]>;
> *Date: * Tue, Sep 12, 2023 10:15 PM
> *To: * "dhcwg"<[e-mail]>;
> *Subject: * Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification -
> Respond by September 13, 2023
>
> Comments with co-chair hat off:
>
> While I think this work has marginal utility as its is optional and can be
> disabled (as bad actors will soon learn to disable it in devices they may
> use for nefarious purposes), it may have some utility for help desk and
> other troubleshooting purposes. Whether the cost to implement (for clients
> and servers) is worth it is debatable. But we can let the market decide
> that.
>
> I have worked on the draft to improve its clarity on what is expected of
> clients and servers.
>
> 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. And this is the situation that is driving this work -
> clients that don’t support managed address assignment. I’d prefer we
> invested the time and energy into getting that support, rather than
> extending the protocol to cover additional cases.
>
> While some argue that a server need just log this information when a
> notification is received, that probably is too simplistic a view as
> administrators want to know what addresses are in use “now” (and scanning
> logs is not very efficient) and may want to use other facilities a server
> provides (such as historical views, again by not having to search logs).
> For the server I worked on these and other (failover and lease query)
> considerations make this much more complex to implement and integrate
> completely (though likely most of “our” customers will not demand for this
> work to be supported). Sure, for “check the box” that it is supported one
> can just log.
>
> Comments with co-chair hat on:
>
> The chairs need to follow the consensus of the working group, regardless
> of our personal opinions (we can weigh our position as we would any other
> “member’s”).
>
> This is why it is important to hear from as many people as we can to
> understand the level of consensus that this work is useful and complete.
> Volume is just one measure (and sometimes a suspect one), but we are much
> more interested in detailed reviews of the work and your level of interest
> in seeing it move forward. Hopefully this message will spur more feedback
> to make the chairs decisions easier as to WGLC?
>
> - Bernie Volz
>
> On Sep 11, 2023, at 10:43 AM, Bernie Volz <[e-mail]> wrote:
>
> Just a friendly reminder for those that support this work, or those not
> in favor, to comment on the document. We will wait until Wednesday
> September 13th as subject had that date for WGLC to conclude. (Monday is
> September 11th - today.)
>
> - Bernie Volz
>
> On Aug 31, 2023, at 10:15 AM, Timothy Winters <[e-mail]> wrote:
>
> 
> Hi:
>
> The authors believe this document is ready for WGLC. Therefore, the chairs
> are initiating a WGLC on this document.
>
> Please review this document and provide your comments and whether you
> support this document moving forward or not by end of day on Monday,
> September 13th, 2023.
>
> Please see
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-04.
> This is a Standards Track document.
>
> Thank you!
>   ~ Tim and Bernie
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>