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

[Bernie Volz <[e-mail]>]

Likely better to use “1% or 3 seconds, whichever is greater”? Larger changes can have larger tolerances before potentially rescheduling.

- Bernie Volz

> On Oct 14, 2025, at 2:51 PM, [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