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

[Bernie Volz <[e-mail]>]

I agree with you that this should be an errata.

Yes, the “3 seconds” is debatable but it guards against the zero or 1 that could result otherwise which is even worse.

The errata would of course be held until a future version is published, if ever, but it does alert folks to the issue and guards against it.

We could paramaterize the value (MIN_TOLERANCE?)  and suggest a default value (perhaps 3) which implementations could adjust if they had a good reason (such as high network latency).

- Bernie

> On Oct 14, 2025, at 4:49 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. 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 <[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
>> 
>>