Hands-On Lab: Configuring IPv6 First-Hop Security (RA Guard and DHCPv6 Guard)

Lab Objective

Configure RA Guard on access ports to block router advertisements from anywhere except a trusted uplink, configure DHCPv6 Guard similarly to block unauthorized DHCPv6 server responses, and verify both simulated rogue conditions are blocked while legitimate traffic continues functioning.

Lab Purpose

DHCP Snooping and Dynamic ARP Inspection, covered earlier in this series, protect IPv4 networks against rogue DHCP servers and ARP spoofing. IPv6 introduces its own distinct threats — a rogue device sending router advertisements can hijack default gateway selection entirely, and a rogue DHCPv6 server can distribute false addressing information — requiring IPv6-specific first-hop security features to address.

Lab Topology

Switch1
  Gi1/0/24 ---- trusted uplink to legitimate
                router (sends real RAs) and
                legitimate DHCPv6 server
  Gi1/0/1 ---- PC-A (untrusted access port)
  Gi1/0/2 ---- Simulated rogue device
               (untrusted access port)

Task 1: Configure RA Guard on Untrusted Ports

Configure RA Guard in host mode on Gi1/0/1 and Gi1/0/2, and in router mode on the trusted uplink.

Task 2: Verify Legitimate RAs Still Reach Clients

Confirm PC-A still receives router advertisements from the legitimate router through the trusted uplink.

Task 3: Simulate a Rogue Router Advertisement

Send a router advertisement from the untrusted Gi1/0/2 port and confirm it is blocked.

Task 4: Configure DHCPv6 Guard on Untrusted Ports

Configure DHCPv6 Guard in client-facing mode on the untrusted ports, permitting server responses only from the trusted uplink.

Task 5: Simulate a Rogue DHCPv6 Server Response

Attempt to send a DHCPv6 advertise message from the untrusted port and confirm it is dropped.

Solution and Verification

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# ipv6 nd raguard attach-policy TRUSTED-UPLINK

Switch1(config)# ipv6 nd raguard policy TRUSTED-UPLINK
Switch1(config-ra-guard)# device-role router

Switch1(config)# ipv6 nd raguard policy HOST-POLICY
Switch1(config-ra-guard)# device-role host

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# ipv6 nd raguard attach-policy HOST-POLICY
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# ipv6 nd raguard attach-policy HOST-POLICY

-- "device-role host" means this port should
-- never legitimately send RAs at all --
-- any RA arriving here is automatically
-- suspect

PC-A> ipconfig /all

IPv6 Address: 2001:DB8:L:1:... (SLAAC-derived
              from the legitimate RA)
Default Gateway: FE80::[legitimate router]
-- Legitimate RAs from the trusted uplink
-- still reach PC-A normally

-- Simulated rogue RA sent from Gi1/0/2:

Switch1# show ipv6 nd raguard policy HOST-POLICY

Interfaces using this policy:
  Gi1/0/1, Gi1/0/2

Switch1# show logging | include RA_GUARD

%RA_GUARD-4-VIOLATION: RA received on
untrusted port Gi1/0/2, dropped
-- The rogue RA never reached other hosts
-- on the segment, preventing a potential
-- default gateway hijack

Switch1(config)# ipv6 dhcp guard policy DHCPV6-GUARD-POLICY
Switch1(config-dhcp-guard)# device-role client
Switch1(config-dhcp-guard)# exit

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# ipv6 dhcp guard attach-policy DHCPV6-GUARD-POLICY
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# ipv6 dhcp guard attach-policy DHCPV6-GUARD-POLICY

-- "device-role client" marks these ports
-- as never legitimately sourcing DHCPv6
-- server messages (advertise, reply)

-- Simulated rogue DHCPv6 advertise message
-- sent from Gi1/0/2:

Switch1# show logging | include DHCP_GUARD

%DHCP_GUARD-4-VIOLATION: DHCPv6 server message
received on untrusted port Gi1/0/2, dropped
-- The rogue DHCPv6 response never reached
-- legitimate clients, preventing them from
-- receiving false addressing or DNS
-- information

Key Takeaway

RA Guard and DHCPv6 Guard both work on the same underlying principle as DHCP Snooping's trusted/untrusted port model covered earlier in this series: legitimate server-role traffic (router advertisements, DHCPv6 server responses) is permitted only from ports explicitly marked as trusted, while any such traffic arriving on a client-facing port is automatically dropped — extending the same fundamental trust-boundary concept from IPv4's DHCP Snooping into IPv6's distinct set of first-hop threats.