[dhcwg] [Errata Held for Document Update] RFC9686 (8600)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 15 October 2025 09:08 UTC

To: prohr@google.com, warren@kumari.net, suresh.krishnan@gmail.com, rajiv.asati@gmail.com, lorenzo@google.com, furry13@gmail.com, shengjiang@bupt.edu.cn
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20251015090820.22DE8C00042B@rfcpa.rfc-editor.org>
Date: Wed, 15 Oct 2025 02:08:20 -0700
Message-ID-Hash: FY6ESE4LIMZPZE45U7NEXUTIBIYJAUZO
CC: iesg@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [dhcwg] [Errata Held for Document Update] RFC9686 (8600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Ms8Qhg-zEpWEX9Rnf7jsDw6Qbp0>

The following errata report has been held for document update 
for RFC9686, "Registering Self-Generated IPv6 Addresses Using DHCPv6". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8600

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Patrick Rohr <prohr@google.com>
Date Reported: 2025-10-14
Held by: Eric Vyncke (IESG)

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.

--- Verifier note (Eric Vyncke) ---
See the thread at https://mailarchive.ietf.org/arch/msg/dhcwg/j1XxAx2yNlmq_EA2M0Uc_pjIxMA/

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

[dhcwg] [Errata Held for Document Update] RFC9686… RFC Errata System