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

[Warren Kumari <[e-mail]>]

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 <
[e-mail]> 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
>
>