How IPv6 SLAAC Works: Autoconfiguration Explained

Stateless Address Autoconfiguration (SLAAC) is the mechanism by which IPv6 hosts configure their own addresses without a DHCPv6 server. A host listens for Router Advertisements from the local gateway, extracts a network prefix, and autonomously generates its own interface identifier to form a complete /128 address. The entire process requires no central allocation server, scales to any network size, and recovers automatically when infrastructure changes.

Router Solicitation and Router Advertisement

SLAAC relies on two ICMPv6 message types defined in RFC 4861 (Neighbor Discovery Protocol). When a host joins a link — because an interface comes up, a device boots, or a cable is plugged in — it immediately sends a Router Solicitation (RS, ICMPv6 type 133) to the all-routers multicast address ff02::2. This is a request: "is there a router on this link? please announce yourself."

Any router present on the link responds with a Router Advertisement (RA, ICMPv6 type 134). Routers also send unsolicited RAs periodically (typically every 200 seconds by default, though operators tune this). The RA contains several critical pieces of information that the host uses to configure itself:

• Prefix Information Option (PIO) — one or more network prefixes, each with an L flag (on-link), A flag (use for SLAAC), valid lifetime, and preferred lifetime
• Default router — the source address of the RA is the router's link-local address, which the host uses as its default gateway
• M flag (Managed) — if set, the host should use DHCPv6 to obtain addresses in addition to or instead of SLAAC
• O flag (Other) — if set, the host should use DHCPv6 to obtain other configuration (DNS, domain search list) but can still use SLAAC for addresses
• MTU option — the link MTU
• RDNSS option (RFC 8106) — one or more recursive DNS server addresses, allowing DNS configuration without DHCPv6
• Router lifetime — how long the router should be used as a default router; zero means "not a default router"

Address Formation: EUI-64

The original SLAAC mechanism (RFC 2462, superseded by RFC 4862) used EUI-64 to derive the interface identifier from the hardware MAC address. EUI-64 is a 64-bit interface identifier that embeds the 48-bit Ethernet MAC address with a specific transformation:

1. Take the 48-bit MAC address, e.g., 00:1a:2b:3c:4d:5e
2. Split it in half: 00:1a:2b and 3c:4d:5e
3. Insert ff:fe in the middle: 00:1a:2b:ff:fe:3c:4d:5e
4. Flip bit 6 of the first byte (the U/L bit): 00 in binary is 0000 0000; bit 6 is the second-least-significant bit, so flipping it gives 0000 0010 = 02
5. Result: 02:1a:2b:ff:fe:3c:4d:5e

The U/L (Universal/Local) bit flip is the most confusing part. In IEEE MAC addressing, bit 6 of the first octet indicates whether the address is universally administered (0) or locally administered (1). EUI-64 flips this bit to indicate that the identifier is derived from a globally unique MAC. The result is an interface identifier that is globally unique as long as the MAC is unique.

Combined with the /64 prefix from the RA, the full SLAAC address is the prefix concatenated with the EUI-64 interface identifier. For prefix 2001:db8:1::/64 and the MAC above, the address would be 2001:db8:1::21a:2bff:fe3c:4d5e.

The privacy problem with EUI-64 is severe: the MAC address is a stable hardware identifier, and embedding it in the IPv6 address means every IPv6 address the host forms on any network reveals the same hardware fingerprint. This enables tracking across networks and time.

Stable Privacy Addresses: RFC 7217

RFC 7217 (Semantically Opaque Interface Identifiers) replaces the EUI-64 with a pseudorandom interface identifier that is stable per network but not globally unique. The algorithm generates the interface identifier as a hash of:

• The prefix received in the RA
• The interface identifier (name or index)
• The network identifier (SSID for Wi-Fi, or a per-network secret)
• A secret key known only to the host
• A counter (incremented if the address is already in use)

The result is that on a given network, the host always generates the same address from the same prefix (stable — useful for logs and access control). But the address is different on every network (no cross-network tracking), and the MAC address is not recoverable from the IPv6 address. RFC 7217 stable privacy is the default on recent versions of Windows (since Windows 10), macOS (since 10.11), and Linux with systemd-networkd.

Temporary Privacy Addresses: RFC 8981

Even with RFC 7217 stable addresses, a host using the same address on a given network over days and weeks is trackable within that network. RFC 8981 (previously RFC 4941) introduces temporary addresses: randomly generated interface identifiers with short preferred lifetimes (typically 24 hours). The host forms these in addition to its stable address and uses them as the source for outgoing connections.

The practical result is that most IPv6 source addresses visible on the internet cycle every day. A server operator sees a different IPv6 address from the same phone each day. The stable address still exists and can be used for inbound connections and services, but the operating system prefers the temporary address for outgoing flows. RFC 8981 is widely deployed — essentially all modern mobile and desktop operating systems implement it by default.

Duplicate Address Detection (DAD)

Before using a SLAAC-derived address, a host must verify that no other node on the link is using the same address. This process is Duplicate Address Detection (DAD), defined in RFC 4862. The procedure:

1. The host configures the address tentatively (it can receive packets for it but not send from it)
2. It sends a Neighbor Solicitation (NS, ICMPv6 type 135) with source address :: (unspecified) and destination the solicited-node multicast address derived from the tentative address
3. It waits one RetransTimer interval (default 1 second)
4. If no Neighbor Advertisement arrives, the address is unique and is promoted to preferred
5. If a NA arrives, the address is a duplicate; the host must not use it and may generate a new one (RFC 7217 uses the counter to try again)

DAD adds a brief delay after interface bring-up. Operators who control the entire attached network and can guarantee address uniqueness may disable DAD for performance reasons (common in data center environments with fully managed IPv6 allocation).

On-Link Determination and the Default Route

The RA tells the host two distinct things that are sometimes confused. The L (on-link) flag in the Prefix Information Option tells the host whether addresses covered by the prefix are on the same link. If set, the host can reach those addresses directly via Neighbor Discovery without going through the router. If not set, the host must send all traffic through the default gateway even to addresses within the prefix.

The default route is implicitly provided by the RA source address — the router's link-local address. Any RA received from a router with a non-zero router lifetime causes the host to install a default route via that router's link-local address. The host can receive RAs from multiple routers and maintain multiple default routes with different preferences.

M/O Flags and SLAAC vs DHCPv6

The M and O flags in the RA control the interaction with DHCPv6:

In practice, pure SLAAC (M=0, O=0) with RDNSS is increasingly common on home and mobile networks. Enterprise deployments often use M=1 for DHCPv6 address assignment, which allows the network to know which host has which address — useful for security logging and DHCP-based access control. The argument for DHCPv6 in enterprise networks mirrors the argument for DHCPv4: operator control and visibility over address assignment.

Android's DHCPv6 Refusal

Android has never implemented DHCPv6 client support for address assignment. Google's position, maintained consistently since IPv6 was first supported on Android, is that SLAAC with RDNSS is sufficient for mobile devices and that DHCPv6 introduces unnecessary complexity and state. This is a pragmatic position for consumer devices but creates operational friction in enterprise environments that rely on DHCPv6 for address tracking and policy enforcement. Enterprise network teams deploying IPv6 on networks with Android devices must plan for SLAAC even if they prefer DHCPv6 — or rely on MAC address tracking at Layer 2 instead of DHCP lease logs.

SLAAC in Practice: Timing and Stability

When a host has both a stable RFC 7217 address and temporary RFC 8981 addresses, the OS presents a preference ordering to applications. The temporary address is preferred as the source for new outgoing connections (via source address selection rules in RFC 6724). The stable address is used when the host acts as a server (bound explicitly to an address), when the application requests a specific address, or for link-local communication.

Address lifetimes are managed by two timer values in the PIO: the preferred lifetime (when the address should stop being used for new connections, but existing flows continue) and the valid lifetime (when the address is fully removed). RFC 8981 temporary addresses have a default preferred lifetime of 24 hours and a valid lifetime of 7 days. This means an ongoing TCP connection can persist for days on a temporary address even after the address stops being preferred for new connections — connections are not abruptly killed when the preferred lifetime expires.

The interaction between SLAAC address churn and long-lived connections is an operational consideration for services that track users by IPv6 source address. A user's apparent address changes daily for outgoing connections but the change is gradual rather than abrupt. Network logging systems should record both the stable and temporary addresses observed from a given device, and ideally correlate them by other means (cookie, session token) for security analysis.

SLAAC Across the Network Stack

SLAAC is a Layer 3 mechanism but it has implications at every layer. At Layer 2, Neighbor Discovery Protocol (NDP) — the IPv6 replacement for ARP — uses solicited-node multicast addresses to resolve IPv6 addresses to MAC addresses on the same link. NDP's Neighbor Solicitation and Neighbor Advertisement messages are the IPv6 equivalent of ARP Request and ARP Reply. A host's SLAAC-configured address is only useful once NDP can map it to a MAC on the local link.

At the firewall and security layer, SLAAC's temporary address behavior complicates per-host policies. A firewall rule permitting traffic from a specific IPv6 address will become ineffective the next day when the host generates a new temporary address from the same prefix. Security appliances that enforce per-host policies in IPv6 environments must either use the /64 prefix granularity (allowing all addresses a host might form from that prefix) or track both the stable and temporary addresses dynamically. The stable RFC 7217 address does not change between sessions on a given network, providing a consistent per-host identifier for policy purposes.

For a complete picture of IPv6 address configuration, SLAAC is one of three methods: SLAAC (this article), DHCPv6 stateful (server assigns specific addresses), and manual configuration. In practice, most end-user devices use SLAAC with privacy extensions. Servers and infrastructure typically use manual configuration or DHCPv6 for operator visibility and stability. The IPv4 vs IPv6 article covers the broader address space and transition implications.

From a BGP and routing perspective, SLAAC addresses are just IPv6 addresses — the mechanism by which an end host chose its address within a /64 prefix is invisible to routing. BGP announces the /48 or /32 prefix belonging to the ISP; the /64 subnets are internal to the operator; the individual /128 host addresses are not visible in the global routing table at all. SLAAC is purely a local-link mechanism between the host and its first-hop router. The consequences of address churn matter for application-layer tracking and for network access control, but they are invisible to the broader routing infrastructure.

Renumbering and Prefix Delegation

One advantage of SLAAC is the ease of renumbering. When a network changes its upstream provider and receives a new IPv6 prefix, the router simply starts sending RAs with the new prefix (and eventually withdraws the old one by setting its preferred lifetime to zero and valid lifetime to a short value). Hosts automatically form new addresses from the new prefix and deprecate the old ones. In contrast, renumbering an IPv4 network requires updating DHCP server configuration, flushing leases, and manually updating static assignments. SLAAC's address formation from router-advertised prefixes makes provider-based renumbering nearly automatic for end hosts.

IPv6 Prefix Delegation (DHCPv6-PD, RFC 8415) extends this further: a home router receives a /48 or /56 prefix from its upstream ISP via DHCPv6-PD, then sub-delegates /64s to each internal LAN and sends SLAAC RAs for those subnets. The end hosts have no awareness of the delegation process — they just receive an RA and configure themselves normally. This is the standard model for residential IPv6 deployment, where the CPE (home router) bridges prefix delegation from the ISP to SLAAC-based configuration of devices on the home network.

Explore It Live

IPv6 addressing and routing are visible in the BGP table. Look up any IPv6 prefix to see its origin AS and path:

• 2001:4860:4860::8888 — Google's IPv6 DNS, formed from a /32 prefix announcement
• 2606:4700:4700::1111 — Cloudflare's IPv6 resolver
• AS15169 — Google's ASN, see the IPv6 prefixes they originate