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

[Patrick Rohr <[e-mail]>]

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
>
>