DHCPv6 vs SLAAC: How IPv6 Hands Out Addresses, Explained

Here is DHCPv6 vs SLAAC explained without the RFC headache: SLAAC lets each device build its own address from a prefix the router advertises, while DHCPv6 hands addresses out from a server the way IPv4 DHCP does. They are not rivals you must choose between — on most home networks they run together, and the Router Advertisement decides who does what. Get the flags right and every device, including the awkward ones, gets an address.

This is the piece of IPv6 that trips up people who are otherwise comfortable with networks, because IPv4 only ever gave them one way to assign an address: DHCP. IPv6 gives two, plus a hybrid, and the behavior is controlled by three flags in a packet most people never look at. I run a mix across my VLANs depending on what is on each, so let me lay out exactly how each works and when I reach for it.

SLAAC: The Device Builds Its Own Address

SLAAC stands for Stateless Address Autoconfiguration (RFC 4862), and “stateless” is the key word — no server keeps a table of who has what. The router periodically sends a Router Advertisement (RA) announcing the /64 prefix on that link. Each device takes that prefix, generates its own interface identifier for the back half, and assembles a complete address on its own. No lease, no server, no negotiation.

The back half — the interface identifier — used to be derived from the MAC address (EUI-64), which made a device trackable. Modern operating systems instead use privacy extensions (RFC 8981) that randomize and rotate it. SLAAC’s strength is that every IPv6 client supports it, which is exactly why it is the safe default. Its weakness is that the router does not know or record which device took which address, so there is no central lease list to audit. If you want stable, logged assignments, SLAAC alone will not give you that.

DHCPv6: A Server Hands Out Addresses

DHCPv6 works the way IPv4 DHCP trained you to expect: a server holds a pool, a client asks, the server leases an address and records it. This is stateful DHCPv6 (RFC 8415) — the server keeps state about every lease, which gives you a central list of who has what, predictable assignments, and the ability to reserve a fixed address for a specific device. For a homelab where you want your NAS or a server pinned to a known address and logged, that auditability is genuinely useful.

There is also a stateless DHCPv6 mode, which is the one people forget. In stateless mode DHCPv6 does not hand out addresses at all — the device still gets its address via SLAAC — but DHCPv6 supplies options like DNS server addresses and search domains. This matters because not every client reads DNS from the RA’s RDNSS option, so stateless DHCPv6 is how you reliably push DNS settings while letting SLAAC handle addressing.

The Three RA Flags That Control Everything

The Router Advertisement carries three flags, and together they decide whether a device uses SLAAC, DHCPv6, or both. Understanding these is the whole game. The A flag (Autonomous) on a prefix tells devices “build your own address from this prefix via SLAAC.” The M flag (Managed) tells devices “get your address from DHCPv6.” The O flag (Other) tells devices “get other settings, like DNS, from DHCPv6.”

The common combinations: A on, M off, O off is pure SLAAC. A on, M off, O on is SLAAC for addresses plus stateless DHCPv6 for DNS — my default for general VLANs. A off, M on is pure stateful DHCPv6. And A on with M on is both, which most clients handle but is rarely what you actually want. Set these deliberately, because a contradictory combination is how you end up with devices that have no address or no DNS.

DHCPv6 vs SLAAC at a Glance

The Android Problem Nobody Warns You About

Here is the single most important practical fact in this whole topic: Android does not implement stateful DHCPv6. It has never shipped a DHCPv6 client for address assignment, by deliberate design decision. If you configure a VLAN for pure stateful DHCPv6 (A off, M on) because you want logged leases, every Android phone and tablet on that segment will get no IPv6 address at all and silently fall back to IPv4.

This bites people constantly. They build a clean DHCPv6-only network, test it on a laptop, see it working, and only later discover half the household’s phones never got IPv6. The fix is simple once you know: keep the A flag on so SLAAC works, and use DHCPv6 in stateless mode (O flag) for DNS options, or accept that any VLAN with Android clients needs SLAAC. On my KIDS and GUEST VLANs, which are full of phones, I run SLAAC plus stateless DHCPv6 and never think about it again.

How to Tell Which Mode Your Network Is Using

You do not have to guess which flags are set — you can read them straight off the wire. On a Linux client, rdisc6 eth0 (from the ndisc6 package) sends a Router Solicitation and prints the Router Advertisement that comes back, including the “Stateful address conf.” (the M flag) and “Stateful other conf.” (the O flag) lines. If both read No and you still get an address, you are on pure SLAAC. radvdump does the same passively if you would rather watch the periodic RAs roll in.

From the client side, list the interface addresses (ip -6 addr on Linux, ipconfig on Windows) and count the globals: a stable one plus a rotating temporary one is the SLAAC-with-privacy-extensions signature, while a single global paired with a DHCPv6 lease points at stateful mode. When I bring a new VLAN up I run rdisc6 from a laptop on it before trusting any phone to it — it takes ten seconds and tells me immediately whether the A, M, and O flags match what I actually set in OPNsense.

One more tell worth internalizing: if a device pulls an address but cannot resolve names, the addressing flags are fine and it is DNS that is not arriving — a different failure from “no address at all.” Splitting those two symptoms apart saves real time, because the fix for a missing address (the A or M flag) is nothing like the fix for missing DNS (the O flag, the RDNSS option, or a resolver that actually answers on IPv6).

What I Actually Run On Each Segment

My approach is per-VLAN rather than one-size-fits-all. General segments with phones — LAN, KIDS, GUEST — get SLAAC plus stateless DHCPv6 (A and O flags), which gives universal compatibility and reliable DNS. Segments where I want predictable, logged addressing and have no Android clients — parts of the LAB or a server VLAN — can use stateful DHCPv6 for that audit trail. The IOT VLAN gets SLAAC because cheap devices handle it most reliably, and the egress rules do the heavy lifting there anyway.

If you are mapping these onto a segmented network, the per-interface RA and DHCPv6 settings are exactly what the OPNsense IPv6 configuration guide walks through, and the overall design sits inside the IPv6 home network setup guide. If you have not decided whether to enable IPv6 at all yet, the honest cost-benefit take is the place to start. And whichever you choose, your recursive DNS setup is what those clients should ultimately point at.

Frequently Asked Questions

Keep Building

• IPv6 at Home, Demystified: A Practical Setup Guide
• Should You Even Enable IPv6 at Home?
• IPv6 on OPNsense: WAN, LAN, and Per-VLAN Configuration
• Unbound Recursive DNS for the Home Network