By Yair Knijn · September 15, 2025

Your IPv6 rollout is leaking MAC addresses, and your privacy review missed it

The network architect signs off on the IPv6 plan: prefix delegation works, router advertisements are clean, hosts get global addresses without a DHCPv6 server in sight. SLAAC is doing its job. What the plan never wrote down is how the interface identifier gets generated, so it took the oldest default in the book, EUI-64. Every host now carries its own hardware MAC, padded with ff:fe in the middle, in plain sight inside a routable address.

Nobody decided this. The absence of a decision is the decision, and it shipped a privacy defect into a network that will run for a decade.

How EUI-64 turns a MAC address into a tracking beacon

An IPv6 address is a 64-bit prefix plus a 64-bit interface identifier. EUI-64 builds that lower half deterministically from the NIC's MAC: split the 48-bit MAC, insert fffe, flip the universal/local bit, done. The prefix changes when the device moves. The interface identifier does not, and that stable lower half is the problem. SIDN, operator of the .nl registry, puts it plainly: that portion of the address stays the same even when the machine connects to a completely different network, so the device can in principle be tracked online wherever it goes in the world.

A laptop on your corporate LAN, then a hotel network, then conference Wi-Fi presents three different prefixes and one identical 64-bit tail. Any passive observer along the path correlates those sessions to a single physical machine, no cookies required. You have published a hardware identifier in every packet that device ever sends.

RFC 8981 and RFC 7217: the two ways to fix it

There are exactly two address-generation schemes that close this, and they solve different halves of the problem. Pick deliberately.

• RFC 8981 generates randomized temporary identifiers that rotate on a schedule, often daily. Good for client devices making outbound connections. The cost is churn: addresses come and go, which complicates logging and ACLs.
• RFC 7217 produces an identifier that is stable within one network but different on every other network. Same address each time the host rejoins your LAN, no MAC leak, no cross-network correlation. This is what you want for servers and managed endpoints that need a reachable, loggable address.

In practice you run both: RFC 7217 as the stable baseline so EUI-64 never gets used, RFC 8981 layered on for outbound client traffic. Modern Windows, macOS, iOS, and Android already enable privacy extensions by default. The gap is on the gear that does not: servers, network appliances, embedded and CPE devices that still fall back to EUI-64 unless told otherwise.

Why the default config is the one that gets audited

EUI-64 leaks because it is silent. No error, no failed handshake, no alert fires when a host derives its address from its MAC. The plan works, so it ships. The finding arrives later, in a DPIA or a privacy review, when someone maps "stable hardware identifier transmitted across network boundaries" onto personal-data tracking and writes it up as a defect you now have to remediate in production.

That is the expensive path. Retrofitting policy across a live IPv6 estate means touching router advertisement flags, host configuration, and every device class that quietly defaulted to EUI-64, then proving the change took. Deciding it once, at design time, costs a paragraph in the plan and a line in your provisioning templates.

Setting and enforcing address-generation policy in IPAM

The policy is one sentence: no production interface generates its identifier from EUI-64; stable hosts use RFC 7217, client devices add RFC 8981. Writing the sentence is easy. Enforcing it across hundreds of subnets and device classes is the part that fails, because nothing in a plain IPv6 deployment inspects the lower 64 bits to tell you a MAC is showing through.

That inspection belongs in your IPAM. Spot IPAM tracks the addresses actually in service across an Environment, so the EUI-64 signature, that ff:fe in the middle of the interface identifier, is something you can flag before a privacy review does, not after. Make the address-generation rule part of how addresses get reviewed, and the silent default stops being the one that ships. See how policy checks fit into address tracking in features.