implement draft-ietf-dhc-addr-notification
Implement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this draft implements a message from the DHCPv6 client to a DHCPv6 server to log the address the client is using. This enables the server administrator to better troubleshoot issues related to DHCP, because there is a centralized record of addresses associated with the clients using them.
The requirements in the draft include accepting the registration message from the client, returning an appropriately formed acknowledgement, logging a lease in the lease db, and retiring the address after the preferred lifetime has elapsed without a refresh.
[ [ After receiving this ADDR-REG-INFORM message, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415]. If the server believes that address being registered is not appropriate to the link [RFC8415], it MUST drop the message, and SHOULD log this fact.
If the address is appropriate, the server:
-
SHOULD register or update a binding between the provided Client Identifier and IPv6 address in its database; -
SHOULD log the address registration information (as is done normally for clients which have requested an address), unless configured not to do so; -
SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages. -
SHOULD send back an ADDR-REG-REPLY message. -
If the address registration server does not receive such a refresh after the preferred lifetime has passed, it SHOULD remove the record of the Client-Identifier-to-IPv6-address binding.
There aren't any specific requirements in the draft about how to facilitate finding or monitoring these 'leases' so that is all implementation-specific. We might want to log receipt of these messages, if we can't mark the leases to indicate it was reported by the client, rather than a 'regular' dynamic lease from the DHCPv6 server.
- consider some indication on the lease record that this is self-assigned that would facilitate filtering and locating just this kind of lease records
- consider some log message indicating this was a self-assigned address reported by the client