Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
obsoletes
- rfc-4941 — Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Extracted elements (29)
DESYNC_FACTOR is computed per-address (rather than globally) so that each temporary address has a statistically different preferred lifetime, preventing all hosts from regenerating addresses at exactly the same time and making it harder to infer when a new address is generated.
MAX_DESYNC_FACTOR is set to 0.4 * TEMP_PREFERRED_LIFETIME because this produces statistically different address lifetimes while capping the number of concurrent temporary addresses at approximately three when default parameter values are used, limiting stress on network elements.
REGEN_ADVANCE is expressed as a function of DAD parameters rather than a fixed constant to ensure a new preferred address is always available before the current one is deprecated, even in the worst case of TEMP_IDGEN_RETRIES consecutive DAD failures.
Temporary address generation is enabled by default in this revision (changed from RFC 4941's off-by-default), aligning with BCP 188 (RFC 7258, pervasive monitoring is an attack) and BCP 204 (RFC 7934, host address availability recommendations).
The secret_key for temporary address IID generation must not be shared with the stable-address secret_key (RFC 7217) because reusing the same key would enable an observer to correlate stable and temporary addresses to the same host, defeating the privacy goal.
RFC 4941 generated a single randomized IID shared across all prefixes in a temporary address set; RFC 8981 requires that IIDs of all temporary addresses be statistically different from each other. This means hosts on networks with multiple SLAAC prefixes must join more solicited-node multicast groups under RFC 8981 than under RFC 4941.
Some servers perform inverse-DNS (PTR) validation before accepting connections, and may refuse clients whose temporary addresses are not registered in DNS. Wide deployment of temporary addresses could challenge this practice, which the document notes has little validity.
An implementation MUST NOT create a temporary address with a zero preferred lifetime.
DESYNC_FACTOR MUST be computed per-address when a temporary address is created, and the address's valid and preferred lifetimes MUST be derived from the prefix lifetimes capped by TEMP_VALID_LIFETIME and (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively.
Implementations MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses.
New temporary addresses MUST be created by appending a randomized IID to the received prefix. The IID MUST be compared against reserved IPv6 IIDs and those already employed on the same interface and prefix before use.
TEMP_PREFERRED_LIFETIME MUST be smaller than TEMP_VALID_LIFETIME to avoid the pathological case where a newly initiated connection uses an address that immediately becomes invalid.
The host MUST perform DAD on each generated temporary address. If DAD fails, the host MUST generate a new randomized IID and retry up to TEMP_IDGEN_RETRIES times; if all retries fail, the host MUST log a system error and SHOULD NOT attempt further temporary address generation for that prefix during the current attachment.
The pseudorandom function F() used for IID generation MUST NOT be computable from the outside (without knowledge of the secret key) and MUST be difficult to reverse so that it resists attempts to recover the secret_key from output samples.
The secret_key used in the PRF-based IID algorithm MUST be at least 128 bits and MUST be initialized to a pseudorandom number at OS bootstrap. It MUST NOT be employed for any other purpose, and specifically MUST NOT be shared with the stable-address generation algorithm of RFC 7217.
When a temporary address becomes deprecated, a new one MUST be generated. However, if deprecation was caused by a Prefix Information option with a zero preferred lifetime, a new temporary address MUST NOT be generated in response to that same option.
When an interface connects to a new (different) link, existing temporary addresses for that interface MUST be removed and new temporary addresses MUST be generated for the new link.
When processing a Router Advertisement with a Prefix Information option for autoconfiguration (A bit set), the host MUST perform the specified steps including adjusting lifetimes, creating temporary addresses, and running DAD.
DNS names and HTTP cookies serve as persistent identifiers that remain constant even when addresses change; changing addresses alone is insufficient to protect privacy when these identifiers are in use, because correlating activity via the DNS name or cookie remains trivial.
Temporary addresses do not prevent an on-link observer (e.g., the host's default router) from tracking all of the host's addresses, nor do they prevent correlation based on unencrypted payload contents, packet size, or timing characteristics.
DESYNC_FACTOR: a per-address random value in the range [0, MAX_DESYNC_FACTOR] computed at address creation. Ensures statistically different preferred lifetimes across addresses and prevents synchronized regeneration across hosts. MAX_DESYNC_FACTOR = 0.4 * TEMP_PREFERRED_LIFETIME.
PRF-based IID generation algorithm: RID = F(Prefix, Net_Iface, Network_ID, Time, DAD_Counter, secret_key), where the IID is taken from the least-significant bits of RID. BLAKE3 or HMAC-SHA-256 are suggested for F(); HMAC-MD5 is explicitly unacceptable.
REGEN_ADVANCE: lead time before address deprecation to start regeneration, computed as 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits * RetransTimer / 1000) seconds, accounting for worst-case DAD duration.
TEMP_IDGEN_RETRIES: maximum number of consecutive attempts to generate a unique temporary IID before giving up, default value 3.
TEMP_PREFERRED_LIFETIME: maximum preferred lifetime for temporary addresses, default 1 day. User-overridable. Controls regeneration frequency.
TEMP_VALID_LIFETIME: maximum valid lifetime for temporary addresses, default 2 days (reduced from 7 days in RFC 4941). User-overridable.
Frequent generation of new temporary addresses may interfere with ingress/egress filtering mechanisms, making it difficult to distinguish legitimately changing temporary addresses from spoofed in-prefix source addresses, potentially undermining DDoS countermeasures.
If a temporary address is used in a session where the user authenticates, any notion of privacy for that address is compromised for all parties receiving the authentication information.
When a very small number of hosts (possibly only one) share a prefix for an extended period, changing only the IID provides little privacy benefit because the prefix portion of the address acts as a constant identifier. The mechanism is most effective when the prefix is used by a large number of hosts or changes frequently.