IPv4 addresses are scarce (about 4.3 billion total) and almost always shared, via NAT, across every device on a home or office network. Your laptop, phone, and smart TV all appear to the internet as the same IPv4 address, which incidentally provides a privacy side effect nobody designed for: no external server can distinguish your devices by address alone.
IPv6 solved the scarcity problem completely (2128 addresses, enough for roughly 340 undecillion unique addresses) but in doing so removed the accidental privacy shield. Every device could now get its own fully routable, globally unique address. The question was how that address gets generated, and the original answer created a much worse problem than the one it solved.
SLAAC and the EUI-64 Problem
Stateless Address Autoconfiguration (SLAAC), defined in RFC 4862, lets a device generate its own IPv6 address without a DHCP server, by combining a 64-bit network prefix (announced by the router) with a 64-bit interface identifier. The original method for generating that interface identifier, specified in RFC 4291's Appendix A, was called EUI-64: take the device's 48-bit MAC address, split it in half, insert the fixed value FFFE in the middle, and flip one bit. The MAC address, a hardware identifier burned into the network card at manufacture, was now embedded directly in every IPv6 address the device generated, on every network it joined.
A MAC-derived interface identifier doesn't change when you switch networks. Connect your laptop to your home Wi-Fi, then a hotel network in another country, then a conference network, and the last 64 bits of your IPv6 address stay identical across all three, even though the network prefix changes. Any server, ad network, or analytics script logging IPv6 addresses could correlate your activity across completely unrelated networks using nothing but that fixed suffix, without needing cookies, fingerprinting, or any other tracking mechanism.
RFC 4941: Temporary Addresses
The IETF published RFC 3041 in 2001 (obsoleted and superseded by RFC 4941 in 2007, then further refined by RFC 8981 in 2021) specifically to fix this. The mechanism, commonly called "IPv6 privacy extensions," generates a randomized interface identifier instead of a MAC-derived one, using an MD5-based algorithm seeded with a locally stored random value and the previous identifier, then rotates it on a schedule (RFC 8981's default is a 24-hour preferred lifetime with a 7-day maximum valid lifetime, though implementations vary).
Critically, privacy extensions generate temporary addresses used for outbound connections while keeping a stable address for services that need to reliably reach the device, like a home server accepting inbound connections. This split matters: the temporary address is what an external tracker sees when you browse the web; the stable address exists mainly for the device's own inbound-reachable services.
Where Each OS Landed
| Platform | Default behavior |
|---|---|
| Windows | Randomized interface identifiers by default since Windows 10 (moved away from EUI-64 entirely, not just via rotating temporary addresses). |
| macOS / iOS | Privacy extensions (RFC 4941 style) enabled by default since roughly 2013; toggle exists in Wi-Fi settings as "Private Address." |
| Android | Randomized addressing enabled by default since Android 10, paired with per-network randomized MAC addresses at the link layer. |
| Linux | Supported via net.ipv6.conf.*.use_tempaddr sysctl, but historically off by default on many distributions; NetworkManager now enables it by default on most modern releases. |
What Privacy Extensions Don't Fix
Randomizing the IPv6 suffix closes the specific EUI-64 hardware-tracking hole, but it doesn't make you untraceable at the network layer. The 64-bit network prefix is still tied to your ISP-assigned block, which is a coarser but still real signal (it usually identifies your ISP and, within a day or two, narrows to your household). A tracker correlating requests within a single browsing session can still often link them by other means, TLS fingerprinting, cookies, or browser fingerprinting, regardless of what the IP address does. And devices that keep a stable address for legitimate reachability reasons (a home NAS, a self-hosted service) are, by design, not rotating, because rotation would break the ability to reach them.
Privacy extensions solve the specific problem of "does my address secretly contain a permanent hardware fingerprint." They were never meant to solve, and don't solve, the broader question of network-layer traceability.
Checking Your Own Configuration
On most desktop operating systems you can check whether privacy extensions are active by comparing your device's IPv6 address to its MAC address: if the interface identifier (the last 64 bits) contains FFFE in the middle two bytes, it's the old EUI-64 format and your device is exposing a hardware-derived, permanently trackable suffix. If it looks essentially random with no relationship to the MAC address, privacy extensions are working. On Linux, ip addr show combined with sysctl net.ipv6.conf.all.use_tempaddr confirms the setting directly; on Windows and macOS the equivalent check is in the network adapter's advanced settings or Wi-Fi privacy toggle respectively.
It's a small protocol detail, but it's a good example of how privacy problems in networking tend to arrive as unintended side effects of solving a completely different problem (in this case, address scarcity), and get fixed years later once someone works out what the side effect actually exposed.