Privacy Extensions for Stateless Address Autoconfiguration in IPv6
obsoleted by
- rfc-8981 — Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
obsoletes
- rfc-3041 — Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Extracted elements (28)
By default, the same randomized interface identifier is used across all prefixes on an interface to minimize the number of solicited-node multicast groups a node must join, avoiding potential promiscuous-mode requirements. Nodes highly concerned about privacy MAY use different identifiers per prefix.
MD5 was chosen as the hash algorithm for generating randomized interface identifiers purely for convenience, as its properties were adequate to produce the desired level of randomization. The node MAY use another algorithm instead of MD5.
The extension generates temporary addresses from randomized interface identifiers that change over time, rather than modifying the stable public address, so that nodes can maintain a stable public address for server use while using temporary addresses for outgoing client connections — analogous to having a listed phone number but suppressing caller ID.
Using a history value (the rightmost 64 bits of a previous MD5 computation) rather than purely random generation avoids the scenario where two nodes with a flawed RNG generate the same randomized identifier repeatedly; the globally unique IEEE identifier in the input ensures divergent sequences after a collision.
Applications that open multiple sessions expecting them all to use the same source address, or that do not tolerate address changes mid-connection, may break when temporary addresses expire. This is one reason temporary addresses are disabled by default.
CGA (Cryptographically Generated Addresses) is not suitable as an alternative for privacy addresses because CGA binds the interface identifier to a public key (enabling node identification via the key) and is computationally intensive, discouraging frequent regeneration.
Some servers perform reverse DNS (PTR) lookups and may refuse connections from clients whose temporary addresses are not registered in DNS. Nodes may register temporary addresses in DNS under random names as a workaround, though inverse-DNS-based authentication has little validity.
Implementations MUST provide a method for the end user or trusted administrator to override the use of temporary addresses (repeated from Section 4, emphasizing operational control).
Implementations MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. Implementations SHOULD also provide a way for trusted administrators to enable or disable temporary addresses, as well as per-prefix granularity control.
Implementations SHOULD provide users with the ability to override TEMP_PREFERRED_LIFETIME and TEMP_VALID_LIFETIME default values, since appropriate address lifetimes vary by environment and application usage patterns.
New temporary addresses MUST be created by appending the interface's current randomized interface identifier to the received prefix.
Nodes SHOULD start the address regeneration process REGEN_ADVANCE time units before a temporary address would actually be deprecated, to avoid race conditions during DAD. A new randomized interface identifier SHOULD be generated at least once every (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units.
Temporary address lifetime values MUST be derived from the corresponding prefix: Valid Lifetime is the lower of the prefix's Valid Lifetime or TEMP_VALID_LIFETIME; Preferred Lifetime is the lower of the prefix's Preferred Lifetime or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). An implementation MUST NOT create a temporary address with a zero Preferred Lifetime.
The initial history value SHOULD be generated at random using techniques that ensure it is hard to guess; RFC 4086 is referenced for guidance on random number sources.
The randomized interface identifier value SHOULD change over time; while the same identifier can be used to create more than one temporary address, it should not remain static indefinitely.
The use of temporary addresses SHOULD be disabled by default to minimize potential disruptions to applications that depend on address stability or reverse-DNS validation.
When a preferred lifetime expires, a new temporary address MUST be generated using the new randomized interface identifier.
When a temporary address becomes deprecated, a new one MUST be generated, except when the deprecation results from a Prefix Information Option with a zero Preferred Lifetime, in which case a new temporary address MUST NOT be generated.
When an interface connects to a new link, a new randomized interface identifier SHOULD be generated immediately together with a new set of temporary addresses, to prevent correlation of addresses across links.
When processing a Router Advertisement with a global-scope Prefix Information option with A bit set, the node MUST perform DAD on every generated temporary address. If DAD detects a collision, the node MUST generate a new randomized interface identifier and retry up to TEMP_IDGEN_RETRIES times; after exhausting retries it MUST log a system error and MUST NOT generate further temporary addresses for that interface.
If only a very small number of nodes share a prefix for extended periods, changing the interface identifier alone does not ensure privacy, because the network prefix itself serves as a constant identifier grouping those nodes.
IPv6 stateless address autoconfiguration embeds a fixed interface identifier (derived from an IEEE MAC address) into every global address, enabling eavesdroppers to correlate seemingly unrelated transactions across time and topology changes, even when upper-layer payloads are encrypted.
Temporary addresses are ineffective against sophisticated traffic analysis based on packet payload content, size, and timing. More advanced techniques such as onion routing may be needed for stronger anonymity.
A randomized interface identifier is a 64-bit value derived by computing the MD5 digest over a concatenation of a history value and the IEEE-derived interface identifier, taking the leftmost 64 bits, and setting bit 6 to zero to indicate local significance only.
A temporary address is formed by appending the interface's current randomized interface identifier to a globally scoped prefix received in a Router Advertisement Prefix Information option (A bit set). Its Valid Lifetime is min(public address Valid Lifetime, TEMP_VALID_LIFETIME) and its Preferred Lifetime is min(public address Preferred Lifetime, TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR).
Defined constants: TEMP_VALID_LIFETIME = 1 week (default), TEMP_PREFERRED_LIFETIME = 1 day (default), REGEN_ADVANCE = 5 seconds, MAX_DESYNC_FACTOR = 10 minutes, TEMP_IDGEN_RETRIES = 3 (default). All user-configurable except REGEN_ADVANCE.
DESYNC_FACTOR is a random value in the range [0, MAX_DESYNC_FACTOR] computed once at system start, ensuring clients do not synchronize address regeneration. It must never exceed (TEMP_VALID_LIFETIME - REGEN_ADVANCE). MAX_DESYNC_FACTOR is 10 minutes.
Frequent generation of new temporary addresses in large networks may make it difficult for ingress filtering mechanisms to distinguish legitimately changing temporary addresses from spoofed in-prefix source addresses. Per-address access control at network egress points is suggested as a mitigation.