Re: [dhcwg] [Snac] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

[Bernie Volz <[e-mail]>]

As we are trying to just clean up 8415 to become full standard, we really need to be careful about what we add. It would be much better if we referred readers to other documents (likely more as informational than normative).

Clients (servers and relays) have successfully interoperated and are working in the field so these are very much edge conditions and there could be more over time. I think implementations have pretty much understood these conditions.

- Bernie Volz

On Nov 17, 2023, at 8:00 AM, Esko Dijk <[e-mail]> wrote:



Hello Tim,   (removing SNAC WG from cc for these more detailed comments)

 

Thanks for the comments about the thread. Would you or co-authors like to receive concrete text proposals, to address the points 1 / 2 / 3 / 5 of my second WGLC comment?  If so I can send some to the list.

If you have any thoughts about point 1. – what are the allowed exceptions where the client can deviate from the SHOULD – or point 5. – should we add a random delay before acting on “significant change”? -  then I’m happy to hear it.

 

6.

After re-reading the text again I also came up with a point 6. , a proposed clarification by adding an example to the “may have moved to a new link” example list:

 

• The client’s network interface indicates a disconnection event, followed by a connection event.

 

The rationale for adding this is that the bullet 2 example gives the impression that this example is only about reconnecting to the same link only. Or at least, this is as some readers may interpret it: “a link on which it has obtained leases” is the same link as before.

So for completeness we can add this case in which it’s not obvious if the same link, or another link, was connected in the end. The only certain thing is that the network interface indicated a (brief or long) disconnection. So it’s a more general case and it can be a different link. It could also be the same link as before but with significant changes having happened in the meantime while the client was disconnected.

 

Regards

Esko

 

 

 

 

From: Snac <[e-mail]> On Behalf Of Timothy Winters
Sent: Tuesday, November 14, 2023 14:45
To: Esko Dijk <[e-mail]>
Cc: Ted Lemon <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Snac] [dhcwg] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

 

Hi Esko,

 

Thanks for reading the 8415 document, a couple of things from this thread.  

 

RFC 8415 did relax or update from request/delegating router to client/server as mentioned.

 

I'm open to trying to define "significant changes", I think we could try to do something like what is at the top 18.2.12 for defining examples of link change events. Like you have below.

 

As for the SHOULD, some DHCP clients don't react to events such as new prefixes in the RA with only the L flag set might not trigger a Renew event.

 

I can also confirm that DNA (6059) is not in DHCPv6 at the moment.

 

Regards,

Tim

 

On Sat, Nov 11, 2023 at 7:58 AM Esko Dijk <[e-mail]> wrote:

> An additional example of “significant change” might be any sort of carrier transition for Ethernet or SSID change for WiFi

 

My assumption was that these types of change cases are already covered by the requirement on detecting prefix change.  E.g.:

- if the SSID changes (without a reconnection – if that’s possible) , but all prefixes stay the same, then it’s “no change”

- if the WiFi client changes access points so a new SSID results, that’s covered by bullet 4 of 18.2.12 -> “change”

- Ethernet is plugged out and in again on the same link -> that’s covered by bullet 2 -> “change”

- Ethernet is plugged out and in again on a *different* link -> this seems not covered yet, however chances are that the new link will have a new ULA or global prefix on-link. Which is detected as “change”

- if any prefix changes, without these link-layer change events -> “change” per 18.2.12 last paragraph

 

There seems to be some overlap here with Detecting Network Attachment detection of a new network, but a large part may already be covered by current text.

DNA could be the default method to quickly detect “same-link attachment”, in case the DHCPv6 client sits on an IPv6 host.  (DNA is not applicable to a pure IPv6 router device)

 

Esko

 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg