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

On Fri, Apr 12, 2024 at 11:16 AM, Eric Vyncke <[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
>


I have just uploaded a new version.

Link (for easy clickin'):
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/
Diff:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dhc-addr-notification-10&url2=draft-ietf-dhc-addr-notification-11&difftype=--html

Thank you Eric (and authors!)
W




>
> Regards
>
>
>
> -éric
>
>
>
>
>
>
>
> *From: *Jen Linkova <[email protected]>
> *Date: *Wednesday, 10 April 2024 at 01:15
> *To: *Eric Vyncke (evyncke) <[email protected]>
> *Cc: *[email protected] <[email protected]>, [email protected] <rajiv.asati@
> gmail.com>, Warren Kumari <[email protected]>, [email protected] <
> [email protected]>, Lorenzo Colitti <[email protected]>,
> [email protected] <[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]>
> 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