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

[Rajiv Asati <[e-mail]>]

I agree with Warren. The co-authors have collaborated well enough to get the draft to this stage (it has been a long drawn timeline for few of us). 

Cheers,

R

On Apr 16, 2024, at 5:09 AM, Warren Kumari <[e-mail]> wrote:



[ + Timothy Winters explicitly ] 

On Mon, Apr 15, 2024 at 2:08 PM, Eric Vyncke <[e-mail]> wrote:

Hi Lorenzo,

 

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

The shepherd writeup includes: "You will need the cooperation of the authors and editors to complete these checks.", and so, as an author, I'll cooperate :-) 

Tim - Perhaps the below text would work a response to Q13 (13. Has each author, editor, and contributor shown their willingness to be  listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.)?

This document has 6 listed authors. As stated in the Acknowledgements section:

"This document borrows heavily from a previous document, draft-ietf-dhc-addr-registration, which defined "a mechanism to register self- generated and statically configured addresses in DNS through a DHCPv6 server", which was abandoned after WGLC. The authors of draft-ietf-dhc-addr-notification felt that it was appropriate to acknowledge the primary authors of this previous document by keeping them as authors on the new document.

Thanks,

W

 

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 <[e-mail]>

Date: Monday, 15 April 2024 at 11:00

To: Eric Vyncke (evyncke) <[e-mail]>

Cc: Jen Linkova <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Warren Kumari <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>

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) <[e-mail]> wrote:

Hello Jen,

 

Also replying implicitly to Warren’s reply dated 5^th 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