Configuring a Stateless DHCPv6 Server on a Cisco Router

Stateless DHCPv6 does one job and one job only: it hands out supplementary configuration — DNS servers, a domain name — to clients that have already generated their own IPv6 address through SLAAC entirely on their own. It never assigns an address itself, under any circumstances. That distinction shapes every command in this setup, and it’s worth keeping in mind throughout, since it’s the exact detail that trips people up when moving from DHCPv4’s habits to IPv6.

This guide covers the full server configuration, the O-flag/M-flag mechanics that actually trigger stateless mode, configuring a router as a stateless client, and verification on both sides.

Before Anything Else: Enable IPv6 Unicast Routing

Router(config)# ipv6 unicast-routing

Stateless DHCPv6 itself doesn’t strictly require this command, but Router Advertisements do — and RAs are what tell clients to use stateless DHCPv6 in the first place. Without unicast routing enabled, the router won’t process ICMPv6 correctly, which breaks the RA mechanism the entire stateless DHCPv6 flow depends on. This is effectively a prerequisite even though it isn’t technically part of the DHCPv6 configuration itself.

Step 1: Create the DHCPv6 Pool

Router(config)# ipv6 dhcp pool DHCPV6-POOL
Router(config-dhcpv6)#

This creates the pool and enters DHCPv6 pool configuration mode, marked by the (config-dhcpv6)# prompt.

Step 2: Configure Pool Parameters

Router(config-dhcpv6)# dns-server 2001:ABC1:B001:1::20
Router(config-dhcpv6)# domain-name networkustad.com
Router(config-dhcpv6)# exit

Note what’s not here: there’s no address prefix command for the pool itself in a stateless setup, because the server never assigns an address of its own — the client already has one from SLAAC by the time it ever asks the server for anything else. The RA message (separate from this pool entirely) carries the prefix, prefix length, and default gateway; the DHCPv6 pool only needs to supply what the RA doesn’t — DNS server addresses and a domain name here, though other options can be added to the pool the same way if needed.

Step 3: Bind the Pool to an Interface and Set the O Flag

Router(config)# interface gigabitEthernet 0/1
Router(config-if)# ipv6 address 2001:ABCD:1::1/64
Router(config-if)# ipv6 nd other-config-flag
Router(config-if)# ipv6 dhcp server DHCPV6-POOL
Router(config-if)# exit

Two things happen here that matter independently of each other, and it’s worth understanding both separately rather than treating them as one combined step:

• ipv6 dhcp server DHCPV6-POOL binds the pool to this interface — when a DHCPv6 request arrives here, the router replies using this pool’s configuration.
• ipv6 nd other-config-flag sets the O flag to 1 in this interface’s Router Advertisements. This is the actual trigger that tells clients “stateless DHCPv6 is available here, come get your extra options.” Without this command, the RA’s O flag stays at its default of 0, and clients have no signal to ever attempt a stateless DHCPv6 exchange at all — the pool could be perfectly configured and never get used.

The M flag stays at its default of 0 throughout this setup — setting it to 1 would signal stateful DHCPv6 instead, telling clients to get their address from the server rather than generating one via SLAAC. Stateless configuration deliberately leaves M alone.

Full Worked Example

DHCPv6_SERVER# configure terminal
DHCPv6_SERVER(config)# ipv6 unicast-routing
DHCPv6_SERVER(config)# ipv6 dhcp pool DHCPV6-POOL
DHCPv6_SERVER(config-dhcpv6)# dns-server 2001:ABC1:B001:1::20
DHCPv6_SERVER(config-dhcpv6)# domain-name networkustad.com
DHCPv6_SERVER(config-dhcpv6)# exit
DHCPv6_SERVER(config)# interface gigabitEthernet 0/1
DHCPv6_SERVER(config-if)# ipv6 address 2001:ABCD:1::1/64
DHCPv6_SERVER(config-if)# ipv6 nd other-config-flag
DHCPv6_SERVER(config-if)# ipv6 dhcp server DHCPV6-POOL
DHCPv6_SERVER(config-if)# exit
DHCPv6_SERVER(config)# exit
DHCPv6_SERVER# write memory

Configuring a Cisco Router as a Stateless DHCPv6 Client

DHCPv6 clients are typically end-user devices — laptops, phones, tablets — not routers. But a router can be configured as one, which is useful for lab work and for understanding the client side of this exchange.

A router needs a link-local address before it can send or receive any IPv6 messages at all, RS and DHCPv6 included. ipv6 enable creates one without requiring a global unicast address first — appropriate here, since the whole point of this configuration is to get the global address dynamically, not supply one manually.

DHCPv6_Client(config)# interface gigabitEthernet 0/1
DHCPv6_Client(config-if)# ipv6 enable
DHCPv6_Client(config-if)# ipv6 address autoconfig
DHCPv6_Client(config-if)# exit

ipv6 address autoconfig enables SLAAC — this is what generates the client’s actual global unicast address, combining the prefix from the router’s RA with a self-generated interface ID. If that RA’s O flag is set to 1, the client will also reach out to a stateless DHCPv6 server for supplementary options like DNS — but the address itself is entirely a SLAAC product, never something the DHCPv6 exchange provides in stateless mode. Keeping that distinction straight matters: it’s easy to assume “DHCPv6 client” means DHCPv6 assigns the address, and in stateless mode specifically, it never does.

Verifying the Server

DHCPv6_SERVER# show ipv6 dhcp pool
DHCPv6 pool: DHCPV6-POOL
  DNS server: 2001:ABC1:B001:1::20
  Domain name: networkustad.com
  Active clients: 0

“Active clients: 0” here is expected, not a problem. Stateless DHCPv6 doesn’t maintain client state the way a stateful server or DHCPv4 server does — the server simply answers each INFORMATION-REQUEST message as it arrives without tracking bindings anywhere, so this counter staying at zero forever doesn’t mean anything is actually broken.

DHCPv6_SERVER# show running-config | section dhcp

Confirms the full DHCPv6-related configuration in one place — pool contents, the interface binding, and the flag settings together.

Verifying the Client

DHCPv6_Client# show ipv6 interface gigabitEthernet 0/1

Look for “Stateless address autoconfig enabled” and a populated global unicast address in the output — together these confirm SLAAC actually completed successfully.

DHCPv6_Client# debug ipv6 dhcp detail

Shows the DHCPv6 messages exchanged between client and server in real time — for a stateless client, that means watching for INFORMATION-REQUEST going out and the corresponding REPLY coming back with the DNS and domain-name options. This is the fastest way to confirm the O flag is actually being seen and acted on, rather than just configured and assumed to be working.

Stateless vs. Stateful DHCPv6 Server Config, Side by Side

Seeing the two configurations laid out next to each other makes the structural difference concrete — the stateful version needs an address prefix directly in the pool itself, and it sets the M flag instead of relying only on the O flag the way the stateless version does.

	Stateless	Stateful
Pool needs address prefix?	No — SLAAC handles addressing	Yes — the pool assigns the actual address
Relevant ND flag	ipv6 nd other-config-flag (O=1)	ipv6 nd managed-config-flag (M=1)
Client message	INFORMATION-REQUEST	REQUEST
What the client already has by the time it asks	A SLAAC-generated address	Nothing — it’s asking for the address itself
show ipv6 dhcp pool active clients	Typically stays at 0 (stateless)	Reflects real bindings, since state is tracked

This is also a useful gut check when troubleshooting a configuration someone else built: if show ipv6 dhcp pool on a supposedly-stateless server shows non-zero active clients being tracked persistently over time, or the pool has an address prefix configured at all, something has drifted toward stateful behavior somewhere along the way — worth double-checking the flag configuration actually matches the mode the network design intended.

Worked Scenario: DNS Settings Never Arrive

This is a composite scenario built to illustrate a common misconfiguration, not a specific reported incident.

An administrator configures a stateless DHCPv6 pool with DNS and domain-name options, binds it with ipv6 dhcp server DHCPV6-POOL, and confirms clients are picking up correct global unicast addresses via SLAAC without any apparent issue whatsoever. But no client ever receives the DNS server address — every single client falls back to whatever DNS it had configured manually beforehand, or none at all.

Checking show ipv6 interface on the server-facing interface reveals the problem immediately upon inspection: the O flag in outgoing Router Advertisements is still sitting at 0. The administrator configured the pool and bound it to the interface correctly, but never actually ran ipv6 nd other-config-flag — so nothing in the RA ever told clients that a stateless DHCPv6 server was even available on this segment to ask.

This is worth internalizing as a general pattern beyond just this scenario: the pool and the binding control what the server has to offer, but the O flag is what actually controls whether clients ever think to ask for it in the first place. A perfectly configured pool that nothing ever queries is functionally identical to having no pool configured at all — the two failure modes look completely different in the configuration but produce the exact same symptom on the client side. Running ipv6 nd other-config-flag on the interface resolves it immediately in this scenario — within moments, debug ipv6 dhcp detail on a client shows an INFORMATION-REQUEST going out and a REPLY coming back with the DNS server address finally populated correctly.

Troubleshooting Stateless DHCPv6

Symptom	Likely Cause	Fix
Client gets a SLAAC address but never picks up DNS/domain settings	O flag not set on the server’s interface	Confirm ipv6 nd other-config-flag is applied; check with show ipv6 interface for the O flag status in outgoing RAs
Server pool looks correct but nothing seems to be requesting from it	Pool not bound to the correct interface	Confirm ipv6 dhcp server <pool-name> is on the interface actually facing the clients
Client never gets even a SLAAC address	ipv6 unicast-routing not enabled on the server-side router, breaking RA processing	Enable ipv6 unicast-routing and confirm RAs are actually being sent
Client appears stuck before even attempting DHCPv6	Missing link-local address on a router configured as a client	Confirm ipv6 enable (or a configured global address) has actually created a link-local address on the interface

FAQs

What is stateless DHCPv6?

A mode where the client generates its own IPv6 address via SLAAC, and DHCPv6 is used only to supply supplementary configuration — DNS servers, domain name — that SLAAC and the RA don’t provide on their own.

Which flags control stateless DHCPv6?

The O flag set to 1 tells clients that supplementary options are available from a stateless DHCPv6 server. The M flag stays at 0, since setting it to 1 would signal stateful DHCPv6 instead, where the server assigns the address itself.

How do you bind a DHCPv6 pool to an interface?

ipv6 dhcp server <pool-name> in interface configuration mode. This is what makes the router actually respond to DHCPv6 requests arriving on that interface using the specified pool.

Does the stateless DHCPv6 server ever assign the client’s IP address?

No — never, in stateless mode specifically. The address always comes from SLAAC, generated by the client itself from the RA’s prefix and a self-generated interface ID. The DHCPv6 pool in a stateless setup only ever supplies extra options.

Why does show ipv6 dhcp pool show zero active clients even when everything is working?

Because stateless DHCPv6 doesn’t maintain per-client state — the server answers INFORMATION-REQUEST messages without tracking bindings the way a stateful server or a DHCPv4 server does. A zero count here is normal, not a sign of failure.

What command enables IPv6 autoconfiguration on a client router?

ipv6 address autoconfig, applied in interface configuration mode. It triggers SLAAC to generate the router’s global unicast address, and — if the received RA’s O flag is set — also triggers a stateless DHCPv6 exchange for supplementary options.

If a pool has an address prefix configured, is it still stateless?

Not really — an address prefix in the pool is a stateful-server behavior, since it’s what the server would use to actually assign addresses. A genuinely stateless setup has no reason to configure this; if it’s present alongside ipv6 nd other-config-flag rather than the managed-config flag, it’s worth double-checking which mode the configuration is actually intended to run in.