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

[Ivan A Pena <[e-mail]>]

Hello to all,

The truth about this draft or scope in enterprise networks as such I 
don't see much scope for adding more options (OPTION_ADDR_REG_ENABLE).

Just to mention some points from the document:

It is mentioned that you should only send addresses with global reach.
/"The client MUST only send the ADDR-REG-INFORM message for valid 
([RFC4862]) addresses of global scope ([RFC4007]). This includes ULA 
addresses, which are defined in [RFC4193] to have global scope. The 
client MUST NOT send the ADDR-REG-INFORM message for addresses 
configured by DHCPv6."/

But then it says that the IPs will be discarded if they do not match 
the source address, where the source address is an IPv6 Link-Local and 
in the previous lines it mentions that it has to be a global IPv6 it no 
longer makes sense.
"/the message does not include the IA Address option, or the IP address 
in the IA Address option does not match the source address of the 
original ADDR-REG-INFORM message sent by the client. The source address 
of the original message is the source IP address of the packet if it is 
not relayed, or the Peer-Address field of the innermost Relay-Forward 
message if it is relayed."/

Now the client can select the lifetime, it is as if they better remove 
the DHCPv6 server, now with this the client selects a lifetime year and 
it will continue to consume resources in the router table.
/"SHOULD register or update a binding between the provided Client 
Identifier and IPv6 address in its database. The lifetime of the 
binding is equal to the Valid Lifetime of the address reported by the 
client. If there is already a binding between the registered address 
and another another client, the server SHOULD log the fact and update 
the binding."/


In addition to all this, if the objective is to keep a log or record of 
the computers that use SLAAC (for example using ChromeBook on an 
enterprise network) to do correct troubleshooting, the idea would be to 
add a "Router AdvertisementReply" to the RFC4861 standard. Where it 
contains the information of the mac address and the segment (/56, /64 
or any other), with this when a user speaks because they cannot connect 
to a printer, the IP phone cannot register to the Softswitch or IMS and 
provide the IPv6 assigned to Help Desk can locate it through the first 
4 hextets of the network, with this searching in the DHCP Server I can 
locate who is using this segment and be able to connect to the 
equipment and perform the necessary troubleshooting on that network 
where the user is connected.

Now in ISP providers, when assigning the IA_NA (/128) and the IA_PD 
(/64) to the CPE, the CPE is responsible for distributing or assigning 
this IA_PD /64 addressing to the host (cell phone, laptop, etc.) in 
/132, but when An Android or Chromebook is connected, the CPE assigns a 
/65 network, but this is not registered within the CPE since the 
standard (NDP rfc4861) does not mention that a record is kept or saved, 
where it would be better to update the protocol They already exist.

They mention in the draft to add this new option in DHCPv6 messages and 
I don't understand how this will happen on computers that use SLAAC if 
they are not going to send REQUEST or REQUEST (messages DHCPv6)