Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10

[Lorenzo Colitti <[e-mail]>]

I do see the argument for "MUST mark it as unavailable", but I think SHOULD
is better. This is because with MUST, it is not valid to build an
implementation that just logs the address notifications and does nothing
else.

In practice, such an implementation would work perfectly well. SLAAC works
on /64s and on /64s conflicts are *incredibly* unlikely. I think it's less
than one in a billion chance of collision even with 100k devices on the
link, or something like that.

On Sat, Apr 13, 2024 at 12:16 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Hello Jen,
>
>
>
> Also replying implicitly to Warren’s reply dated 5th of April in the same
> thread.
>
>
>
> So, thank you, for the answers and suggested changes. We still disagree on
> one point (see below for EVY>) but, at this stage, I will it go as you have
> answered to my point (even if I do not like the answer).
>
>
>
> I.e., please upload a revised I-D and I will request an IETF Last Call
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
>
>
> *From: *Jen Linkova <[e-mail]>
> *Date: *Wednesday, 10 April 2024 at 01:15
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, Warren Kumari <[e-mail]>,
> [e-mail] <[e-mail]>, Lorenzo Colitti <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: AD review of draft-ietf-dhc-addr-notification-10
>
> Hi Eric,
>
> Thank you very much for your review and comments.
> Sorry for the delayed response, the authors have been discussing the
> remaining open items, our comments are below.
>
> On Sat, Apr 6, 2024 at 1:38 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
> > Figure 1, suggest to also add the dst address.
>
> We'd prefer not to. The diagram focuses on elements which are either
> new (different from existing mechanisms) or important for
> understanding the proposed concept. That’s why Fig1 shows the source
> address: unlike all other DHCPv6 communications,  ADDR-REG-INFORM
> MESSAGE is sent from the global address, not the link-local one. That
> difference is important to emphasize. The dst address is the standard
> multicast, so nothing new here. Adding it overloads the diagram with
> information and makes it harder to understand IMHO.
>
> EVY> fair enough
>
>
> > ` The client MUST NOT send the ADDR-REG-INFORM message for addresses
> configured by DHCPv6.` what about the very special and rare case where not
> all multiple DHCPv6 servers have received the confirmation of address lease
> ?
>
> Well...This sounds like a problem DHCPv6 protocol should address with
> or without this proposal. Improving DHCPv6 reliability is out of scope
> for this draft (and sending ADDR-REG-INFORM for addresses received via
> IA_NA is a very high price to pay: it would be *very* noisy if we
> allow the client to register DHCPv6 addresses - and this group has
> spent a lot of time discussing how to optimize the registration
> algorithm to minimize the amount of multicast noise...
> So while nothing would be broken if we replace 'MUST NOT' with 'SHOULD
> NOT', it looks very much undesirable.
>
>
>
> EVY> fair enough
>
>
>
> > # Section 4.2.1
> > In the case of multiple DHCPv6 servers, how can ` within a prefix
> delegated to the client`be checked ?
>
> There is not much difference between knowing which prefix is
> “appropriate for the link” and knowing which pool is used on the given
> link: both require some knowledge of the topology. If the
> administrator runs multiple DHCPv6 servers which share the same pool -
> some mechanism to keep the data in sync would be required anyway, even
> w.o this proposal - and defining such a mechanism sounds like out of
> scope of this draft. In case of a multi-homing scenario (or multiple
> administrative domains, each operating its own DHCPv6 infrastructure),
> then each DHCPv6 server would only register addresses belonging to its
> address space.
>
>
> Would  adding the following text to the end of Section 4.2.1 address
> your concern?:
>
> “If a client is multihomed (connected to multiple administrative
> domains, each operating its own DHCPv6 infrastructure), the
> requirement to verify that the registered address is appropriate for
> the link or  belongs to a delegated prefix ensures that each DHCPv6
> server only registers bindings for addresses from the given
> administrative domain.”
>
> EVY> this would indeed improve the specification
>
>
>
> > ` SHOULD log the address registration information` should probably be
> more explicit about which information... I.e., DUID not always have MAC
> addresses.
>
> We’d like the behavior to be consistent with what the server does for
> assigned addresses and delegated prefixes, hence the text is saying
> “as is done normally for clients to which it has assigned an address”
> - we shall probably update it with “...or delegated a prefix” though.
>
> The proposed text: “the server SHOULD log the client DUID and the
> link-layer address, if available. The server MAY log any other
> information”
>
> EVY> LGTM
>
>
> > ` SHOULD mark the address as unavailable for use and not include it in
> future ADVERTISE messages` when can this SHOULD be bypassed ? I would
> assume that a MUST would be safer.
>
> If the DHCPV6 pool configuration permits a collision between
> DHCPv6-assigned and SLAAC addresses, then that problem exists even w/o
> this proposal. This draft provides an additional signal to prevent the
> collision but it should be up to the server administrator to use it.
> Making this SHOULD a MUST would be safer but wouldn't guarantee that
> there is no collision.
> MUST would prevent a server from assigning an address that another
> host has registered. But it wouldn't prevent a host forming an address
> with SLAAC that the server has assigned to another host. That has to
> rely on DAD or on the laws of probability.
>
> Given that MUST can't guarantee that collisions don't occur,  SHOULD
> seems appropriate.
>
>
>
> EVY> we do not agree here. Up to the authors & WG to decide of course, but
> a MUST wont’ prevent other conflicts but would at least prevent some.
>
>
>
> Additionally, a very simple implementation of this draft could simply
> just log and do nothing else. Unless the hosts are malicious or the
> network is extremely large, this will work very well in practice,
> because a collision is extremely unlikely (even with 100k clients it's
> less than one in a billion). If we said MUST, such an implementation
> would be non-compliant.
>
> > ` SHOULD include the client's link-layer address in the relayed message`
> when can this SHOULD be bypassed ? I.e., without the client MAC, there is
> little use of this I-D.
>
> Good point, thank you!
>
> The proposed text:
> “DHCPv6 relay agents and switches that relay address registration
> messages directly from clients MUST include the client's link-layer
> address in the relayed message using the Client Link-Layer Address
> option ([RFC6939]) if they would do so for other DHCPv6 client
> messages such as SOLICIT, REQUEST, and REBIND”
>
> EVY> ACK
>
>
> > Should the client periodically try to register ? I fear that some
> statically addressed nodes will never register as they could stay for years
> without reboot or move.
>
> Warren's comment summarizes the WG decision.
> Anyway, statically assigned addresses are not the primary use case for
> this proposal...
>
> EVY> WG decision is paramount at this stage. So, let’s keep the text
>
>
>
>
>
>
> --
> Cheers, Jen Linkova
>