IPv6 SLAAC vs DHCPv6: An Enterprise Decision Guide

The IPv6 addressing decision is made by two flags in the Router Advertisement and one in each prefix option, and getting them wrong produces a network where some hosts have addresses, some do not, and the ones that do cannot resolve names. DHCPv6 is not simply "IPv4 DHCP for IPv6": it never delivers a default router, Android does not implement it, and the stateless variant exists precisely because address assignment and option delivery are separate problems. This guide explains the flags, the three deployment models, and how to choose.

The three flags

Router Advertisements are always required. Even in a DHCPv6-only network, RAs supply the default route — a host that receives a DHCPv6 address but no RA has an address it cannot use for off-link traffic, because DHCPv6 does not carry default-router information.

Model 1: SLAAC

The host generates a link-local address as soon as the interface comes up, receives RAs containing prefix information, and combines the prefix with an interface identifier to form a global address. Requirements: A=1 and M=0.

The historical objection to SLAAC was the absence of DNS configuration, and RDNSS (RFC 8106) answers it: the router advertises recursive DNS servers and a DNS search list inside the RA. That leaves the real remaining objections as the loss of central address accounting and the absence of a registration step some organisations use as a pseudo-authorisation control.

interface GigabitEthernet0/1
 ipv6 address 2001:db8:10::1/64
 ipv6 nd ra-interval 30
 no ipv6 nd managed-config-flag
 no ipv6 nd other-config-flag
 ipv6 nd ra dns server 2001:db8::53

Model 2: stateful DHCPv6

Set M=1 (the O flag becomes irrelevant, since M already implies option delivery) and install a DHCPv6 server or relay on every link. Optionally set A=0 in the prefix options to stop SLAAC addresses being formed at the same time. The trade-offs:

• Every node must support DHCPv6. Android and ChromeOS do not implement it. If your wireless network must serve Android devices, a DHCPv6-only design cannot work.
• You gain central address management, lease tracking, DNS dynamic updates and a repository of what exists on the network.
• You add a stateful service the network now depends on, plus relay configuration on every segment.

Model 3: SLAAC with stateless DHCPv6

Set O=1 and A=1: hosts auto-configure their own addresses from the RA prefix and obtain options — DNS servers, domain search lists, NTP — from DHCPv6. This is the documented middle ground, and it is particularly useful for zero-touch provisioning of access points, IP phones and similar devices: addresses come from the network with no server dependency, while the options that must be centrally managed come from DHCPv6.

Running both together

Setting A=1 and M=1 gives redundancy for mixed-capability estates: hosts that only implement SLAAC still get an address, and hosts that want DHCPv6 options get them. The cost is address bloat — a host ends up with more addresses than under either single model (SLAAC plus a DHCPv6 address, plus privacy-extension addresses), which increases Neighbor Discovery cache pressure on links with many hosts.

If you operate both, make the DNS information identical in RAs and in DHCPv6. A host that receives different resolvers from the two sources can behave unpredictably, and that failure looks like a DNS problem rather than a dual-stack configuration problem.

Prefix delegation: DHCPv6's genuine advantage

DHCPv6 can hand a router a whole prefix rather than one address: assign 2001:db8::/56 and the downstream router subdivides it into /64s autonomously, registering the route upstream. This is how almost every ISP delivers IPv6 to a home or branch router, and it is the one capability with no SLAAC equivalent. For enterprise WAN edges where a CPE must number multiple internal segments, PD is usually the deciding argument.

Renumbering behaviour worth knowing before you switch

• Switching SLAAC → DHCPv6: hosts do not immediately release SLAAC addresses when A is cleared, so turn M on while leaving A on, then stop advertising RAs so the old addresses expire naturally.
• Switching DHCPv6 → SLAAC: some operating systems release DHCPv6 addresses immediately if M is cleared, which causes a visible flap. Keep M=1 while enabling A, and stop the DHCPv6 server from answering renewals so leases lapse instead of being revoked.
• Plan both mechanisms at initial deployment rather than migrating later — renumbering with flag transitions produces unpredictable host behaviour and, at worst, a period with no usable IPv6 connectivity.

Decision summary

1. Consumer-style, Wi-Fi with Android, minimal administration → SLAAC with RDNSS.
2. Strict central address control, no Android, full DDI tooling in place → stateful DHCPv6.
3. Want autonomous addressing plus central options, zero-touch devices → SLAAC + stateless DHCPv6.
4. Mixed estate, tolerating address bloat → both, with identical DNS in RA and DHCPv6.
5. Numbering downstream segments from a delegated prefix → DHCPv6 PD, regardless of the host-addressing model.

For the flag mechanics in more depth see SLAAC, DHCPv6 and RA flags M/O/A explained, and for a vendor implementation see 华为交换机 IPv6 ND/RA 配置.

原文链接：https://www.blueally.com/ipv6-deployment-series-part-6-slaac-vs-dhcpv6/