Re: WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023
Lorenzo Colitti <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <CAKD1Yr1MDZWKdpb_afqCP4B8SaG9Bx5A3RqWqZ4t_WZHtuFwow@mail.gmail.com> |
On Sun, Dec 24, 2023 at 2:28 PM Daryll Swer <contact= [email protected]> wrote: > Does this imply that, if for example, I have a DHCPv6 server running on a > VLAN, and on this particular VLAN, I delegate via ia_pd to my client, a > /56, the client needs to inform back to my DHCPv6 server > through ADDR-REG-INFORM, whenever the client uses some addresses out of the > delegated /56? If the implication is yes, then would this not make it a > redundant functionality? As the DHCPv6 server will, anyway, already have > knowledge of which client received which ia_pd prefix, therefore if we do > need to identify a particular /128 IPv6 address client origin, we can do so > by looking at the ia_pd pools. > The intent was that the client is not required to do so, but it could choose to do so. For example, consider the deployment model in draft-ietf-v6ops-dhcp-pd-per-device <https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/>. The client would get a prefix from the network and could form addresses from it. But the network wouldn't necessarily know which addresses the client is using. So it cannot reach the client, add a DNS record for it, etc. The client could inform the server of these addresses using the address notification mechanism defined in this document. Does that match your reading of the doc? _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg