How do IPv6 SLAAC and EUI-64 addressing actually work?

Why IPv6 needed a different address-assignment model

IPv4 networks mostly rely on DHCP to hand out addresses, or NAT to let many devices share one public address — workarounds largely necessitated by IPv4’s limited address space. IPv6’s address space is large enough (2^128 addresses) that neither workaround is strictly necessary, which opened the door to a different model: Stateless Address Autoconfiguration (SLAAC), defined in RFC 4862, where a device generates its own complete, globally routable address without asking a server for one. A router periodically advertises the network’s prefix — almost always a /64, as covered in our guide on subnet and CIDR basics — and every device on that network independently combines the advertised prefix with a 64-bit identifier it builds itself to form a full 128-bit address.

How the 64-bit interface identifier gets built: EUI-64

The second half of a SLAAC address — the interface identifier — has to come from somewhere, and one of the original, standardized ways to generate it is the modified EUI-64 format, specified in RFC 4291’s IPv6 addressing architecture. The process is mechanical: take the device’s 48-bit MAC address, split it into two 24-bit halves, insert the fixed 16-bit value fffe between them to pad the result to 64 bits, then flip one specific bit (the universal/local, or “u/l,” bit) to mark the identifier as derived this way. The result is a 64-bit value that’s deterministic and reproducible from the MAC address alone — the same NIC always produces the same EUI-64 identifier, on any network.

This matters because of where the raw material comes from. A MAC address’s first three bytes are its OUI (Organizationally Unique Identifier), assigned by the IEEE to the manufacturer that requested it — the same identifier our MAC OUI glossary entry covers. An EUI-64-derived IPv6 address therefore embeds not just a persistent per-device identifier, but one that can often reveal the device’s manufacturer as well, simply by decoding its structure.

Why that’s a meaningful privacy problem

Because a device’s MAC address doesn’t change, an EUI-64-derived interface identifier doesn’t change either, regardless of which network the device joins or how many times it reconnects. Combine that constant 64-bit value with whatever /64 prefix a given network advertises, and the resulting address changes its network portion from place to place but keeps the exact same device-identifying tail every time. That makes it possible, in principle, to recognize the same physical device across completely unrelated networks — home, a coffee shop, a different office — purely from the IPv6 address it generates, without needing cookies, browser fingerprinting, or any cooperation from the device’s software. For a device whose owner has no reason to expect or want that kind of cross-network trackability, this is a real and non-obvious consequence of a mechanism originally designed purely for convenience.

The fix: randomized, temporary addresses

RFC 4941 defines privacy extensions for SLAAC specifically to close this gap: instead of deriving the interface identifier from the MAC address, a device generates a random 64-bit value, uses it as a temporary address for outgoing connections, and periodically replaces it with a new random value on a rotation schedule. This breaks the cross-network and even cross-session linkability that EUI-64 addressing creates, since the identifier a device presents today has no relationship to the one it used yesterday or will use tomorrow. Most modern operating systems — recent versions of Windows, macOS, iOS, Android, and major Linux distributions — now generate these randomized, temporary addresses by default for ordinary outbound traffic, while still being able to fall back to a stable, EUI-64-derived or otherwise fixed address for specific cases like a server that genuinely needs a predictable, reachable address.

What this means in practice

If you inspect a device’s IPv6 address and notice it contains fffe in the middle of its last 64 bits, that’s a strong sign it’s using EUI-64 addressing rather than a randomized temporary address — worth checking on anything you don’t want to be trackable across networks, particularly older IoT devices and embedded hardware, which are more likely to still default to EUI-64 than a modern phone or laptop. AdminKit’s subnet calculator can help you work out the /64 network portion of an address so you can isolate and inspect the 64-bit interface identifier on its own, and the DNS lookup tool lets you check what AAAA (IPv6) addresses a domain or device actually publishes. Regardless of which addressing method a device uses, remember that SLAAC only handles how an address is assigned — it says nothing about whether that device is protected from unsolicited inbound connections, which is a separate concern covered in IPv6 and home devices: why no NAT means a firewall.