[dhcwg] Re: [Technical Errata Reported] RFC9686 (8600)

[Warren Kumari <[e-mail]>]

On Tue, Oct 14, 2025 at 4:48 PM, Patrick Rohr <[e-mail]> wrote:

> I guess I more so wanted to point out the flaw in the prescribed mechanism
> that was discovered during implementation, as I am sure others will
> encounter the same problem.
>

Yup, I agree that it's an issue, and Eric's "Hold For Document Update"
works for this - there is a red "Errata" blob on the document, and so
people will hopefully see this.

Thank you for noting it!
W



The quoted text is inside a SHOULD section, so maybe it doesn't need to be
> updated at all.
>
> On Tue, Oct 14, 2025 at 1:01 PM Warren Kumari <[e-mail]> wrote:
>
> I believe that this errata should be rejected, or hold for document
> update.
>
> "Errata are meant to fix "bugs" in the specification and should not be
> used to change what the community meant when it approved the RFC." -
> https://datatracker.ietf.org/doc/
> statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
>
> While this text could *clearly* be improved, this was the consensus when
> the document was published, so this isn't really an Errata.
>
> IIRC, we did have some discussions around "1% or <some time>, whichever is
> greater" but we were not able to get any sort of consensus on <some time>,
> and so the consensus was to go with this…
>
> W
>
> On Tue, Oct 14, 2025 at 2:22 PM, RFC Errata System <rfc-editor@rfc-editor.
> org> wrote:
>
> The following errata report has been submitted for RFC9686,
> "Registering Self-Generated IPv6 Addresses Using DHCPv6".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8600
>
> --------------------------------------
> Type: Technical
> Reported by: Patrick Rohr <[e-mail]>
>
> Section: 4.6.1
>
> Original Text
> -------------
> Whenever the network changes the Valid Lifetime of an existing address by
> more than 1%, for example, by sending a Prefix Information Option (PIO)
> [RFC4861] with a new Valid Lifetime, the client calculates a new
> AddrRegRefreshInterval.
>
> ---
>
> * The 1% tolerance ensures that the client will not refresh or reschedule
> refreshes if the Valid Lifetime experiences minor changes due to
> transmission delays or clock skew between the client and the router(s)
> sending the RA.
>
> Corrected Text
> --------------
> Whenever the network changes the Valid Lifetime of an existing address by
> more than 3s, for example, by sending a Prefix Information Option (PIO)
> [RFC4861] with a new Valid Lifetime, the client calculates a new
> AddrRegRefreshInterval.
>
> ---
>
> * The 3s tolerance ensures that the client will not refresh or reschedule
> refreshes if the Valid Lifetime experiences minor changes due to
> transmission delays or clock skew between the client and the router(s)
> sending the RA.
>
> Notes
> -----
> Replace 1% tolerance with 3s tolerance.
>
> Rationale: As the remaining lifetime approaches zero, the 1% tolerance
> also approaches zero which can trigger redundant address refreshes. This
> problem is exacerbated by potential integer rounding, where 1% of 99s could
> be rounded down to 0s. Android's implementation of this mechanism uses a 3s
> tolerance instead. Since both clock skew and transmission delays are
> independent from the address lifetime, using a static tolerance is more
> consistent and still follows the original intent of this mechanism.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it will be
> removed shortly by the RFC Production Center.) Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --------------------------------------
> RFC9686 (draft-ietf-dhc-addr-notification-13)
> --------------------------------------
> Title : Registering Self-Generated IPv6 Addresses Using DHCPv6 Publication
> Date : December 2024 Author(s) : W. Kumari, S. Krishnan, R. Asati, L.
> Colitti, J. Linkova, S. Jiang Category : PROPOSED STANDARD Source : Dynamic
> Host Configuration
> Stream : IETF
> Verifying Party : IESG
>
>