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

[Ole Trøan <[e-mail]>]

Lorenzo,

> On 14 Sep 2023, at 05:07, Lorenzo Colitti <[e-mail]> wrote:
> 
> 
> Thanks all for the constructive discussions here. Let's see if I can try to summarize/characterize the incremental rollout and traffic quesstion.
> 
> For SLAAC-only (A=1, M=0, O=0) or DHCPv6-only (A=0) networks , there will never be any registrations. Ole, your code will never see any of these packets :-)
> 
> Registrations will occur if A=1 and M/O=1 (i.e., there is SLAAC and a DHCPv6 server). If the DHCPv6 server supports this protocol, it will ack the regstrations and there will be at most two packets every 80% of the address lifetime.

- A router on a link setting the M-flag and a PIO with the A-flag. What is a host that supports dhcp supposed to do?

Try to acquire addresses with IA_NA and in parallel register an address with the new protocol? Run these dhcp sessions as ships in the night?
Different IAIDs presumably? 
The server is supposed to reply with NoAddrsAvail?

By overloading the M-flag you now also get a full dhcpv6 exchange even if you only want SLAAC with notifications on the link.



> 
> I think that's fine, so the only question is what to do for networks where A=1, M/O=1, and the DHCPv6 server doesn't support this message type. We have a few options here:
> The host always registers.
> The host starts off registering, but if it doesn't receive any ACKs, it stops.
> The host always registers unless an RA flag enables it.
> The host never registers unless an RA flag disables it.
> I don't think #3 and #4 are good options because operational experience deployment of new RA flags is very slow. Our experience with the deployment of pref64 taught us that changing the content of the RA requires a router upgrade, which takes years. Also I don't think there is widespread support for the "RA extended flags" option in RFC 5075 (e.g., Linux doesn't support it).

No irony here at all of course. Given that you fought tooth and nail against a generic mechanism that would let you announce new information in RAs without implementation changes. 

> 
> Right now the draft assumes #1. Personally I think this is the right way forward. It's not a lof of traffic, and SLAAC sends multicast traffic already (DAD, GRAND, multicast NS, etc.). Networks can also control the amount of traffic by lengthening lifetimes. And Wi-Fi access points where multicast is expensive can simply not send DHCPv6 packets out on the air. Many wifi networks are probably doing this already, to prevent chatty and privacy-sensitive DHCPv6 solicits going to all devices. Even if they don't, the amount of traffic is way less than other sources of multicast such as MDNS.
> 
> That said, if there is consensus that #1 will create too much traffic and we really don't want to do it, how about #2? Something like:
> 
> =====
> If after transmitting AddrRegServerDetect ADDR-REG-INFORM messages on a given network the client has never received any ADDR-REG-REPLY message, it SHOULD stop transmitting ADDR-REG-INFORM messages on that network until it connects to that network again. A suggested value for AddrRegServerDetect is 8.
> =====
> 
> or:
> 
> =====
> If the client never receives any ADDR-REG-REPLY message for a given address, it SHOULD NOT schedule any refreshes for the address.
> =====


O.