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

[Esko Dijk <[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]