IPv6 Privacy Extensions: How Your Phone Hides Its Real Name

The Tracking Problem Built Into the Original IPv6 Design

When the IETF designed Stateless Address Autoconfiguration (SLAAC) for IPv6, the original mechanism for generating the lower 64 bits of an address — the interface identifier — was EUI-64. The process was elegant: take the device's 48-bit MAC address, split it in half, insert the bytes FF:FE in the middle, and flip bit 6 of the first byte (the Universal/Local bit). The result is a stable, globally unique 64-bit string that the host appends to whatever network prefix the router advertises.

The engineering logic was sound. MAC addresses are already supposed to be globally unique. Deriving the interface identifier from the MAC produces an identifier that is guaranteed not to collide with any other device on the planet. No central coordination needed, no registration required.

The privacy implication was severe. Your IPv6 address would carry your hardware identifier in every packet you sent — to every website, every server, every network you connected to. At home, at work, at a coffee shop, at an airport — the lower 64 bits of your address remained constant. A web server logging your source address could correlate all your sessions across every network you ever visited. This is more persistent than a browser cookie, more resistant to clearing, and invisible to most users.

How EUI-64 Works in Detail

Consider a network interface with the MAC address 00:1A:2B:3C:4D:5E. The EUI-64 process proceeds as follows:

1. Split the MAC in half: 00:1A:2B and 3C:4D:5E
2. Insert FF:FE in the middle: 00:1A:2B:FF:FE:3C:4D:5E
3. Flip bit 6 of the first byte: 00 in binary is 00000000; flipping bit 6 gives 00000010, which is 02
4. Result: 02:1A:2B:FF:FE:3C:4D:5E, written in IPv6 notation as 021a:2bff:fe3c:4d5e

If your router advertises the prefix 2001:db8::/64, your EUI-64-derived address would be 2001:db8::21a:2bff:fe3c:4d5e. Every network you join with this device, and every packet you send from it, carries those same lower 64 bits — permanently identifying your hardware.

RFC 4941: Privacy Extensions for SLAAC

RFC 4941 (updated by RFC 8981) defines Privacy Extensions for Stateless Address Autoconfiguration. Instead of deriving the interface identifier from the MAC address, the host generates a cryptographically random 64-bit value. This random value becomes the interface identifier for a temporary address.

The temporary address has a limited lifetime. RFC 4941 defines two relevant parameters: TEMP_VALID_LIFETIME (the total time the address remains valid, defaulting to 1 day) and TEMP_PREFERRED_LIFETIME (the time the address is preferred for new connections, defaulting to a few hours less than the valid lifetime). Before a temporary address expires, the host generates a new random identifier and creates a fresh temporary address. Connections in progress on the old address continue until they close normally, while new connections use the new address.

The practical result: your outbound IPv6 address changes every few hours to every day, preventing any single party from building a persistent cross-session profile from your IP address alone.

OS Support and Default Behavior

Privacy Extensions are enabled by default on all major operating systems for client devices:

• Windows: Privacy Extensions are enabled by default since Windows Vista. You can verify with netsh interface ipv6 show privacy. The system maintains both a stable address (for inbound connections) and one or more temporary addresses (for outbound connections).
• macOS and iOS: Privacy Extensions are on by default. macOS additionally implements RFC 7217 stable privacy addresses for the stable (non-temporary) component, meaning the stable address is randomized but consistent per-network rather than based on the MAC address.
• Android: Android has used random interface identifiers since Android 8.0. The randomization is per-network — the same network gets the same random identifier unless the user resets it.
• Linux: The kernel supports Privacy Extensions via the net.ipv6.conf.all.use_tempaddr sysctl. Many distributions enable it by default for desktop profiles. Server distributions often leave it disabled, since servers need stable addresses for DNS and connection logging. To enable: sysctl -w net.ipv6.conf.all.use_tempaddr=2.

RFC 7217: Stable Privacy Addresses

RFC 4941 temporary addresses solve outbound tracking but leave a secondary problem: even with temporary addresses, some systems maintain a stable address (for services that need a consistent inbound address) that is EUI-64-derived. RFC 7217 addresses this with Stable Privacy Addresses.

Instead of EUI-64, the stable address is derived by hashing the network prefix, the interface name, a network-specific key, and a secret value stored on the device. The result is an interface identifier that is stable per-network (the same every time you join the same network) but different on different networks. This means your stable IPv6 address on your home network is different from your stable address at the office, defeating cross-network correlation even for the stable address component.

macOS and iOS implement RFC 7217 by default. Recent Linux kernels support it via the stable_secret parameter in /proc/sys/net/ipv6/conf/.

Architecture: How Multiple Addresses Coexist

A modern device on an IPv6 network typically maintains several addresses simultaneously on each interface:

• Link-local address (fe80::/10): Used for communication within the local segment (neighbor discovery, router discovery). Never routed beyond the local link. Often EUI-64 derived since it never leaves the local network.
• Stable global unicast address: Used for inbound connections and services needing a consistent address. Generated via RFC 7217 on modern clients, or EUI-64 on older implementations.
• Temporary global unicast address(es): Generated via RFC 4941. Used for all outbound connections by default. Rotates every few hours to days.

The host's address selection algorithm (RFC 6724) prefers temporary addresses for source address selection when initiating outbound connections, while the stable address handles inbound connections from parties who already know it (e.g., a server you previously connected to).

EUI-64 vs Privacy Extensions Comparison

Common Misconceptions

Privacy Extensions make your IPv6 address completely anonymous

The interface identifier rotation prevents hardware tracking, but the network prefix (upper 64 bits) still identifies your ISP and approximate geographic region — the same information visible in any IPv4 address. Your ISP can still correlate your IPv6 prefix to your account. Privacy Extensions prevent cross-network and cross-session correlation by third parties; they do not hide your ISP assignment or location from parties with access to BGP routing data.

EUI-64 is still widely used on modern devices

EUI-64 as the default for client devices is effectively obsolete. Windows has used Privacy Extensions since Vista (2007). iOS adopted random addresses years ago. Android switched in Android 8.0 (2017). A device generating EUI-64 addresses for internet-facing traffic is either very old, running a server OS with default settings, or running a misconfigured client installation. The IEEE also stopped guaranteeing MAC address uniqueness in 2017, making EUI-64's uniqueness guarantee less certain on newer hardware that generates locally administered MAC addresses.

Disabling Privacy Extensions improves connection stability

Some network administrators disable Privacy Extensions on the theory that changing addresses break connections. In practice, RFC 4941 handles this gracefully: active connections continue using the address they started with until they close. Only new connections use the new temporary address. Disabling Privacy Extensions for stability reasons trades a real privacy benefit for a problem that does not actually occur in normal operation.

IPv6 privacy extensions and MAC randomization are the same thing

They are complementary but separate mechanisms. MAC randomization (supported in iOS, Android, and Windows 10+) changes the MAC address used in Layer 2 frames when probing or connecting to Wi-Fi networks, preventing tracking at the local network layer. IPv6 Privacy Extensions change the interface identifier in the Layer 3 IPv6 address, preventing tracking at the IP routing layer. Both are needed for full protection: MAC randomization stops local tracking; Privacy Extensions stop remote tracking.

Pro Tips

• On Linux servers that make outbound connections (email relays, crawlers, API clients), enable Privacy Extensions with sysctl -w net.ipv6.conf.eth0.use_tempaddr=2 to prevent the server's MAC address from appearing in remote server logs via EUI-64 identifiers.
• Verify which address your browser uses for outbound connections by visiting an IP detection page — if you see a temporary address (one that differs from what ip -6 addr show lists as your stable address), Privacy Extensions are working.
• For servers that need stable inbound addresses, configure a specific static IPv6 address rather than relying on SLAAC. This gives you full control over the address without depending on EUI-64 stability.
• If you manage a network and want to log stable identifiers for access control, use DHCPv6 with recorded assignments rather than relying on EUI-64 addresses — DHCPv6 gives you explicit records while allowing client privacy extensions to function normally.
• Check whether your VPN passes IPv6 traffic. If your VPN only tunnels IPv4, your real IPv6 address — including any Privacy Extension temporary address — leaks to every dual-stack destination you visit.
• On Android, each saved Wi-Fi network can be configured to use a randomized MAC. Combine this with IPv6 Privacy Extensions for layered protection that defeats both local (Layer 2) and remote (Layer 3) tracking.

Understanding EUI-64 and Privacy Extensions is essential for anyone serious about IP-layer privacy. The mechanism is subtle but the implications are significant — a permanent hardware identifier in every packet is a tracking surface that most users never knew existed. Verify your current IPv6 address and check if Privacy Extensions are active.