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

Hi Lorenzo,

TL;DR: the document is only waiting for the shepherd’s write-up update to justify the 6 authors

On the topic SHOULD/MUST, I agree that ther chance of collision is “rather small” (to say the least), but why not adding a MUST anyway to be on the safe side even if DAD will be done even for IA ? Anyway, not blocking, and happy to disagree with the authors on this minor issue.

Regards,

-éric

From: Lorenzo Colitti <[email protected]>
Date: Monday, 15 April 2024 at 11:00
To: Eric Vyncke (evyncke) <[email protected]>
Cc: Jen Linkova <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Warren Kumari <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: Re: AD review of draft-ietf-dhc-addr-notification-10
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) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Date: Wednesday, 10 April 2024 at 01:15
To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Warren Kumari <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Lorenzo Colitti <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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) <[email protected]<mailto:[email protected]>> 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

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg