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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.