Hands-On Lab: Configuring DHCPv6 Stateful and Stateless Modes

This hands-on lab configures a router as a DHCPv6 server in both stateless mode (providing only DNS information alongside SLAAC) and stateful mode (assigning full addresses), verifying clients behave differently depending on the router advertisement flags set.

DHCPv6 Stateless ConfigurationDHCPv6 Stateful ConfigurationRA Flag Control

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure a router as a DHCPv6 server, first in stateless mode providing only DNS server information alongside SLAAC-derived addressing, then reconfigure to full stateful mode assigning complete addresses, verifying client behavior differs based on the router advertisement's M and O flags.

Lab Purpose

SLAAC, discussed earlier in this series regarding IPv6 addressing, lets a client derive its own address automatically but provides no mechanism for distributing DNS server information or other options. DHCPv6 fills this gap, and can operate in a lightweight stateless mode alongside SLAAC or take over full address assignment in stateful mode — the router advertisement's flags determine which behavior a client adopts.

Lab Topology

R1 ---- Gi0/0: 2001:DB8:I:1::1/64

PC-A: client, will use SLAAC + DHCPv6
      stateless initially, then full
      DHCPv6 stateful later in the lab

Task 1: Configure Basic IPv6 Addressing

Enable IPv6 routing and configure R1's LAN interface.

Task 2: Configure a Stateless DHCPv6 Pool

Configure a DHCPv6 pool providing only DNS server information, with no address range.

Task 3: Enable Stateless DHCPv6 on the Interface

Apply the pool to the interface using the "other-config-flag" (O-flag) rather than the managed flag.

Task 4: Verify PC-A Uses SLAAC for Addressing and DHCPv6 for DNS Only

Confirm PC-A's address comes from SLAAC while its DNS server setting comes from DHCPv6.

Task 5: Reconfigure for Full Stateful DHCPv6

Change the pool to include an address range and enable the managed flag (M-flag) instead, verifying PC-A now receives its full address from DHCPv6.

Solution and Verification

R1(config)# ipv6 unicast-routing
R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 address 2001:DB8:I:1::1/64
R1(config-if)# no shutdown

R1(config)# ipv6 dhcp pool STATELESS-POOL
R1(config-dhcpv6)# dns-server 2001:4860:4860::8888
R1(config-dhcpv6)# domain-name lab.local

-- No "address prefix" statement in this
-- pool -- stateless mode never assigns
-- addresses, only supplementary options

R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 dhcp server STATELESS-POOL
R1(config-if)# ipv6 nd other-config-flag

-- The O-flag tells clients "get additional
-- configuration (DNS, etc.) via DHCPv6,
-- but derive your address yourself via
-- SLAAC" -- notably, the M-flag is NOT set

PC-A> ipconfig /all

IPv6 Address: 2001:DB8:I:1:a4f2:... (SLAAC-derived,
              using the interface's MAC-based
              or randomized identifier)
DNS Servers: 2001:4860:4860::8888
-- Address structure confirms SLAAC
-- generated it, while the DNS server
-- value came from DHCPv6 -- exactly the
-- hybrid behavior stateless mode provides

R1(config)# ipv6 dhcp pool STATELESS-POOL
R1(config-dhcpv6)# address prefix 2001:DB8:I:1::/64

R1(config)# interface gigabitethernet0/0
R1(config-if)# no ipv6 nd other-config-flag
R1(config-if)# ipv6 nd managed-config-flag

-- The M-flag tells clients "obtain your
-- full address from DHCPv6" -- clients
-- receiving this flag stop using SLAAC
-- for addressing entirely

PC-A> ipconfig /release6
PC-A> ipconfig /renew6

PC-A> ipconfig /all

IPv6 Address: 2001:DB8:I:1::1000 (assigned
              directly from the DHCPv6 pool's
              address range, not SLAAC-derived)
DNS Servers: 2001:4860:4860::8888
-- The address format is now clearly a
-- sequential DHCPv6-assigned value rather
-- than a SLAAC-style interface identifier

Key Takeaway

The M-flag and O-flag in router advertisements are what determine a client's DHCPv6 behavior, entirely independent of whatever the DHCPv6 pool itself is configured to provide — a pool with an address range configured is irrelevant if the interface only sets the O-flag, since clients receiving that flag will never even attempt to request an address via DHCPv6, making the RA flag configuration just as essential to verify as the pool contents when troubleshooting unexpected DHCPv6 client behavior.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue