A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
Extracted elements (26)
All bits in the resulting IIDs are treated as opaque (RFC 7136), including the universal/local bit of Modified EUI-64 format. This is acceptable because random 64-bit IIDs have very low DAD collision probability, and real-world MAC address reuse means EUI-64-based IIDs also collide in practice.
Including the SLAAC prefix in the PRF computation causes the IID to vary across each prefix (link-local, global, etc.) and across networks as the host moves. This mitigates correlation of multihomed hosts' addresses and prevents address-scanning attacks that exploit predictable IIDs.
No specific PRF is mandated for F() because the best choice involves trade-offs among processing requirements, ease of implementation, and intellectual property concerns that differ across device types (embedded vs. server) and may change over time.
The algorithm is inspired by Bellovin's work on TCP sequence numbers (RFC 1948): randomizing a per-flow or per-network value using a secret key and a PRF, making the value stable for a given context but unpredictable across contexts.
The method is designed as an alternative—not a replacement—for temporary addresses (RFC 4941). Even when temporary addresses are in use, this method adds value by mitigating host-tracking vectors and address-scanning that temporary addresses do not address (e.g., patterns in the stable address used for server functions).
Because different OS installations will use different secret_key values and may use different PRFs and Net_Iface sources, addresses generated by this scheme should not be expected to be stable across different OS installations on the same hardware, including dual-boot or reinstalled systems.
The algorithm is orthogonal to temporary addresses (RFC 4941); both can be employed simultaneously. This method improves the privacy properties of the stable addresses that accompany temporary addresses, mitigating remaining tracking vectors not addressed by RFC 4941 alone.
The method is incrementally deployable and poses no interoperability implications when deployed on networks where other nodes do not implement it. It does not update or modify SLAAC (RFC 4862) itself; address lifetime properties from Prefix Information Options still apply normally.
DAD_Counter MUST be initialized to 0 and incremented by 1 for each new tentative address configured as a result of a DAD conflict. Implementations that record DAD_Counter in non-volatile memory for each {Prefix, Net_Iface, Network_ID} tuple MUST initialize it to the recorded value if such an entry exists.
Hosts SHOULD try at least IDGEN_RETRIES tentative addresses if DAD fails for successive generated addresses. In the event a DAD conflict cannot be solved, hosts MUST NOT automatically fall back to employing other algorithms for generating Interface Identifiers.
Implementations SHOULD provide the means for a system administrator to enable or disable the use of this algorithm for generating Interface Identifiers.
IPv6 implementations conforming to this specification MUST generate Interface Identifiers using the algorithm specified in Section 5 as a replacement for any other algorithms for generating stable addresses with SLAAC (such as those in RFC 2464, RFC 2467, and RFC 2470). The method MUST be employed for all stable addresses including global, link-local, and unique-local addresses.
The Net_Iface parameter MUST be constant across system bootstrap sequences and other network events, and MUST be different for each network interface simultaneously in use. This stability is required for the resulting addresses to remain stable within each subnet.
The pseudorandom function F() MUST NOT be computable from the outside (without knowledge of the secret key) and MUST be difficult to reverse. F() SHOULD produce an output of at least 64 bits; SHA-1 and SHA-256 are acceptable options; MD5 is explicitly unacceptable.
The resulting Interface Identifier SHOULD be compared against reserved IPv6 Interface Identifiers (RFC 5453 and IANA registry) and against those already employed in the same interface/prefix. If an unacceptable identifier is generated, it SHOULD be handled the same as a duplicate address.
The secret_key SHOULD be at least 128 bits and MUST be initialized to a pseudo-random number (per RFC 4086) when the OS is installed or the IPv6 stack is first bootstrapped. Access to the secret_key should be constrained (e.g., require superuser privileges) and it must not be used for any other purpose.
When DAD fails, a host SHOULD resolve the conflict by incrementing DAD_Counter and generating a new tentative address, with a random delay of 0 to IDGEN_DELAY seconds before retrying. Hosts MUST limit the number of tentative addresses tried and MUST NOT indefinitely retry.
Each configured address uses a different Interface Identifier, so leakage of one stable address's IID does not compromise the privacy of other stable addresses configured for other prefixes at any point in time.
MAC-address-based IIDs allow correlation of host activities within the same network and tracking across multiple networks. This method generates IIDs that are stable within a subnet but change across networks, mitigating cross-network tracking while retaining the operational benefits of stable addresses.
The algorithm computes RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key), where F() is a pseudorandom function that MUST NOT be computable from outside without the secret key. The Interface Identifier is then taken as the least significant 64 bits of RID.
The Network_ID parameter is an OPTIONAL input to F() that identifies the specific subnet (e.g., IEEE 802.11 SSID). Including it causes the algorithm to produce a different Interface Identifier even for the same prefix when connecting to different networks, such as different link-local or ULA deployments.
Two constants are defined: IDGEN_RETRIES defaults to 3 (minimum number of tentative addresses to try when DAD fails), and IDGEN_DELAY defaults to 1 second (maximum random delay between DAD retry attempts to avoid lockstep behavior).
An attacker on the same subnet as a victim can send a forged Router Advertisement and learn the victim's IID for an arbitrary prefix by observing DAD packets or subsequent traffic. First-hop security mechanisms such as RA-Guard (RFC 6105, RFC 7113) and the optional Network_ID parameter mitigate this attack.
The method prevents trivial host-tracking across networks because the IID changes as the network prefix and/or Network_ID changes. It also mitigates address-scanning attacks that exploit predictable OUI-based Interface Identifiers embedded in MAC-derived IIDs.
The security of the algorithm is no stronger than the secret key. An attacker who knows the PRF and can collect sufficient address samples may search the key space; 128-bit keys are recommended as adequate protection against this brute-force threat.
The Interface Identifier is 64 bits taken from the least significant bits of the RID output. All bits are treated as opaque per RFC 7136, including the universal/local bit that would otherwise have meaning in Modified EUI-64 format identifiers.