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

[Nick Buraglio <[e-mail]>]

Apologies for my late reply - I realize the time has lapsed. I don't
actively follow this list and wasn't aware of this draft, but I am acutely
aware of this problem space.

After reading the draft, I my first thoughts are that this is a useful
feature addressing a complaint I hear quite frequently: "We have to be able
to map a device to an network address", which is not possible with SLAAC in
a way that enterprise folks are comfortable with (i.e. they want it in the
same place they have it for IPv4: the DHCP server logs). While I have done
this with varying levels of success by scraping neighbor tables, it's a
poor and error prone method that is a bit hard to support long term.
Of course, many enterprises want to just use DHCPv[4/6] for everything in
order to ensure consistency, but I think this would be a nice compromise
and would definitely give them the functionality that I have been hearing
they "need".
Basically anyone that wants to track hardware addresses and map against
network addresses could leverage this, with a fairly low bar to get over.

I would support this, and I think it would aid in IPv6 deployments where
efficiently mapping hardware to network traffic is a sticking point. The
suggestions that I had already given to Jen are clarifying the verbiage
around how privacy addresses are handled and why DHCP assigned addresses do
not require an inform (probably self evident, but clarity is generally a
good thing).
and thinking about this
/*
*DHCPv6 relay agents and switches that relay address registration messages
directly from clients SHOULD include the client's link-layer address in the
relayed message using the Client Link-Layer Address option ([RFC6939]).*
*/
leaving a little too much to interpretation.

Sorry for the top post - I don't have the rest of the thread.

nb