What Is IPv6 SLAAC? The End of the DHCP Server

Self-Configuring Networks: What SLAAC Actually Does

Every time a device joins an IPv4 network, it typically sends a DHCPDISCOVER broadcast and waits for a DHCP server to respond with an address assignment. The DHCP server maintains a lease database, tracks which device holds which address, manages pool exhaustion, and must be available when any device connects. If the DHCP server crashes, new devices cannot get addresses and expired leases cannot be renewed. The centralized dependency is both a single point of failure and a scaling constraint.

IPv6 eliminates this dependency for the common case through Stateless Address Autoconfiguration, defined in RFC 4862. SLAAC allows a device to construct its own globally routable IPv6 address using information advertised by the local router — no central server, no lease database, no pool to exhaust. The device does this in seconds after connecting and verifies its address is unique before using it, all without administrator intervention.

SLAAC is called stateless because no server stores state about which device holds which address. Each device manages its own address independently. The router only needs to advertise the network prefix — the device handles everything else.

The SLAAC Process Step by Step

When a network interface comes up on an IPv6-capable device, the following sequence executes automatically:

1. Link-local address generation: The device immediately generates a link-local address in the fe80::/10 range by appending an interface identifier to the link-local prefix. This address is used for on-link communication and does not require any router contact.
2. Duplicate Address Detection (DAD) on link-local: Before using the link-local address, the device sends a Neighbor Solicitation message asking if any other device on the segment already uses this address. If no response comes within a defined timeout, the address is considered unique and activated.
3. Router Solicitation: With a working link-local address, the device sends a Router Solicitation (RS) message to the all-routers multicast address ff02::2, asking routers to identify themselves and advertise their prefixes.
4. Router Advertisement (RA) reception: The router responds with a Router Advertisement containing the network prefix (e.g., 2001:db8:1::/64), the prefix length, flag bits (M flag for managed/DHCPv6, O flag for other configuration), the router's lifetime, and MTU information.
5. Global address construction: The device takes the advertised 64-bit prefix and appends a 64-bit interface identifier. The interface identifier is either derived via EUI-64 from the MAC address, or generated randomly via RFC 4941 Privacy Extensions (which is the default on modern client OSes).
6. DAD on global address: The device performs Duplicate Address Detection on its newly constructed global address before using it for actual traffic. A Neighbor Solicitation is sent; if no conflict is detected, the address is activated.

The entire process completes in under a second on a properly configured network. The device is ready to send and receive internet traffic without a single packet going to a DHCP server.

The Role of Router Advertisements

Router Advertisements are the engine of SLAAC. They are ICMPv6 messages (type 134) sent by routers either in response to a Router Solicitation or periodically on a configured interval. The RA carries several important fields:

• Prefix Information option: Contains the network prefix and prefix length. The Autonomous flag (A-flag) in this option indicates whether SLAAC should use the prefix for address generation. The prefix is typically /64.
• Router Lifetime: How long this router should be used as the default gateway. A value of 0 means the router is not a default gateway.
• M flag (Managed Address Configuration): When set, the device should use DHCPv6 to obtain its address in addition to or instead of SLAAC.
• O flag (Other Configuration): When set, the device should use DHCPv6 to obtain other configuration information (such as DNS server addresses) even if SLAAC handles the address itself.
• MTU option: Advertises the link MTU so devices can configure Path MTU Discovery correctly.
• RDNSS option (RFC 8106): Distributes DNS server IPv6 addresses directly in the RA, allowing full network configuration without DHCPv6 at all.

Duplicate Address Detection in Detail

DAD is defined in RFC 4862 as a prerequisite to using any IPv6 address. The mechanism uses the Neighbor Discovery Protocol:

1. The device sets its tentative address (it knows the address but does not yet respond to traffic sent to it).
2. The device sends a Neighbor Solicitation with the source address set to the unspecified address :: (indicating a DAD probe) and the target set to the tentative address.
3. The device joins the solicited-node multicast group for the tentative address, which ensures only devices with similar addresses receive the probe.
4. If another device already uses that address, it sends a Neighbor Advertisement in response. The probing device detects the conflict and marks the address as duplicate.
5. If no response arrives within the DAD timeout (usually one second by default), the address is considered unique and activated.

The probability of an address collision with random interface identifiers in a /64 is extraordinarily small — 2⁶⁴ possible interface identifiers means the birthday paradox does not become significant until a network has roughly 4 billion devices, far beyond any practical deployment. DAD is a safety mechanism, not a frequent need.

SLAAC vs DHCPv6: When to Use Each

DHCPv6 Prefix Delegation

A separate but related mechanism is DHCPv6 Prefix Delegation (DHCPv6-PD, RFC 8415). This is used between ISPs and customer routers, not between routers and end devices. Your home router asks the ISP's DHCPv6-PD server for a prefix (typically a /56 or /48) to use on its LAN side. The router then advertises sub-prefixes from this delegated block to each internal subnet via Router Advertisements. End devices on those subnets configure themselves via SLAAC using the sub-prefixes the router advertises. The result is a fully automated chain: ISP allocates prefix to router, router divides it and advertises to subnets, devices self-configure on those subnets.

Common Misconceptions

SLAAC means there is no way to assign specific addresses to devices

SLAAC is not the only option on IPv6 networks. DHCPv6 in stateful mode allows administrators to assign specific addresses to specific devices identified by their DUID (DHCP Unique Identifier). Many networks run SLAAC for general client devices and DHCPv6 for servers and infrastructure that need stable, administrator-controlled addresses. The two coexist on the same network segment.

SLAAC addresses are not globally unique because devices make them up

The global uniqueness of a SLAAC address is guaranteed by the combination of the ISP-allocated network prefix (which is globally unique by the allocation system) and the interface identifier. The interface identifier only needs to be unique within the /64 subnet — and with 2⁶⁴ possible values, collisions are statistically negligible even in large deployments. DAD provides an additional safety check for the rare case of a collision.

SLAAC cannot distribute DNS server addresses

This was a real limitation in early IPv6 deployments, which is why DHCPv6 was often required even on SLAAC networks just to deliver DNS server addresses. RFC 8106 (and its predecessor RFC 6106) defines the RDNSS (Recursive DNS Server) option for Router Advertisements, which allows DNS server addresses to be included directly in the RA. All modern operating systems support RDNSS, making a separate DHCPv6 server unnecessary for most deployments.

SLAAC is less secure than DHCP because there is no central record of who has which address

The lack of a central lease database is a feature, not a bug, for resilience. Security monitoring on IPv6 networks uses different approaches: network flow logging captures all actual traffic regardless of how addresses were assigned; DHCPv6 logging captures only DHCP-assigned addresses anyway; and IPv6 Neighbor Discovery snooping on managed switches can track which MAC-address-to-IPv6-address bindings are active on each port. None of these require SLAAC to be replaced by DHCPv6.

Pro Tips

• Enable the RDNSS option in your router's RA configuration (e.g., radvd on Linux) to distribute DNS server addresses via SLAAC, eliminating the need for DHCPv6 infrastructure on client-only segments.
• Use rdisc6 on Linux to manually trigger a Router Solicitation and see what prefixes and flags the local router is advertising — useful for diagnosing why SLAAC addresses are not generating on a new segment.
• When deploying IPv6 on a new network, start with a /64 prefix per subnet. IPv6 routing is designed around this boundary; SLAAC requires a /64 for the interface identifier space.
• On Linux, check the RA receipt with ip -6 route show — a default route via fe80:: with proto ra confirms the router is advertising successfully and the device accepted the RA.
• For IoT deployments where devices must not reach the internet directly, use ULA prefixes (fc00::/7) with SLAAC internally and handle external connectivity via a NAT64/NPTv6 gateway — you get SLAAC simplicity without exposing every device to the public internet.
• If SLAAC addresses appear with dadfailed status in ip -6 addr show, another device on the segment has the same address. This is extremely rare with random interface identifiers but can happen in misconfigured static address environments.

SLAAC represents a fundamental shift in how network addresses are managed. Understanding its mechanics makes IPv6 deployment straightforward and illuminates why the protocol's designers deliberately moved away from the centralized DHCP model. Check which IPv6 addresses your device has configured right now.