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

[Esko Dijk <[e-mail]>]

> 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

From: Ted Lemon <[e-mail]>
Sent: Saturday, November 11, 2023 10:44
To: Esko Dijk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

An additional example of “significant change” might be any sort of carrier transition for Ethernet or SSID change for WiFi. References to the Detecting Network Attachment drafts might be appropriate if not already present (I’m reacting to what esko said so I don’t have the draft in front of me to check).

https://datatracker.ietf.org/doc/rfc6059/
https://datatracker.ietf.org/doc/rfc4957/

Op za 11 nov 2023 om 10:30 schreef Esko Dijk <[e-mail]<mailto:[e-mail]>>
Hi DHCWG (cc: SNAC),

Here’s a second WGLC comment for rfc8415bis. It is about the text in 18.2.12, regarding the significant change of prefixes on the link as a trigger for the client to perform actions:

If not associated with one of the above-mentioned conditions, a client SHOULD initiate a Renew/Reply exchange (as if the T1 time expired) as described in Section 18.2.4 or an Information-request/Reply exchange as described in Section 18.2.6 if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change.

The below comments are related to an open issue discussion we had at the IETF SNAC WG meeting. A SNAC stub router per draft-ietf-snac-simple, Section 5.2.3, is required to attempt to  use DHCPv6-PD and so it must follow the rules for a PD client. But the rules weren’t fully clear.

1. the requirement is a SHOULD for the client – why is it not a MUST? If it ought to be a SHOULD, what are the allowed exception reasons to deviate from the requirement? Can we maybe list these in the text to make it clear?   An indication of consequences of not taking the action could also be added, if known.
(In any case we might, for the SNAC case, upgrade the requirement to a MUST if the exception cases aren’t applicable to us.)

2. the requirement could also be clarified by splitting it , in the sense that it now says that the client either does Renew/Reply or Information-request/Reply as if it can freely choose.  However, logically this would be conditional on the status of the client: if it has obtained DHCPv6 address(es) or delegated prefixes, then I assume it MUST select the Renew/Reply exchange . And if it has none of those, it MUST select the Information-request/Reply exchange. Is that correct?

3. the term “detects a significant change” on which the normative requirement is based could be clarified slightly better.  For example like this:

OLD:
<…> if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change.

NEW:
<…> if the client detects a significant change regarding the prefixes available on the link.  A change is considered significant when one or more on-link prefixes are added, and/or one or more existing on-link prefixes are deprecated.
The reason for this is that such a significant change may indicate a configuration change at the server.

(I made some assumptions here that the ‘prefixes available on the link’ only means on-link prefixes, not e.g. prefixes of routes advertised. And assumed that the configuration change is a change at the DHCPv6 server, not just any network configuration change.)

4. about the text of point 3 on “significant change”, what if the value of the M bit in the Router Advertisement(s) on the link goes from M=1 to M=0 ?  This might indicate that DHCPv6 service for addresses and PD is not available anymore, possibly.  This situation may occur when a router is abruptly removed from the link in SNAC home use cases.  Would that be a significant change as well, or do we want to purposely ignore changes of the M bit ?  (Maybe this could become a SNAC-specific requirement; although the WG agreed in general that PD client requirements should be in rfc8415bis if possible.)

5. if the Renew/Reply exchange is done per Section 18.2.4, it seems that no random delay is specified in this case. (In the other case of 18.2.6 it is specified.)  That means potentially many DHCPv6 clients will detect the same “significant change” on the link and try to reach the server all at the same time. Shouldn’t there be a random delay applied in this case? Or, if it is applied, could this be clarified in the text? (I may have just missed it … )

Best regards
Esko Dijk


IoTconsultancy.nl  |  Email/Teams: [e-mail]<mailto:[e-mail]>


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