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

[Lorenzo Colitti <[e-mail]>]

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.

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:

   1. The host always registers.
   2. The host starts off registering, but if it doesn't receive any ACKs,
   it stops.
   3. The host always registers unless an RA flag enables it.
   4. 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).

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.
=====

On Thu, Sep 14, 2023 at 4:43 AM Bernie Volz <[e-mail]> wrote:

> While in some ways yes, I would think that is likely a bad idea as
> infrastructure devices are upgraded much more slowly than clients and so it
> might take a long time before it can be used by any clients.
>
> I do worry about the DHCPv6 server loading impacts for large networks, but
> in many cases (such as DOCSIS) it will only be the home gateway that sees
> this traffic … and in DOCSIS CMs use dhcpv6 and not SLAAC on the WAN side.
>
> Flat networks such as trade shows may see a lot of activity, but usually
> there performance isn’t as big a deal. And, most of the clients aren’t
> impacted by a power failure (as they run from battery) so we shouldn’t see
> a huge spike after power is restored. But even here these numbers are not
> as bad as larger SP deployments.
>
> And with the “refresh” algorithm changes recently we hopefully will see
> far less notification traffic, at least when lifetimes are reasonably long.
>
> These are certainly considerations for moving this forward, and maybe more
> analysis is needed to understand the full impact if we leave it for clients
> to default on (and not depending on a new PIO flag to turn this feature on,
> but off).
>
> Yes, in an ideal world having all general purpose clients support dhcp
> would certainly be best, but sadly that is not were we are and not sure
> this has much hope of changing for now.
>
> - Bernie (from iPad)
>
> On Sep 13, 2023, at 3:17 PM, Ole Trøan <[e-mail]> wrote:
>
> 
> If the flag is the way to go I was thinking the reverse, that the new
> protocol would require explicit enablement.
> After all most SLAAC networks would not need this and most networks that
> needs network controlled addressing would use normal DHCPv6.
> And isn’t this just a band-aid until all hosts support DHCPv6 address
> assignment anyway?
>
> O.
>
> On 13 Sep 2023, at 20:57, Bernie Volz <[e-mail]> wrote:
>
> Ok, more understandable.
>
> Maybe if consenus is for a PIO flag (when A bit set) that if set, say’s
> don’t send server “global scope” SLAAC address notifications would be
> something to consider. That means existing routers don’t have to change for
> clients to send notifications (as flag would be clear - meaning to send).
> Market can then determine if implementing this router PIO flag is worth it
> or not. And flag is controllable by administrator for a network which is
> better than client control which is difficult to signal.
>
> And yes, I suspect that lots of servers (and maybe even some relays) will
> log about the unknown packets and could clutter up logs. It may be
> appropriate to suggest “DHCP servers that do not wish to fully support this
> message, way want to consider whether logging an unknown message for the
> registration message is worth it — though minimal support of the message by
> logging details of the notification request and sending a reply may not be
> significantly more work and would eliminate logging retransmissions except
> when a client fails to receive reply.”
>
> - Bernie (from iPad)
>
> On Sep 13, 2023, at 2:42 PM, Ole Trøan <[e-mail]> wrote:
>
> 
> Hi Bernie,
>
> Sorry if I was muddying the waters.
> I tried to understand if signaling was needed to inform the client to do
> address notification.
>
> Since it’s only relevant if A-bit is set, then perhaps a new PIO flag
> telling the client to initiate the new address notification protocol.
>
> (Not supporting the proposal at all, but the extra flag would at least
> mean I never needed to see the packets. And yes, my DHCPv6 server writes a
> log line per unknown message.)
>
> Cheers,
> Ole
>
>
> On 13 Sep 2023, at 20:08, Bernie Volz <[e-mail]> wrote:
>
> I’m confused by this recent set of discussions.
>
> M&O bits in RA say whether client should run dhcpv6 client (M means
> address assignment via dhcpv6).
>
> A-bit in Prefix Information Option in RA say whether client can auto
> generate address.
>
> When M-bit set for RA receiver for interface, if dhcpv6 implemented on
> client it does dhcpv6. If A-bit set, client does SLAAC. So in this case
> either client does both (though may not get address via dhcpv6) or only
> SLAAC if no dhcpv6 support.
>
> But as there were long discussions on these bits, my understanding and
> yours may well be different as the IETF decided to punt on the issue.
>
> Yes there is no only do dhcpv6 if you support it, otherwise do SLAAC (do
> not do both). That might be something to consider if this is a significant
> issue but my understanding is that we have lived in this world for a long
> time.
>
> Also, Ole wrote:
>
> So it sounds like there is a PIO flag missing, that would have to be used
> to signal that a SLAAC client should also do DHCPv6. I really don’t think
> the M-flag or the O-flag should be overloaded to indicate this. But I might
> have misunderstood Lorenzo’s message.
>
>
> The M&O bits are interface specific (run dhcpv6 or not and issue Solicit
> if M set). PIO is prefix specific. So this would be mixing things when
> there is more than one prefix active on an interface. I don’t see that as a
> good thing.
>
> - Bernie
>
> On Sep 13, 2023, at 1:49 PM, Michael Richardson <[e-mail]>
> wrote:
>
> 
> Ole Troan <[e-mail]> wrote:
>
> the M-flag is set the host will do
>
> normal dhcp surely?
>
>
> If the host has a dhcpv6 client.
>
>
> Well, this proposal assumes every host has a DHCPv6 client
>
> implementation does it not? :-D
>
>
> I think it really could be a one-shot python script run, perhaps from cron.
> (It might need to bail if renew time hasn't arrived yet)
>
> So it sounds like there is a PIO flag missing, that would have to be
>
>
> Such hosts just fail to get an address today.
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>