[dhcwg] Mail regarding draft-ietf-dhc-addr-notification

[Aditi Patange <[e-mail]>]

Hello DHC addr notification authors,

I am Aditi Patange from Microsoft. I recently came across ‘Registering Self-generated IPv6 Addresses using DHCPv6’ draft and I would like to surface some questions on behalf of the Windows DHCP client team.


  *   Nitpick – There is a typing error in Section 4.2.1 Bullet 5 “If there is already a binding between the registered address and another another client, the server SHOULD log the fact and update the binding.” The word “another” is duplicated. 😊


  *   Section 4.3 doesn’t clarify client behavior if the ADDR-REG-REPLY is discarded. Is the client expected to retransmit ADDR-REG-INFORM until an acceptable ADDR-REG-REPLY is received?



  *   Section 4.5 “However, the client cannot rely on the server acknowledging receipt of the registration message, because the server might not support address registration.”
I am confused by this statement. The client started the registration process because the server responded with OPTION_ADDR_REG_ENABLE indicating that it supports this address registration mechanism. Can you please clarify this statement in the draft?



  *   Section 4.6 “Whenever the client creates an address or receives a PIO which changes the Valid Lifetime of an existing address by more than 1%”

The Prefix Information Option aspect of the above statement requires the client to listen to the state of every address on every adapter, and store significant additional state. The client needs to track every address on every adapter, lifetime of each address, and has to store both the existing time as well as the newly-received time. Needless to say, this could lead to race conditions. Also, as the draft briefly acknowledged, this refresh logic would have significant power implications especially for devices running in low power mode. Can we please simplify the renewal logic to reduce computation required by the client?

Thank you,
Aditi Patange