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

[Michael Richardson <[e-mail]>]

Jen Linkova <[e-mail]> wrote:
    > to address an oscillation problem: if some servers support the
    > registration and some don't, the client might turn the registration on
    > and off, depending on the order of arriving Replies.

We can all agree that it's a mis-configuration, but I hope we can also agree
that it shouldn't keep the client from doing it's thing.  The broken servers
are... broken, and perhaps an automatic configuration process will update
them in a few minutes or hours. (Why break all your servers at the same
time!)

    > While it's not the end of the world, I think it's rather undesirable.
    > The new text says that the client always register if at least one
    > server returns the OPTION_ADDR_REG_ENABLE option, and say the client
    > MUST stop
    > registering if that server stops returning the option.

I wanted this text, and I continue to want it.

Ted Lemon <[e-mail]> wrote:
    > My only worry about this is that the draft (correctly) acknowledges that
    > there may be more than one DHCP server and that such servers may have
    > different answers to the registration question, but doesn't talk about the
    > specifics of when the client decides that things have or have not
    > changed.

If the administrator turns it all off, then at some point, the DHCPv6
Advertise messages that the client observes no longer contain that option, so
it stops, right?

    > The only message for which RFC8415 acknowledges that there can be multiple
    > replies is a Solicit, but in fact an Information-Request could just as
    > easily return multiple replies. I don't know if the WG is thinking about
    > this, but this seems like a fairly serious gap.

I guess I don't have enough experience with Information-Request messages to
understand this situation.  I thought they were all unicast.

    > So I think that in fact what you're proposing here isn't quite right.
    > Rather, the client in this case should wait as it does for Advertises. When
    > it gets a reply that allows for registration, it registers with that
    > server. If it gets no reply that allows for registration, then it stops

Right, but since it's a wire-or situation, as soon as one message is seen
that has the right flag enabled, the client can start registration.  The
client does not really have to wait for "all" of them to arrive, the way it
ought to do for Advertise.

    > registering. This behavior should be specified in 8415-bis, not in this
    > document.  Additionally, the client should pick a server, and include the
    > server's DUID in a server identifier option as specified in section 14 of
    > 8415. So this is the opposite of what's currently specified. The reason for
    > this is that if you have some servers that support address registration,
    > and some that do not, and you send an address registration message without
    > specifying a server identifier, it's going to be processed by all servers,
    > so you'll get errors back from servers that don't support it and possibly
    > multiple acknowledgments from multiple servers (maybe that's okay though?).

I accept that maybe we need some text for 8514bis then.

Bernie Volz <[e-mail]> wrote:
    > Personally, I=E2=80=99m not sure 07 was worth it. I don=E2=80=99t think having the
    > clients track the servers is worth doing. And if the network conflicts
    > in the setting, live with it - fix the settings on all servers (there
    > shouldn=E2=80=99t be that many).

okay, I generally agree.
While it might be rare for an enterprise to deploy DHCP servers from
different vendors (and therefore different feature sets), I'll bet it's not
rare for them to incrementally upgrade the servers, with significant gaps
between the upgrades... because critical infrastructure.  Particularly if
it's integrated into some AD server.

    > It is a link, not a per server, setting.

I don't think that I agree, but I could live with this.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide