How does an IPv6 SLAAC host choose its interface identifier, and why did MAC-derived EUI-64 identifiers give way to stable-privacy and temporary addresses?
answer
- the low 64 bits
- ff:fe in the middle, one bit flipped
- same suffix on every network
- a hash of the prefix and a secret
- short-lived ones for outgoing
basics
~20 sA SLAAC host chooses the low 64 bits itself. Legacy modified EUI-64 copied the MAC address, making the host trackable across networks; RFC 8064 now recommends RFC 7217's stable hashed identifiers, often alongside RFC 8981's short-lived random temporary addresses.
solid answer
~50 sThe **interface identifier** (IID) is the low 64 bits of a SLAAC address; the router supplies only the prefix. The original Ethernet scheme, **modified EUI-64** (RFC 2464, RFC 4291), inserts `ff:fe` into the middle of the 48-bit MAC and inverts the universal/local bit, so `00:00:5e:00:53:01` becomes `200:5eff:fe00:5301`. That IID is identical on every network the laptop visits, which lets observers correlate its traffic and reveals the card's manufacturer. **RFC 8064** (2017) says hosts SHOULD instead use **RFC 7217**: a hash of the prefix, the interface, optionally the network, a DAD counter and a host secret — stable within one subnet, different on every other. For outgoing connections hosts can add **temporary addresses** (RFC 8981, which obsoletes RFC 4941): random IIDs with a default one-day preferred and two-day valid lifetime, replaced as they age; RFC 6724's source selection prefers them by default.
go deeper
Recall that the router gives the prefix and the host makes the last 64 bits, and that ff:fe in the middle marks an identifier built from a MAC address.
Walk through the EUI-64 construction, then explain why RFC 7217 hashes the prefix with a secret and how RFC 8981 temporary addresses rotate.
Show the operational side: logs and allow-lists that break as outgoing addresses rotate, servers that need stable identifiers, and reading from an address which scheme built it.
Weigh privacy against accountability in a fleet policy: temporary addresses for clients, stable-privacy for servers, and what identity source replaces the IP address in audit trails.
## Prefix from the router, identifier from the host A SLAAC address has two halves. The **prefix** — on Ethernet the top 64 bits — comes from a Router Advertisement's Prefix Information option. The **interface identifier (IID)**, the bottom 64 bits, is chosen by the host. RFC 4862 leaves the method for choosing it to other documents, and the recommended method has changed since IPv6 was designed. Whatever the method, the result must pass duplicate address detection before it is used. ## Legacy: modified EUI-64 RFC 2464 (IPv6 over Ethernet) and Appendix A of RFC 4291 define the original method. For the documentation MAC address `00:00:5e:00:53:01`: 1. Split the 48-bit MAC into its first three bytes (`00:00:5e`, the manufacturer's identifier) and its last three (`00:53:01`). 2. Insert the fixed bytes `ff:fe` between them: `00:00:5e:ff:fe:00:53:01` — an EUI-64. 3. Invert the **universal/local (U/L) bit**, the second-lowest bit of the first byte: `00` becomes `02`. 4. The IID is `0200:5eff:fe00:5301`, written `200:5eff:fe00:5301`. On prefix `2001:db8:42:1::/64` the address is `2001:db8:42:1:200:5eff:fe00:5301`, and the link-local address is `fe80::200:5eff:fe00:5301`. The `ff:fe` in the middle is how to recognise such an address in a log. RFC 4291 explains the inversion: it lets administrators hand-configure simple local identifiers such as `::1` and `::2` instead of `0200:0:0:1`. ## What was wrong with it RFC 8064 lists the consequences of embedding a stable link-layer address in the IID: - **Network-activity correlation** — the same IID appears under every prefix, so a laptop's sessions at home, at work and on public Wi-Fi can be linked. - **Location tracking** — following one IID across prefixes shows where the device has been. - **Address scanning** — instead of 2^64 unpredictable values, an attacker sweeps one manufacturer's MAC range with `ff:fe` in the middle. - **Device-specific exploitation** — the manufacturer bytes hint at the device type. ## Stable, opaque identifiers: RFC 7217 RFC 7217 computes the IID as a pseudorandom function: `RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)` - `Prefix` differs per network, so the IID differs on every subnet but is **stable** within one; servers that log or allow-list the address keep working across reboots. - `secret_key` is known only to the host, so nobody can predict the value from the MAC. - `Network_ID` is optional network data, such as the IEEE 802.11 SSID. - `DAD_Counter` is incremented after duplicate address detection fails, giving a fresh candidate. RFC 8064 (Standards Track) says nodes SHOULD use RFC 7217 as the default scheme for stable SLAAC addresses and SHOULD NOT embed a stable link-layer address in the IID. ## Temporary addresses: RFC 8981 - A **temporary address** has a randomised IID and short lifetimes; RFC 8981's defaults are a **one-day** preferred lifetime (`TEMP_PREFERRED_LIFETIME`) and a **two-day** valid lifetime (`TEMP_VALID_LIFETIME`), both overridable. - A replacement is generated before the current one is deprecated, so a host usually holds a few: the newest for new connections, older ones finishing their sessions. - RFC 6724's source address selection (Rule 7) prefers temporary addresses over public ones by default, and implementations must let applications reverse that. - RFC 8981 (2021) obsoletes RFC 4941. It dropped MD5 and the reuse of one IID across prefixes, cut the default valid lifetime from one week to two days, allows a host to run temporary addresses only, and removed RFC 4941's recommendation to disable them by default. ## Side by side | Scheme | Specification | Same on every network? | Changes over time? | Typical role | |---|---|---|---|---| | Modified EUI-64 | RFC 2464, RFC 4291 | yes | no | legacy, discouraged by RFC 8064 | | Stable-privacy | RFC 7217 | no | not within one subnet | the host's stable address | | Temporary | RFC 8981 | no | yes, about daily by default | outgoing connections | ## Operational consequences - An allow-list or log keyed on a laptop's outgoing address sees it change regularly; key on the prefix or on authentication instead. - Servers that others must reach use a stable address — RFC 7217 or manually assigned — not a temporary one. - Virtual machines cloned with the same RFC 7217 secret on the same prefix and interface produce the same IID; duplicate address detection catches the clash, and the DAD counter moves one of them on.
- Why is the universal/local bit inverted when a MAC address becomes an IPv6 interface identifier?In IEEE terms a universally administered address has that bit at 0. Inverting it means a globally unique identifier shows 1 in the IID, while simple hand-configured identifiers such as `::1` or `::2` carry 0, meaning local, without anyone writing `0200:0:0:1`. RFC 4291 gives exactly that motive.
- If temporary IPv6 addresses hide the host, why does RFC 8064 still care how the stable address is built?Temporary addresses cover outgoing connections, but most hosts also keep a stable address for inbound use, and it appears in neighbour caches and logs. If that stable address embeds the MAC, the privacy gain leaks straight back through it and the address stays easy to scan. RFC 8064 therefore fixes the stable half with RFC 7217.
saying these in an interview costs you the question
- The router assigns each host its SLAAC interface identifier.
- EUI-64 copies the 48-bit MAC unchanged into the address.
- Privacy addresses are currently defined by RFC 4941.
- RFC 7217 identifiers change every day, like temporary addresses.
- Temporary addresses suit a server's published address.