IPv6 Privacy Extensions: Why Your IPv6 Address Keeps Changing
An IPv6 device with a different address every time it connects isn't broken — privacy extensions (RFC 4941) are at work: the problem with EUI-64, how temporary addresses operate, and what it means for tracking.
Attentive users will notice: in the IPv4 era your IP was always the same, but on IPv6 every lookup returns a slightly different address, with the second half constantly changing. Is something broken? Quite the opposite — a privacy-protecting mechanism is doing its job.
The Problem: IPv6 Addresses Are Too "Honest"
An IPv6 address has 128 bits, and by default the interface identifier (the last 64) is generated by the EUI-64 algorithm: take the NIC's MAC address, insert ff:fe in the middle, and flip the 7th bit.
That creates a problem: a MAC address is globally unique and burned into the hardware. Building your IPv6 address from it means —
- Wherever your device connects, the address suffix stays the same
- Any website can track you across networks via that suffix
- Same suffix on café WiFi and home broadband — a portable ID number you carry everywhere
Fix One: Privacy Extensions (RFC 4941)
The idea behind privacy extensions is straightforward: generate the interface identifier from random numbers instead of the MAC. And not just randomized once — the system periodically generates new "temporary addresses" for outgoing connections and phases the old ones out.
This is exactly the phenomenon you've been observing:
- On each connection / at intervals, the second half of the temporary address changes
- Enabled by default on Windows / macOS / Android / iOS
- Websites see the temporary address; the MAC-derived "permanent address" is used only on the local link
The cost is reduced address stability from the server's perspective. Legitimate sites won't notice at all; only "the parties that want to track you continuously" are affected.
Fix Two: SLAAC Randomization (RFC 7217)
The more modern approach is Stable Privacy Addresses: the interface identifier is still stable (handy for firewall rules and log auditing), but it's computed as a hash of the address prefix + interface identity + a secret key — change networks and the hash input changes, so the suffix changes too. Stable within each network, unlinkable across networks.
Modern operating systems usually combine the two: the stable SLAAC address handles "being connected to" (incoming traffic), temporary addresses handle "reaching out" (outgoing connections), and only the latter is exposed externally.
How to Check Your Own Device
Open the IPchase homepage and, if it shows an IPv6 address, look again a few hours later:
- The second half changed → privacy extensions are working
- The first half (the prefix) unchanged → the carrier's assigned range is stable, which is normal (the prefix comes from the router)
- Nothing changed → privacy extensions may be disabled (enterprise environments sometimes turn them off for auditing)
The Limits of Privacy Extensions: What They Protect and What They Don't
Temporary addresses rotate the "address suffix," defending against identity correlation across networks and over time. But the protection has clear boundaries:
- The range's ownership doesn't change: the first half remains the carrier-assigned global routing prefix — geolocation and carrier information are on full display
- Correlatable within a network: on the same WiFi, your temporary address stays stable between rotations; devices sharing a prefix can be grouped as "one household"
- Rotation frequency isn't anonymity: temporary addresses rotate every few hours to a day by default, but never within a single session — sites can track per session just fine
- Firewall exceptions pin you down: for inbound connections some systems receive on the "stable address" — if you've put a specific address into DDNS or firewall rules, that address stops rotating
In other words, privacy extensions fix the most glaring flaw in IPv6's design (MAC-based correlatability), but that's where IP-layer privacy ends. Finer-grained tracking relies on cookies and browser fingerprinting — the main reason "they still recognize you after you change IPs."
Trade-Offs in Operations
For site operators, privacy extensions cut both ways:
- Logs and risk control: one user's requests within an hour may come from three different IPv6 addresses; statistics and risk models aggregated by exact IP distort, and aggregating by /64 prefix gets closer to "user" granularity
- The allowlist problem: when letting users whitelist IPs, IPv6 users can hardly use exact addresses — either allow the prefix (widening the authorization) or steer them toward stable addresses or an account system
- Anti-scraping: attackers rotating temporary addresses render exact bans useless, but that also raises the false-ban risk — prefix bans can catch innocent users in the same household
Lessons for Site Operators
If your site does "IP banning," in the IPv6 era ban by prefix (/48 or /64) rather than exact address — a user's requests may come from different addresses within the range, and an exact ban bans nothing.
Conversely, don't count on exact IPv6 addresses for user identification either — cluster by prefix or rely on entirely different signals (cookies, fingerprints).
Summary
- Default IPv6 addresses embed MAC information — a trackable identifier you carry everywhere
- Privacy extensions use regularly rotated random temporary addresses for outgoing connections, on by default in modern systems
- The constantly changing second half is privacy protection at work, not a malfunction
- Design banning and identification logic around prefixes, not exact IPv6 addresses
Want to see your current IPv6 address and its geolocation? IPchase detects it directly — and catch up on the basics of IP addresses.
Check your own network: run a full disguise check on the homepage, or try the fingerprint test.