RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 9686, "Registering Self-Generated IPv6 Addresses Using DHCPv6", December 2024
Source of RFC: dhc (int)
Errata ID: 8600
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Patrick Rohr
Date Reported: 2025-10-14
Held for Document Update by: Eric Vyncke
Date Held: 2025-10-15
Section 4.6.1 says:
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.
It should say:
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/
