Privacy Extensions for Stateless Address Autoconfiguration in IPv6
obsoleted by
- rfc-4941 — Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Extracted elements (23)
A DESYNC_FACTOR (random per-client value in range 0–MAX_DESYNC_FACTOR) is subtracted from TEMP_PREFERRED_LIFETIME when computing a temporary address's preferred lifetime. This prevents all clients from synchronizing and regenerating new addresses at exactly the same time, which would create a detectable traffic pattern.
A history value is used as input to successive MD5 computations rather than pure random generation. This avoids the failure mode where two nodes with a flawed RNG generate the same randomized identifier, detect the collision via DAD, and then generate the same identifier again; using the (often globally unique) IEEE identifier in the hash input ensures divergence on retry.
MD5 was chosen to generate pseudo-random interface identifiers because IPv6 nodes are already required to implement MD5 as part of IPsec, so the code will already be present. MD5's properties were deemed adequate to produce the desired level of randomization without requiring additional cryptographic infrastructure.
The same randomized interface identifier is used to generate temporary addresses across all global prefixes (one address per prefix) rather than a unique identifier per prefix. This reduces the number of solicited-node multicast groups a host must join, avoiding the need to put the interface into promiscuous mode.
In the absence of stable storage, there is no history value available across restarts. The initial history value must be generated at random, potentially drawing on machine-specific configuration data (user identity, security keys, serial numbers) combined with random bits, then processed through MD5.
Some servers perform reverse-DNS lookups and may refuse service to clients whose addresses cannot be mapped to a DNS name that also maps back to the same address. Nodes using temporary addresses could register those addresses in DNS using random names (e.g., a string representation of the address itself) to accommodate such servers.
Use of temporary addresses may complicate network debugging and operational troubleshooting, as it becomes harder to determine whether anomalous behavior originates from a single node or multiple nodes. Site policy may mandate that temporary addresses not be used, and implementations may provide a trusted-administrator override.
A temporary address MUST NOT be created with a zero Preferred Lifetime. A temporary address is only created if the calculated Preferred Lifetime (lower of public address's Preferred Lifetime and TEMP_PREFERRED_LIFETIME minus DESYNC_FACTOR) is greater than REGEN_ADVANCE.
DAD is recommended on the first address generated from a given randomized identifier, but should be skipped on all subsequent addresses generated from the same randomized interface identifier, since running DAD on every temporary address provides little benefit.
Duplicate Address Detection (DAD) must be performed on a generated temporary address. If DAD indicates the address is in use, a new randomized interface identifier must be generated and the process repeated up to 5 times. After 5 consecutive failures, the implementation must log a system error and cease attempting to generate temporary addresses for that interface.
If a temporary address becomes deprecated as a result of processing a Prefix Information Option with a zero Preferred Lifetime, a new temporary address must not be generated.
Implementations should generate new temporary addresses on a periodic basis by generating a new randomized interface identifier at least once every (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. Implementations should provide end users with the ability to change this regeneration frequency.
It is recommended that an implementation start the address regeneration process REGEN_ADVANCE time units before a temporary address would be deprecated, to allow sufficient time to avoid race conditions during DAD.
The valid lifetime of a temporary address is the lower of the corresponding public address's Valid Lifetime or TEMP_VALID_LIFETIME. The preferred lifetime is the lower of the public address's Preferred Lifetime or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR).
When an interface connects to a new link, a new randomized interface identifier should be generated immediately along with a new set of temporary addresses. This ensures different randomized identifiers are used on different links, preventing correlation of addresses across link changes.
When processing a Prefix Information Option, implementations MUST NOT increase the lifetimes of an existing temporary address; they may only lower them.
IPv6 stateless address autoconfiguration derives interface identifiers from IEEE MAC addresses, creating globally unique and non-changing identifiers embedded in addresses. Even as a mobile node changes its routing prefix across topological locations, the interface identifier remains constant, enabling tracking of device movement and activity correlation across unrelated transactions.
Defined constants: TEMP_VALID_LIFETIME (default 1 week), TEMP_PREFERRED_LIFETIME (default 1 day), REGEN_ADVANCE (5 seconds), MAX_DESYNC_FACTOR (10 minutes), and DESYNC_FACTOR (random value in 0–MAX_DESYNC_FACTOR, computed once at system start, must not exceed TEMP_VALID_LIFETIME - REGEN_ADVANCE).
Temporary addresses are global-scope addresses generated by appending a randomized (pseudo-random) interface identifier to a prefix, used for outgoing connections for a short period. They coexist with public addresses (derived from IEEE identifiers) that remain stable for use as server addresses registered in DNS.
The algorithm maintains a 64-bit 'history value' in stable storage. On first boot, it is initialized from a random source. After each randomized interface identifier generation, the rightmost 64 bits of the MD5 digest are saved as the new history value for the next iteration.
The document does not introduce security issues beyond those already associated with stateless address autoconfiguration. The motivation is entirely privacy-driven: preventing correlation of a node's activities across time and topological locations by ensuring IP addresses in packet headers do not reveal a persistent, globally unique identifier.
A temporary address transitions from preferred to deprecated when its Preferred Lifetime expires. On deprecation, a new temporary address is generated (unless the deprecation was triggered by a Prefix Information Option with zero Preferred Lifetime). Deprecated addresses may continue to be used for established connections but must not be used to initiate new connections.
The randomized interface identifier is 64 bits wide. It is formed by taking the leftmost 64 bits of the MD5 digest over (history_value || ieee_interface_identifier) and setting bit 6 (universal/local bit) to zero, indicating local significance only.