Early IPv6 addresses baked in your network card's MAC address, making devices trackable across networks. Here's how privacy extensions fixed that.
Early IPv6 address assignment had a privacy flaw baked into the standard itself: a device's address embedded its network interface's MAC address, a value that never changes. That meant the last 64 bits of your IPv6 address stayed identical everywhere you connected — home, a coffee shop, an airport — turning every site and network operator you touched into a place that could recognize your device again, no cookie required. Privacy extensions were designed specifically to close that hole by replacing the fixed identifier with one that rotates over time.
Key Takeaways
- Original stateless address autoconfiguration (SLAAC) derived the last 64 bits of your IPv6 address from your network card's MAC address via a "modified EUI-64" format defined in RFC 4291 — a value that is globally unique and never changes.
- A static interface identifier lets a device be re-identified across every network it joins, even without cookies, since the same 64-bit suffix follows the hardware everywhere.
- Privacy extensions, specified in RFC 8981, generate randomized temporary addresses that rotate on a schedule and are used for outgoing connections instead of the MAC-derived one.
- Modern systems fixed the other half of the problem too: RFC 8064 says nodes should not embed a stable link-layer address in the identifier at all, so even the non-rotating address is now generated by the RFC 7217 method — stable within one network, different on every other.
- Privacy extensions are enabled by default on most modern consumer operating systems, but rotation only hides the interface identifier — your IPv6 network prefix still reveals your ISP and approximate location, the same way an IPv4 address does.
- You can see exactly what your connection currently exposes with BrowserInsight's IP intelligence and fingerprint check tools.
How early IPv6 addresses were built to leak
An IPv6 address is 128 bits, typically split into a 64-bit network prefix (assigned by your ISP or router, identifying the network you're on) and a 64-bit interface identifier (identifying your specific device on that network). Under the original SLAAC scheme, a device generated its interface identifier automatically from its network interface's MAC address using the "modified EUI-64" method defined in RFC 4291: split the 48-bit MAC address in half, insert a fixed FFFE in the middle, and flip one bit. The result is a 64-bit value that is derived entirely from hardware that ships with the device and is never reassigned.
That design was practical for stateless autoconfiguration — no DHCP server needed to hand out addresses — but it had an unavoidable side effect. Because MAC addresses are globally unique and permanent, the resulting interface identifier was too. Move your laptop from your home network to a library to a hotel, and the network prefix in your IPv6 address would change with each new network, but the last 64 bits would stay exactly the same every time. Any site, ad network, or network operator that logged your IPv6 address could match that fixed suffix across completely unrelated sessions and locations, building a persistent identifier that worked like a permanent tracking cookie you never agreed to.
Temporary addresses: how privacy extensions rotate your identity
Privacy extensions, first specified in RFC 4941 and updated by the current standard, RFC 8981, fix this by generating a second kind of address alongside the stable one. Instead of deriving the interface identifier from the MAC address, the operating system generates it from a pseudo-random algorithm seeded with a locally stored value, then periodically discards it and generates a new one.
Each temporary address carries two lifetimes:
- A preferred lifetime — RFC 8981 sets the default at 1 day — after which the address is deprecated: existing connections may keep using it, but new outgoing connections move to a newer address.
- A valid lifetime — RFC 8981 sets the default at 2 days — after which the address is retired entirely and can no longer be used.
Those are the specification's defaults, and they are configurable. The older RFC 4941 defaulted to a full week of valid lifetime, and some implementations still ship that longer value, which is why a temporary address you saw days ago may still be listed on the interface. What matters for tracking is the preferred lifetime, since that governs how often the address a website actually sees changes.
The operating system pre-generates a new temporary address before the current one expires, so there's always a fresh one ready to take over outgoing connections without an interruption. The stable companion address doesn't disappear — it typically stays active for incoming connections and local network services — but with privacy extensions enabled, it's the rotating temporary address that gets used as the source address for the connections you initiate to the outside world, which is exactly where the tracking risk lived.
The other half of the fix: stable addresses stopped using your MAC too
Rotating temporary addresses solved the outgoing-traffic problem, but a device that also configured a MAC-derived stable address was still handing out a permanent identifier on every network it joined. Two later standards closed that gap.
RFC 7217 defines a way to generate a stable interface identifier from a per-device secret key mixed with the network prefix. The result is stable within a given network — so services that need a predictable address still work — but completely different on every other network, which breaks the cross-network correlation that made the EUI-64 scheme a tracking vector in the first place. RFC 8064 then made that the recommendation for everyone: nodes "SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID", and RFC 7217 should be the default method for stable addresses. It updates RFC 4291 and more than a dozen other documents to say so.
The practical consequence is that on a current operating system you usually see two addresses on an interface and neither is derived from your MAC: one per-network stable address and one rotating temporary address. Privacy extensions and RFC 7217 are complementary — the first hides you across sessions, the second hides you across networks.
Checking whether privacy extensions are enabled on your device
Privacy extensions ship enabled by default on most current consumer operating systems — Windows, macOS, iOS and Android all generate and prefer temporary addresses out of the box. Linux is the one where behaviour genuinely varies: the kernel's own use_tempaddr default is off, so whether you get temporary addresses depends on what your distribution's network manager or sysctl defaults set. Server operating systems and minimal Linux configurations are more likely to leave them off entirely, since a server usually wants a stable, predictable address rather than a rotating one.
The most direct way to check is to look at your own address:
- On the command line,
ipconfig /all(Windows) orip -6 addr show(Linux) will list both a "temporary" address and a "permanent"/stable one if privacy extensions are active; macOS shows similar output viaifconfig. - From a browser, BrowserInsight's IP intelligence tool shows the IPv6 address a website actually sees for your current connection, so you can confirm which one is being used for outbound traffic without digging through OS network settings.
If you only ever see one IPv6 address and it looks derived from your hardware (the middle of the interface identifier reads ff:fe), privacy extensions are off, and that device is presenting the same trackable suffix to every network it joins.
The reverse is not a clean result, though: an address without ff:fe is not proof that temporary addresses are in use. Thanks to RFC 7217, a modern stable address is random-looking too. The distinguishing test is whether the address changes — a stable-privacy address stays put for as long as you're on that network, while a temporary one is replaced on its own schedule.
Privacy extensions vs a VPN: what each actually hides
It's easy to assume that a rotating IPv6 address does what a VPN does. It doesn't, and the difference matters. Privacy extensions only randomize the interface identifier — the device-specific half of the address. The network prefix — the half assigned by your ISP — stays exactly the same regardless of how often the interface identifier rotates, and that prefix alone is enough for IP geolocation to place you at roughly the right ISP and region, the same way a plain IPv4 address would. Rotating temporary addresses stop a device from being re-identified by its fixed suffix across sessions; they do nothing to hide which ISP or approximate location you're connecting from.
A VPN works differently: it replaces your entire IP address, prefix included, with the VPN server's address, so both the location signal and any device-specific suffix disappear behind the tunnel's own address. That's also why how websites detect VPNs doesn't involve interface identifiers at all — VPN detection targets the IP as a whole, not the device-tracking angle that privacy extensions were built to close. If you run a tunnel and want to know what it's actually presenting, BrowserInsight's VPN and proxy check tests the IP a site sees against the leak paths that commonly expose the real one.
Comparison: privacy extensions vs a VPN
| IPv6 privacy extensions | VPN | |
|---|---|---|
| What it hides | Device-specific interface identifier (rotates) | Entire IP address, including network prefix |
| What it doesn't hide | ISP and approximate location (network prefix stays fixed) | Nothing by default — it substitutes a different, equally traceable address |
| Enabled by default | Yes, on most consumer OSes | No — requires installing and connecting a client |
| Protects against | Cross-session device re-identification via a static address suffix | IP-based geolocation, ISP visibility, IP-based blocking |
| Rotation | Automatic, on a schedule (hours to days) | Manual — changes only when you reconnect or switch servers |
The two are complementary, not interchangeable: privacy extensions close a specific, low-level tracking vector that most people don't even know exists, while a VPN addresses the broader question of what your IP reveals about who and where you are.
How to check and reduce your exposure
- Confirm privacy extensions are active. Check your OS network settings or command-line output for a "temporary" IPv6 address distinct from a MAC-derived one; enable the setting if it's off (most OSes expose it as "Use temporary addresses" or similar under network/privacy settings).
- See what your connection currently exposes. BrowserInsight's IP intelligence tool shows the live IPv6 (or IPv4) address and network details a website would see for your session right now.
- Remember the prefix is still visible. If ISP-level location exposure is your actual concern rather than cross-session device tracking, privacy extensions alone won't address it — see IP geolocation accuracy for what your network prefix reveals regardless of rotation.
- Layer a VPN if you need the network prefix hidden too. A VPN and IPv6 privacy extensions solve different problems and can run together without conflict.
Frequently Asked Questions
Do IPv6 privacy extensions replace the need for a VPN?
No. Privacy extensions only rotate the device-specific part of your IPv6 address; your ISP-assigned network prefix — the part that reveals your approximate location and provider — stays the same regardless. A VPN replaces the entire address, prefix included.
Are IPv6 privacy extensions on by default?
On most consumer devices and operating systems, yes — Windows, macOS, iOS and Android enable them out of the box. Linux is less uniform: the kernel default is off, so it comes down to your distribution's configuration. Servers and minimal Linux setups often leave them disabled because a stable address is more convenient for those use cases.
How often does the temporary address change?
RFC 8981's defaults are a 1-day preferred lifetime and a 2-day valid lifetime, so a new temporary address is normally generated about once a day and the old one is retired a day or so later. Both values are configurable, and some implementations still carry the week-long valid lifetime from the older RFC 4941, so a retired address can linger on the interface for longer than that.
My IPv6 address has no ff:fe in it — does that mean privacy extensions are on?
Not necessarily. Since RFC 8064, the stable address a device configures is also generated without your MAC address, using the RFC 7217 method, so it looks random too. The absence of ff:fe tells you the address isn't EUI-64-derived; it doesn't tell you the address rotates. Check whether a second, temporary address is present, or whether the address you're presenting changes over time.
Does disabling IPv6 avoid this issue entirely?
Disabling IPv6 removes the interface-identifier tracking vector specifically, but you'll still be identified by whatever IPv4 address and other fingerprinting signals your connection exposes. It isn't a general privacy fix, just a way to avoid this one mechanism.
Conclusion
The MAC-derived interface identifier in early IPv6 addressing was a quiet, protocol-level tracking vector that had nothing to do with cookies or fingerprinting scripts — it followed a device across every network it joined, simply because the address format said so. Privacy extensions close that specific hole by rotating the identifier automatically, and they're on by default almost everywhere that matters today; RFC 8064 finished the job by taking the MAC address out of the stable half as well. What they don't do is hide your ISP or approximate location, since that lives in the network prefix, not the interface identifier — for that layer of exposure, you still need to look at what your IP address as a whole reveals.
Recommended Reading:
