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

[Timothy Winters <[e-mail]>]

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