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

[Ted Lemon <[e-mail]>]

On Thu, Sep 14, 2023 at 11:29 AM Jen Linkova <[e-mail]> wrote:

> > The first of these is the idea that we can put some specific new meaning
> on various combinations of A, M and O that is clear and that doesn't
> conflict with existing uses. I don't think this is true.
>
> To be honest I'm not sure we are putting any new meaning to those
> flags. We do not change their semantics at all.
> This draft is about sending some information to a DHCPv6 server. As
> per RFC4861, M flag indicates that there is a DHCPv6 server which can
> give you an address, and O flag indicates that there is a DHCPv6
> server which can give you some other information. Either of those
> flags are indicating the presence of DHCPv6 server, so the client
> would only send a registration message if the network explicitly says
> that there is a DHCPv6 server present.
>

The problem is that "there is a DHCPv6 server present" does not mean "there
is a DHCPv6 server that supports address registration present." That's what
I mean by ambiguity: you can't make a correct decision about registration
by examining the existing three bits.


> > The second is that we are proposing a new DHCP message that DHCP servers
> may not support, and this will be fine for networks like Jen's where the
> DHCP server does support it; the problem is that I don't hear anyone
> advocating for the operators of networks unlike Jen's where this
> functionality is not deployed.
>
> Well, my network doesn't support it yet, so my network is no different
> from any other. The only difference is that I'm aware of the proposed
> solution and willing to try.
> For every solution IETF develops there are always networks which could
> have deployed that but they wouldn't. I do not think it makes the
> solution bad or harmful.
>

I agree. As I said, I support this work. I just want to make sure that it
doesn't create useless new multicast traffic.


> > I think Jen has a strong motivation to try to get the right thing
> deployed. So I would like to hear Jen weigh in on whether she thinks
> changes to the RA could be practical in a timeline that would satisfy her,
> before we abandon that approach.
>
> If we require a new RA or PIO flag, we get routing vendors in the
> picture, delaying any deployments in large networks (ones using
> commercial hardware, as open source is a different story) by years.
>

Why is delaying this by years bad? If this is important to a particular
enterprise, they will ask their router vendor for the feature, and it will
show up quickly. If it's not important, it won't show up quickly. Either
outcome is fine, right? We've all been at this long enough to see "delay by
years" expire successfully multiple times. Why the hurry?


> > I also think that I proposed a solution to the "too many messages"
> problem that would work if we really don't think deploying new RA behavior
> is practical, and I haven't heard anyone comment on that.
>
> With the proposed defaults the client would send 3 packets initially.
> I do not think it's many.
>

It's three too many. Multicast is expensive. Also, if we're okay with
sending three multicast packets, then Lorenzo's objection about the
"four-way handshake" goes away: the information request can return the IP
address to which to send address registrations, and then we can unicast
them. Or if we want multicast to make relays work, at least this prevents
retransmission. In the most usual case, the client will send one multicast,
get back a unicast reply that discourages address registration, and stop
sending. If we don't get a positive response to a received packet, we just
have to send more packets into the void. I don't think that's a sensible
thing to do when we have several easy alternatives to choose from. If we
had no choice, I'd agree with you that it's not too bad, but we do have a
choice.

Fundamentally, there's a tendency to say "oh, one more multicast won't
matter." But I think this is not a good way to think about it. E.g.
currently mDNS sends two multicasts instead of one in order to make sure
that v4-only clients receive the multicast. This was a cheap no-brainer,
except that it literally doubles the multicast traffic sent by mDNS. We're
talking about fixing that in the DNSSD working group, and I feel like I've
at least learned the lesson here that we shouldn't just say "we're already
doing this much multicast, what's 2% more?"


> Maybe we can change the behaviour so if the client doesn't receive any
> ADDR-REG-REPLY to the initial registration, then it means that the
> server doesn't support the registration functionality and the client
> MUST NOT refresh?
>
> Is the client allowed to remember it as a property of the network (so
> it doesn't register addresses for X hours even if reconnected to that
> network)?
>
> Would it address your concern?
>

I think remembering that we shouldn't do address registration on the
network for some period of time is good, although I don't know how to
specify how to do that. I guess we could base it on the advertised on-link
prefix?