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

[Ted Lemon <[e-mail]>]

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]>

> 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]
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>