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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thanks all for the replies and comments (as well as reporting the erratum, Patrick).

I will mark it as ‘hold for document update’ because it cannot be accepted per the RFC Editor policy (like written below by Warren), but this is also an interesting suggestion.

Regards

-éric

From: Warren Kumari <[e-mail]>
Date: Tuesday, 14 October 2025 at 22:02
To: RFC Errata System <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Technical Errata Reported] RFC9686 (8600)
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]<mailto:[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]<mailto:[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