Hands-On Lab: Configuring an IPv6 DHCP Relay Agent

This hands-on lab configures a router to relay DHCPv6 requests from a remote subnet to a centralized DHCPv6 server, mirroring the ip helper-address behavior covered earlier in this series but using IPv6's distinct relay mechanism.

DHCPv6 Relay Configurationipv6 dhcp relay destinationRemote Subnet DHCPv6

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure a router as a DHCPv6 relay agent, forwarding DHCPv6 requests from a remote subnet to a centralized DHCPv6 server on a different segment, and verify a client on the remote subnet successfully receives an address despite the server having no direct connection to that segment.

Lab Purpose

The DHCP relay lab covered earlier in this series used ip helper-address for IPv4. IPv6 requires a distinct, protocol-specific relay configuration, since DHCPv6 operates differently at the protocol level from DHCPv4 — understanding this separate syntax is essential for supporting centralized DHCPv6 in any multi-subnet IPv6 deployment.

Lab Topology

R1 (DHCPv6 server) ---- Gi0/0: 2001:DB8:J:1::1/64
R1 ---- Serial0/0/0 ---- Serial0/0/0 ---- R2 (relay)

R2 ---- Gi0/0: 2001:DB8:J:2::1/64 (remote
                                    subnet,
                                    clients here)

Task 1: Configure Basic IPv6 Addressing

Enable IPv6 routing and configure R1's LAN interface, the serial link, and R2's LAN interface.

Task 2: Configure R1 as a Stateful DHCPv6 Server

Configure a DHCPv6 pool on R1 covering R2's remote subnet, and apply it appropriately.

Task 3: Configure DHCPv6 Relay on R2

Configure R2's LAN-facing interface to relay DHCPv6 requests toward R1.

Task 4: Verify a Remote Client Receives an Address

Confirm a client on R2's LAN successfully obtains an address from R1's DHCPv6 pool.

Task 5: Verify the Binding on the DHCPv6 Server

Confirm R1 shows the remote client's binding, despite having no direct connection to that segment.

Solution and Verification

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

R2(config)# ipv6 unicast-routing
R2(config)# interface serial0/0/0
R2(config-if)# ipv6 address 2001:DB8:JLINK::2/64
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface gigabitethernet0/0
R2(config-if)# ipv6 address 2001:DB8:J:2::1/64
R2(config-if)# no shutdown

R1(config)# ipv6 dhcp pool REMOTE-POOL
R1(config-dhcpv6)# address prefix 2001:DB8:J:2::/64
R1(config-dhcpv6)# dns-server 2001:4860:4860::8888

R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 dhcp server REMOTE-POOL
-- Also serving its own local segment, but
-- note this pool's address range is
-- specifically for the REMOTE subnet, not
-- this local interface's own subnet --
-- DHCPv6 relay works based on prefix
-- matching, not physical interface

R2(config)# interface gigabitethernet0/0
R2(config-if)# ipv6 dhcp relay destination 2001:DB8:JLINK::1

-- Unlike IPv4's simple "ip helper-address,"
-- IPv6 uses "ipv6 dhcp relay destination"
-- -- distinct syntax reflecting DHCPv6's
-- own protocol differences from DHCPv4

RemoteClient> ipconfig /renew6

IPv6 Address: 2001:DB8:J:2::1000
DNS Servers: 2001:4860:4860::8888
-- The remote client successfully received
-- an address from R1's REMOTE-POOL,
-- despite R1 having no direct connection
-- to the 2001:DB8:J:2::/64 segment

R1# show ipv6 dhcp binding

Client: FE80::...
  IA NA: IA ID 0x00030001, T1 43200, T2 69120
    Address: 2001:DB8:J:2::1000
    preferred lifetime 86400, valid lifetime 86400
-- R1 shows the binding for the remote
-- client, confirming it is genuinely
-- serving as the DHCPv6 server for this
-- remote segment via R2's relay

Key Takeaway

DHCPv6 relay uses ipv6 dhcp relay destination rather than IPv4's ip helper-address, a syntax distinction worth remembering when migrating IPv4 relay knowledge to dual-stack or IPv6-only environments — the underlying concept remains identical to the IPv4 relay lab covered earlier in this series (converting a client's local multicast/broadcast request into a targeted unicast message toward a centralized server), but the specific command and protocol mechanics differ meaningfully between the two address families.

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