IPv6 Security — RA Guard & DHCPv6 Guard

IPv6 introduces powerful auto-configuration mechanisms — SLAAC (Stateless Address Autoconfiguration) and DHCPv6 — that allow hosts to configure themselves with an IPv6 address, prefix, and default gateway without manual intervention. Both mechanisms depend on trust: SLAAC relies on Router Advertisement (RA) messages sent by routers (see IPv6 Neighbour Discovery), and DHCPv6 relies on responses from a DHCPv6 server (see IPv6 DHCPv6 & SLAAC). An attacker on the same Layer 2 segment who sends crafted RA or DHCPv6 messages can hijack host configuration — redirecting all traffic through an attacker-controlled gateway, poisoning DNS, or creating a man-in-the-middle position with no ARP spoofing required.

RA Guard and DHCPv6 Guard are Cisco IOS IPv6 First Hop Security (FHS) features that enforce port-level policies on a switch. RA Guard drops Router Advertisement messages arriving on ports that are not trusted router ports — a host-facing access port should never originate an RA. DHCPv6 Guard drops DHCPv6 server reply messages (Advertise, Reply) on ports that are not designated DHCPv6 server ports. Both features work analogously to DHCP Snooping and Dynamic ARP Inspection for IPv4 — trusted ports allow infrastructure traffic; untrusted ports allow only client traffic.

Before starting, ensure you are familiar with IPv6 fundamentals at IPv6 Overview and address types at IPv6 Link-Local vs Global. For IPv6 address configuration on routers and interfaces, see IPv6 Basic Configuration. For DHCPv6 stateful and SLAAC operation, see IPv6 DHCPv6 & SLAAC. For the IPv4 equivalents of these First Hop Security features, see DHCP Snooping & Dynamic ARP Inspection.

1. IPv6 First Hop Security — Core Concepts

The Attack Surface: Rogue RA and Rogue DHCPv6

Understanding the attacks that RA Guard and DHCPv6 Guard prevent is essential before configuring the defences:

  ══ Attack 1: Rogue Router Advertisement (Rogue RA) ══════════════

  Normal operation:
  [Legitimate Router] ──RA (prefix 2001:db8:10::/64, GW fe80::1)──► [Hosts]
  Hosts configure: 2001:db8:10::xxxx/64, default GW = fe80::1

  Attack — any host can send RA (no protocol enforcement):
  [Attacker PC]  ──fake RA (prefix 2001:db8:99::/64, GW fe80::bad)──► [Hosts]
  Hosts now configure: 2001:db8:99::xxxx/64, default GW = fe80::bad
  ► ALL host traffic is routed through the attacker's machine
  ► Man-in-the-middle, traffic interception, denial of service

  ══ Attack 2: Rogue DHCPv6 Server ════════════════════════════════

  Normal operation:
  [Host] ──DHCPv6 Solicit──► [Legitimate DHCPv6 Server]
         ◄──DHCPv6 Advertise (addr, prefix, DNS 2001:db8::53)──
  Host configures valid DNS server

  Attack — any host can respond to DHCPv6 Solicit:
  [Host] ──DHCPv6 Solicit──► (multicast — all servers see it)
  [Attacker] ◄─── sees Solicit, responds first with DHCPv6 Advertise
  Attacker provides: malicious DNS server (2001:db8::bad:dns)
  ► Host uses attacker-controlled DNS → phishing, credential theft

IPv6 First Hop Security Feature Suite

RA Guard and DHCPv6 Guard are part of a broader suite of Cisco FHS features. This lab covers the two most important ones for the exam:

Feature	Protects Against	Mechanism	IPv4 Equivalent
RA Guard	Rogue Router Advertisements — attacker poses as a router to redirect host traffic	Drops RA messages on host-facing (untrusted) ports; only router-facing (trusted) ports may forward RAs	No direct IPv4 equivalent (DHCP Snooping is closest for gateway assignment)
DHCPv6 Guard	Rogue DHCPv6 servers — attacker provides malicious DNS, prefix, or addressing information	Drops DHCPv6 server reply messages (Advertise, Reply) on client ports; only designated server ports may forward server replies	DHCP Snooping (IPv4)
IPv6 Snooping	Binding table attacks — builds and maintains a database of IPv6 address-to-port-to-MAC mappings	Inspects NDP and DHCPv6 traffic to build a trusted binding table used by other FHS features	DHCP Snooping binding table (IPv4)
IPv6 Source Guard	IPv6 source address spoofing — host sends packets with a source IPv6 address it was not assigned	Checks source IPv6 address against the IPv6 snooping binding table; drops packets with unrecognised source addresses	IP Source Guard / DHCP Snooping (IPv4)
IPv6 ND Inspection	Neighbour Discovery spoofing — fake Neighbour Advertisement messages to poison NDP caches	Validates NDP messages against the binding table; drops inconsistent NAs	Dynamic ARP Inspection (IPv4)

RA Guard — How the Policy Model Works

RA Guard uses a named policy that defines the role of a port. The policy is created globally, then attached to one or more switch interfaces or VLANs:

Policy Device Role	RA Messages	Applied To	Effect
`device-role router`	Permitted and forwarded	Uplink ports toward legitimate routers	Router can send RA through this port — normal operation
`device-role host`	Dropped	All access ports facing end hosts	Any RA arriving on this port is discarded — attacker on a host port cannot send rogue RAs

DHCPv6 Guard — How the Policy Model Works

Policy Device Role	DHCPv6 Server Messages (Advertise, Reply)	Applied To	Effect
`device-role server`	Permitted and forwarded	Uplink ports toward the legitimate DHCPv6 server	DHCPv6 server responses flow through this port normally
`device-role client`	Dropped	All access ports facing end hosts	Any DHCPv6 server reply arriving on this port is discarded — rogue DHCPv6 servers on host ports are silenced

2. Lab Topology & Scenario

NetsTuts has a single IPv6 campus LAN segment. PC-A and PC-B are end hosts connecting through NetsTuts_SW. The legitimate router (NetsTuts_R1) sends Router Advertisements and the DHCPv6 server runs on the router itself. An attacker on the same segment (Attacker-PC, connected to Gi0/3) has been running radvd and a rogue DHCPv6 server to redirect host traffic. RA Guard and DHCPv6 Guard will be configured to harden all host ports.

                     NetsTuts_R1
                     Gi0/0: 2001:db8:10::1/64
                     fe80::1 (link-local)
                     DHCPv6 Server: enabled
                     Sends RA: enabled
                          |
                     Gi0/1 (TRUSTED — router port)
                          |
               ┌──────────────────────────┐
               │       NetsTuts_SW        │
               │  IPv6 FHS enabled        │
               │  VLAN 10                 │
               └──────────────────────────┘
                |          |          |
           Gi0/2        Gi0/3      Gi0/4
         (HOST port)  (HOST port) (HOST port)
              |            |           |
            PC-A      Attacker-PC    PC-B
         2001:db8:   (rogue RA    2001:db8:
         10::a/64     + DHCPv6)   10::b/64

  Port Roles:
  ┌─────────┬──────────────────────────────┬──────────────────┬──────────────────┐
  │ Port    │ Connected To                 │ RA Guard Role    │ DHCPv6 Guard Role│
  ├─────────┼──────────────────────────────┼──────────────────┼──────────────────┤
  │ Gi0/1   │ NetsTuts_R1 (legit router)   │ router (permit)  │ server (permit)  │
  │ Gi0/2   │ PC-A (host)                  │ host (drop RA)   │ client (drop svr)│
  │ Gi0/3   │ Attacker-PC                  │ host (drop RA)   │ client (drop svr)│
  │ Gi0/4   │ PC-B (host)                  │ host (drop RA)   │ client (drop svr)│
  └─────────┴──────────────────────────────┴──────────────────┴──────────────────┘

3. Step 1 — Enable IPv6 First Hop Security on the Switch

IPv6 FHS features require the switch to be in ipv6 unicast-routing mode (for Layer 3 switches) or, on Layer 2 switches, the FHS features are enabled per-interface without needing unicast routing. On both switch types, the VLAN must be configured to allow FHS policy processing:

NetsTuts_SW>en
NetsTuts_SW#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Verify the switch supports IPv6 FHS ──────────────────
! ── (Cat 3560/3750/3850/9000 series support FHS) ─────────
NetsTuts_SW(config)#sdm prefer dual-ipv4-and-ipv6 default
! ── Save and reload if SDM template was changed ──────────
! NetsTuts_SW(config)#end
! NetsTuts_SW#write memory
! NetsTuts_SW#reload

! ── Create and name the access VLAN ──────────────────────
NetsTuts_SW(config)#vlan 10
NetsTuts_SW(config-vlan)#name IPv6-LAN
NetsTuts_SW(config-vlan)#exit

The sdm prefer dual-ipv4-and-ipv6 default command allocates TCAM resources to support both IPv4 and IPv6 forwarding and security features. On newer Catalyst platforms (3850, 9000) this is the default — no SDM change is needed. On older 3560/3750 switches, the default SDM template is IPv4-only and must be changed before IPv6 FHS features will work. A reload is required after changing the SDM template. For interface basics, see Basic Interface Configuration.

4. Step 2 — Configure RA Guard Policies

Two RA Guard policies are needed: one for router-facing ports (permits RA messages) and one for host-facing ports (drops RA messages). The policy is created with ipv6 nd raguard policy [name]:

! ══════════════════════════════════════════════════════════
! RA Guard Policy 1: ROUTER-PORT
! Applied to uplinks toward legitimate routers
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#ipv6 nd raguard policy ROUTER-PORT
NetsTuts_SW(config-ra-guard)#device-role router
NetsTuts_SW(config-ra-guard)#exit

! ══════════════════════════════════════════════════════════
! RA Guard Policy 2: HOST-PORT
! Applied to all access ports facing end hosts
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#ipv6 nd raguard policy HOST-PORT
NetsTuts_SW(config-ra-guard)#device-role host
NetsTuts_SW(config-ra-guard)#exit

The device-role router policy permits Router Advertisements to pass through the port — the legitimate router connected to Gi0/1 can send RAs that reach the hosts normally. The device-role host policy drops all RA messages arriving on that port — any device connected to Gi0/2, Gi0/3, or Gi0/4 that sends an RA will have it silently discarded by the switch before it reaches any other host on the segment.

Optional: Advanced RA Guard Policy — Validate RA Content

The RA Guard policy can go further and validate the content of Router Advertisements on trusted router ports — checking that the RA prefix matches the expected prefix and that the hop limit is reasonable. This catches misconfigured routers as well as attackers:

! ── Advanced ROUTER-PORT policy with content validation ──
NetsTuts_SW(config)#ipv6 nd raguard policy ROUTER-PORT-STRICT
NetsTuts_SW(config-ra-guard)#device-role router

! ── Only accept RAs advertising the expected prefix ───────
NetsTuts_SW(config-ra-guard)#match ra prefix-list RA-ALLOWED-PREFIXES

! ── Only accept RAs with hop-limit of 64 or higher ────────
NetsTuts_SW(config-ra-guard)#match ra hop-limit minimum 64

! ── Managed/Other flags: validate against expected values ─
NetsTuts_SW(config-ra-guard)#match ra managed-config-flag on
NetsTuts_SW(config-ra-guard)#exit

! ── Create the prefix list referenced by the policy ───────
NetsTuts_SW(config)#ipv6 prefix-list RA-ALLOWED-PREFIXES permit 2001:db8:10::/64 le 64

match ra prefix-list validates that the prefix advertised in the RA matches the configured prefix list — a rogue RA with a different prefix (e.g., 2001:db8:99::/64) would be dropped even on a trusted router port. match ra hop-limit minimum 64 drops RAs with an abnormally low hop limit, which is a common indicator of a crafted rogue RA. match ra managed-config-flag on ensures the M-flag (telling hosts to use DHCPv6) matches the expected state — preventing an attacker from clearing the M-flag to push hosts back to SLAAC when the network uses stateful DHCPv6.

5. Step 3 — Configure DHCPv6 Guard Policies

DHCPv6 Guard policies follow the same model as RA Guard — a server policy for trusted server-facing ports and a client policy for all host-facing ports:

! ══════════════════════════════════════════════════════════
! DHCPv6 Guard Policy 1: DHCPV6-SERVER-PORT
! Applied to uplinks toward the legitimate DHCPv6 server
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#ipv6 dhcp guard policy DHCPV6-SERVER-PORT
NetsTuts_SW(config-dhcp-guard)#device-role server
NetsTuts_SW(config-dhcp-guard)#exit

! ══════════════════════════════════════════════════════════
! DHCPv6 Guard Policy 2: DHCPV6-CLIENT-PORT
! Applied to all access ports facing end hosts
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#ipv6 dhcp guard policy DHCPV6-CLIENT-PORT
NetsTuts_SW(config-dhcp-guard)#device-role client
NetsTuts_SW(config-dhcp-guard)#exit

The device-role server policy allows DHCPv6 Advertise and Reply messages to pass — the legitimate DHCPv6 server on NetsTuts_R1 (connected via Gi0/1) can respond to client Solicits. The device-role client policy silently drops all DHCPv6 server messages arriving on host ports — the Attacker-PC on Gi0/3 cannot respond to DHCPv6 Solicits from PC-A or PC-B because the switch drops all DHCPv6 Advertise/Reply messages from that port before they reach any other host.

Optional: Advanced DHCPv6 Guard — Validate Server Identity

! ── Validate that DHCPv6 server replies come from ────────
! ── a known trusted server address prefix ─────────────────
NetsTuts_SW(config)#ipv6 dhcp guard policy DHCPV6-SERVER-STRICT
NetsTuts_SW(config-dhcp-guard)#device-role server

! ── Only permit replies from the expected server prefix ───
NetsTuts_SW(config-dhcp-guard)#match server access-list DHCPv6-SERVER-ACL

! ── Only permit replies advertising prefixes in this list ─
NetsTuts_SW(config-dhcp-guard)#match reply prefix-list DHCPV6-ALLOWED-PREFIXES

NetsTuts_SW(config-dhcp-guard)#exit

! ── IPv6 ACL matching the legitimate DHCPv6 server ────────
NetsTuts_SW(config)#ipv6 access-list DHCPv6-SERVER-ACL
NetsTuts_SW(config-ipv6-acl)#permit ipv6 2001:db8:10::1/128 any
NetsTuts_SW(config-ipv6-acl)#exit

! ── Prefix list for allowed DHCPv6 address pool ───────────
NetsTuts_SW(config)#ipv6 prefix-list DHCPV6-ALLOWED-PREFIXES permit 2001:db8:10::/64 le 128

match server access-list validates the source IPv6 address of DHCPv6 server replies against an IPv6 ACL — only the legitimate server at 2001:db8:10::1 can send replies through the server port. match reply prefix-list validates the prefixes being delegated in DHCPv6 replies — a rogue server advertising an unexpected prefix would be dropped even if it somehow reached a trusted port.

6. Step 4 — Apply Policies to Switch Interfaces

Policies are applied to interfaces using ipv6 nd raguard attach-policy and ipv6 dhcp guard attach-policy. Both policies can be applied to the same interface simultaneously — a host port gets both the RA Guard host policy and the DHCPv6 Guard client policy:

! ══════════════════════════════════════════════════════════
! Gi0/1 — Uplink to NetsTuts_R1 (trusted router + DHCPv6)
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#interface GigabitEthernet0/1
NetsTuts_SW(config-if)#description Uplink to NetsTuts_R1
NetsTuts_SW(config-if)#switchport mode access
NetsTuts_SW(config-if)#switchport access vlan 10

! ── Apply RA Guard — router role (permit RAs) ────────────
NetsTuts_SW(config-if)#ipv6 nd raguard attach-policy ROUTER-PORT

! ── Apply DHCPv6 Guard — server role (permit replies) ────
NetsTuts_SW(config-if)#ipv6 dhcp guard attach-policy DHCPV6-SERVER-PORT
NetsTuts_SW(config-if)#exit

! ══════════════════════════════════════════════════════════
! Gi0/2 — PC-A (host port)
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#interface GigabitEthernet0/2
NetsTuts_SW(config-if)#description PC-A host port
NetsTuts_SW(config-if)#switchport mode access
NetsTuts_SW(config-if)#switchport access vlan 10

! ── Apply RA Guard — host role (drop all RAs) ────────────
NetsTuts_SW(config-if)#ipv6 nd raguard attach-policy HOST-PORT

! ── Apply DHCPv6 Guard — client role (drop server replies)
NetsTuts_SW(config-if)#ipv6 dhcp guard attach-policy DHCPV6-CLIENT-PORT
NetsTuts_SW(config-if)#exit

! ══════════════════════════════════════════════════════════
! Gi0/3 — Attacker-PC (host port — same policy as any host)
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#interface GigabitEthernet0/3
NetsTuts_SW(config-if)#description Host port (Attacker-PC blocked)
NetsTuts_SW(config-if)#switchport mode access
NetsTuts_SW(config-if)#switchport access vlan 10
NetsTuts_SW(config-if)#ipv6 nd raguard attach-policy HOST-PORT
NetsTuts_SW(config-if)#ipv6 dhcp guard attach-policy DHCPV6-CLIENT-PORT
NetsTuts_SW(config-if)#exit

! ══════════════════════════════════════════════════════════
! Gi0/4 — PC-B (host port)
! ══════════════════════════════════════════════════════════
NetsTuts_SW(config)#interface GigabitEthernet0/4
NetsTuts_SW(config-if)#description PC-B host port
NetsTuts_SW(config-if)#switchport mode access
NetsTuts_SW(config-if)#switchport access vlan 10
NetsTuts_SW(config-if)#ipv6 nd raguard attach-policy HOST-PORT
NetsTuts_SW(config-if)#ipv6 dhcp guard attach-policy DHCPV6-CLIENT-PORT
NetsTuts_SW(config-if)#exit

NetsTuts_SW(config)#end
NetsTuts_SW#wr
Building configuration...
[OK]
NetsTuts_SW#

Both policies are applied independently on each interface — attaching the RA Guard policy does not automatically apply DHCPv6 Guard, and vice versa. The Attacker-PC on Gi0/3 receives exactly the same host policies as PC-A and PC-B — the switch treats all non-router ports identically, regardless of intent. Any RA or DHCPv6 server message from Gi0/3 is silently dropped at the switch port before it enters the VLAN. For VLAN and trunk configuration, see VLAN Creation & Management and Trunk Port Configuration.

7. Step 5 — Applying FHS Policies at the VLAN Level

In larger deployments with many access ports, applying policies per-interface is repetitive. Both RA Guard and DHCPv6 Guard support VLAN-level policy application — the policy is applied to the VLAN and automatically takes effect on all ports in that VLAN:

! ── Apply HOST-PORT RA Guard to all ports in VLAN 10 ──────
NetsTuts_SW(config)#vlan configuration 10
NetsTuts_SW(config-vlan-config)#ipv6 nd raguard attach-policy HOST-PORT

! ── Apply DHCPv6 client guard to all ports in VLAN 10 ─────
NetsTuts_SW(config-vlan-config)#ipv6 dhcp guard attach-policy DHCPV6-CLIENT-PORT
NetsTuts_SW(config-vlan-config)#exit

! ── Override: apply router policy on the uplink only ──────
! ── Interface-level policy takes precedence over VLAN-level
NetsTuts_SW(config)#interface GigabitEthernet0/1
NetsTuts_SW(config-if)#ipv6 nd raguard attach-policy ROUTER-PORT
NetsTuts_SW(config-if)#ipv6 dhcp guard attach-policy DHCPV6-SERVER-PORT
NetsTuts_SW(config-if)#exit

VLAN-level policy applies the host/client policy to all ports in VLAN 10 by default, then the uplink (Gi0/1) overrides it with the router/server policy at the interface level. Interface-level policies always take precedence over VLAN-level policies when both are configured. This approach is far more scalable on a switch with 48 access ports — configure the host policy once on the VLAN, then explicitly override only the uplink and inter-switch trunk ports.

8. Verification

show ipv6 nd raguard policy

NetsTuts_SW#show ipv6 nd raguard policy

Target: GigabitEthernet0/1
  Policy ROUTER-PORT configuration:
    Device Role: Router
    Max Hops: 255

Target: GigabitEthernet0/2
  Policy HOST-PORT configuration:
    Device Role: Host

Target: GigabitEthernet0/3
  Policy HOST-PORT configuration:
    Device Role: Host

Target: GigabitEthernet0/4
  Policy HOST-PORT configuration:
    Device Role: Host

The output confirms which policy is applied to each interface and the device role. Device Role: Host on Gi0/2–4 confirms all RA messages arriving on those ports will be dropped. The router port (Gi0/1) shows Device Role: Router — RA messages from the legitimate router will pass through. If a port shows no policy, RA Guard is not active on that port and rogue RAs could still propagate through it.

show ipv6 nd raguard policy [name]

NetsTuts_SW#show ipv6 nd raguard policy HOST-PORT

Raguard policy HOST-PORT configuration:
  Device Role: Host
  Feature: Enabled
  Targets:
    GigabitEthernet0/2 vlan all
    GigabitEthernet0/3 vlan all
    GigabitEthernet0/4 vlan all

Raguard policy ROUTER-PORT configuration:
  Device Role: Router
  Feature: Enabled
  Targets:
    GigabitEthernet0/1 vlan all

show ipv6 dhcp guard policy

NetsTuts_SW#show ipv6 dhcp guard policy

DHCPv6 guard policy DHCPV6-CLIENT-PORT:
  Device Role: DHCP Client
  Targets:
    GigabitEthernet0/2 vlan all
    GigabitEthernet0/3 vlan all
    GigabitEthernet0/4 vlan all

DHCPv6 guard policy DHCPV6-SERVER-PORT:
  Device Role: DHCP Server
  Targets:
    GigabitEthernet0/1 vlan all

The DHCPv6 Guard output confirms all host ports have the client policy (DHCPv6 server replies dropped) and only the uplink (Gi0/1) has the server policy (DHCPv6 replies permitted). Any DHCPv6 Advertise or Reply message arriving on Gi0/2, Gi0/3, or Gi0/4 — including from the Attacker-PC — will be silently dropped by the switch.

show ipv6 dhcp guard policy [name]

NetsTuts_SW#show ipv6 dhcp guard policy DHCPV6-CLIENT-PORT

DHCPv6 guard policy DHCPV6-CLIENT-PORT configuration:
  Device Role: DHCP Client
  Feature: Enabled
  Targets:
    GigabitEthernet0/2 vlan all
    GigabitEthernet0/3 vlan all
    GigabitEthernet0/4 vlan all

show ipv6 nd raguard statistics — Drop Counters

NetsTuts_SW#show ipv6 nd raguard statistics

Interface       Gi0/2                Gi0/3                Gi0/4
  RA dropped:   0                    47                   0
  RA forwarded: 0                    0                    0

Interface       Gi0/1
  RA dropped:   0
  RA forwarded: 312

The statistics output confirms the Attacker-PC on Gi0/3 has sent 47 rogue Router Advertisement messages that were all dropped by the switch before reaching any host on the segment. Gi0/1 shows 312 RA messages forwarded — the legitimate router's periodic RAs and unsolicited RAs are passing through correctly. PC-A and PC-B ports show 0 dropped because neither host has attempted to send an RA (normal end-host behaviour).

show ipv6 snooping features — FHS Feature Summary

NetsTuts_SW#show ipv6 snooping features

Feature name    priority    state
Ra-guard        150         READY
DHCP-guard      100         READY

Functional Verification — Before and After

! ── On PC-A BEFORE RA Guard (attacker active) ────────────
PC-A$ ip -6 route show default
default via fe80::bad dev eth0 proto ra   ← Attacker's gateway!

! ── On PC-A AFTER RA Guard applied ───────────────────────
PC-A$ ip -6 route show default
default via fe80::1 dev eth0 proto ra     ← Legitimate router only

! ── Verify PC-A is using correct DNS (post DHCPv6 Guard) ─
PC-A$ cat /etc/resolv.conf
nameserver 2001:db8:10::53                ← Legitimate DNS only

Before RA Guard, PC-A had configured the attacker's gateway (fe80::bad) as its default route — all traffic was being routed through the attacker's machine. After RA Guard is applied, only the legitimate router's RA (with gateway fe80::1) is forwarded by the switch. PC-A now has the correct default gateway and the man-in-the-middle position is eliminated.

Verification Command Summary

Command	What It Shows	Primary Use
`show ipv6 nd raguard policy`	All RA Guard policies — device role, and all interfaces/VLANs each policy is applied to	Primary verification — confirm RA Guard is applied to every port with correct role
`show ipv6 nd raguard policy [name]`	Specific policy detail — device role, feature state, and list of attached targets	Confirm a named policy is enabled and attached to the expected interfaces
`show ipv6 dhcp guard policy`	All DHCPv6 Guard policies — device role (server/client) and attached targets	Confirm DHCPv6 Guard client policy is applied to host ports and server policy to uplinks
`show ipv6 dhcp guard policy [name]`	Specific DHCPv6 Guard policy detail — role, state, and attached interfaces	Verify a specific policy is active and applied to the correct ports
`show ipv6 nd raguard statistics`	Per-interface RA drop and forward counters	Confirm rogue RAs are being dropped (non-zero drop counter on attacker port) and legitimate RAs are forwarded (non-zero forward counter on router port)
`show ipv6 snooping features`	All active IPv6 FHS features and their state (READY / NOT READY)	Confirm all FHS features are initialised and operational on the switch
`show ipv6 snooping binding`	IPv6 First Hop Security binding table — MAC, IPv6 address, VLAN, interface, and how the entry was learned	Verify hosts have learned IPv6 addresses from the correct source; used by IPv6 Source Guard and ND Inspection
`show running-config interface [int]`	Interface config — confirms `ipv6 nd raguard attach-policy` and `ipv6 dhcp guard attach-policy` lines are present. See show running-config	Quick audit of which policies are attached to a specific port

9. Troubleshooting RA Guard & DHCPv6 Guard Issues

Problem	Symptom	Cause	Fix
Hosts cannot get IPv6 addresses via SLAAC	After applying RA Guard, hosts no longer receive a global IPv6 address via SLAAC — they only have a link-local address	The router uplink port has the HOST-PORT policy (device-role host) instead of the ROUTER-PORT policy (device-role router) — the legitimate router's RA is being dropped along with the rogue ones	Run `show ipv6 nd raguard policy` — confirm the router port (Gi0/1) has device-role router. If it shows device-role host, re-attach the correct policy: `interface Gi0/1` then `ipv6 nd raguard attach-policy ROUTER-PORT`. Test with `show ipv6 nd raguard statistics` — the router port should show RA forwarded, not RA dropped
Hosts cannot get addresses from DHCPv6	After applying DHCPv6 Guard, hosts send DHCPv6 Solicit but receive no response — DHCPv6 address assignment fails	The DHCPv6 server uplink port has the DHCPV6-CLIENT-PORT policy (device-role client) instead of DHCPV6-SERVER-PORT (device-role server) — the server's Advertise/Reply messages are being dropped by the switch before reaching the client	Run `show ipv6 dhcp guard policy` — confirm the uplink port (Gi0/1) has device-role server. Re-attach if wrong: `interface Gi0/1` then `ipv6 dhcp guard attach-policy DHCPV6-SERVER-PORT`. On a Layer 3 switch where the DHCPv6 server is on a different VLAN, the relay/server port facing that VLAN must also have the server policy
`show ipv6 nd raguard policy` shows no output or no targets	Policy is created but no interfaces are listed as targets — the policy exists but is not active anywhere	The policy was created with `ipv6 nd raguard policy` but `ipv6 nd raguard attach-policy` was never applied to any interface or VLAN	Apply the policy: on each host port run `ipv6 nd raguard attach-policy HOST-PORT`. Verify with `show ipv6 nd raguard policy HOST-PORT` — targets should now list the attached interfaces
RA Guard not dropping rogue RAs despite correct policy	`show ipv6 nd raguard statistics` shows 0 dropped on the attacker port — rogue RAs are still reaching hosts	The SDM template does not allocate TCAM for IPv6 FHS, or the switch platform does not support RA Guard in hardware on this port type, or the policy is attached to the wrong VLAN scope	Verify `show sdm prefer` — confirm the active template includes IPv6. If not, run `sdm prefer dual-ipv4-and-ipv6 default` and reload. Check `show ipv6 snooping features` — RA Guard state must be READY, not NOT READY
Advanced policy content validation drops legitimate RA	After adding `match ra prefix-list`, even the router port drops RAs — hosts can no longer auto-configure	The prefix list does not include the exact prefix the router is advertising, or the prefix list has a `le` value that does not cover the advertised prefix length	Run `debug ipv6 nd raguard` to see why RAs are being dropped — the debug output shows which match criterion failed. Check the prefix list: `show ipv6 prefix-list RA-ALLOWED-PREFIXES` — ensure the router's actual advertised prefix (from `show ipv6 interface` on the router) is covered
VLAN-level policy not working on newly added ports	A new host port added to VLAN 10 is not protected — rogue RAs from this port still propagate	VLAN-level policy was applied correctly but the new port has an interface-level override that takes precedence, or the VLAN-level policy was applied before the new port was assigned to VLAN 10	Check `show running-config interface [new-port]` — remove any interface-level RA Guard policy that overrides the VLAN policy. Verify the port is in the correct VLAN with `show vlan brief`. VLAN-level FHS policies apply automatically to all ports that are currently and subsequently added to that VLAN

Key Points & Exam Tips

RA Guard prevents rogue Router Advertisement attacks by dropping RA messages on host-facing switch ports — only ports with device-role router are allowed to forward RAs. This stops any host from posing as a router to redirect IPv6 traffic through an attacker-controlled gateway. See also Login Security for complementary switch hardening.
DHCPv6 Guard prevents rogue DHCPv6 server attacks by dropping DHCPv6 Advertise and Reply messages on host-facing ports — only ports with device-role server forward DHCPv6 server responses. This stops rogue DHCPv6 servers from providing malicious DNS addresses or prefixes to clients.
Both features follow the same trusted / untrusted port model as IPv4 DHCP Snooping: infrastructure-facing ports are trusted (router/server role); host-facing access ports are untrusted (host/client role).
Policies are created globally with ipv6 nd raguard policy [name] and ipv6 dhcp guard policy [name], then attached to interfaces with ipv6 nd raguard attach-policy [name] and ipv6 dhcp guard attach-policy [name]. Creating a policy without attaching it has no effect.
Interface-level policy takes precedence over VLAN-level policy when both are configured. This allows the efficient pattern of applying a host/client policy to the entire VLAN and then overriding only the uplink ports with router/server policies.
The SDM template must allocate TCAM for IPv6 on older Catalyst platforms (3560/3750) — use sdm prefer dual-ipv4-and-ipv6 default and reload. On modern platforms (3850/9000) this is the default. A wrong SDM template causes the FHS features to show NOT READY in show ipv6 snooping features.
Advanced RA Guard policies can validate RA content on trusted router ports: match ra prefix-list (prefix must match), match ra hop-limit minimum (abnormally low hop limit = crafted RA), and match ra managed-config-flag (M-flag consistency). This catches misconfigured routers as well as attackers.
show ipv6 nd raguard statistics shows per-interface RA drop and forward counters — the most direct evidence that RA Guard is active and blocking rogue RAs. Non-zero drop counters on host ports indicate attack traffic was blocked.
RA Guard and DHCPv6 Guard are part of the broader IPv6 First Hop Security suite, which also includes IPv6 Snooping (binding table), IPv6 Source Guard (anti-spoofing), and IPv6 ND Inspection (NDP cache protection). The full suite provides IPv6 equivalents of DHCP Snooping, IP Source Guard, and Dynamic ARP Inspection.
On the exam: know the two device roles for each feature (router/host for RA Guard; server/client for DHCPv6 Guard), the three-step workflow (create policy → set role → attach to interface), the primary verification commands (show ipv6 nd raguard policy, show ipv6 dhcp guard policy), and the IPv4 analogues for each FHS feature.

Next Steps: For the IPv4 First Hop Security equivalents — DHCP Snooping and Dynamic ARP Inspection — see DHCP Snooping & Dynamic ARP Inspection. For port security to restrict which MAC addresses can appear on a host port, see Port Security & Sticky MAC. For switch port hardening fundamentals including PortFast and BPDU Guard, see PortFast & BPDU Guard. For private VLAN configurations that further isolate hosts on the same segment, see Private VLAN Configuration. For the IPv6 addressing and SLAAC/DHCPv6 operation that these features protect, see IPv6 DHCPv6 & SLAAC and IPv6 Basic Configuration. For logging FHS drop events, see show logging and Syslog Configuration for forwarding FHS events to a central log server.

TEST WHAT YOU LEARNED

1. What specific threat does a rogue Router Advertisement attack pose on an IPv6 network, and why is it more dangerous than the IPv4 equivalent?

A. A rogue RA floods the switch's CAM table with random MAC addresses, causing all frames to be broadcast — the same threat as a MAC flooding attack in IPv4 B. A rogue RA causes all hosts on the segment to lose connectivity by advertising a shorter prefix length that overlaps with the legitimate prefix, triggering routing loops C. A rogue RA tricks IPv6 hosts into configuring an attacker-controlled default gateway via SLAAC — hosts auto-configure without any DHCP negotiation, so the attack succeeds the moment the RA is received with no user interaction. In IPv4, hosts must contact a DHCP server to get a gateway; in IPv6 with SLAAC the gateway is derived directly from the RA, making the attack instantaneous and requiring no server compromise D. A rogue RA causes IPv6 Neighbour Discovery to fail, preventing hosts from resolving link-layer addresses — equivalent to a gratuitous ARP poisoning attack in IPv4

Correct answer is C. In IPv6 with SLAAC, a host receives a Router Advertisement and uses the advertised prefix to automatically configure its own global unicast address, and uses the router's link-local address (the RA source) as its default gateway. This happens automatically via the Neighbour Discovery Protocol — there is no DHCP server involved, no user interaction, and no timeout waiting for a response. Any host on the L2 segment that sends an RA can immediately redirect all SLAAC-configured hosts to route their traffic through the attacker's interface. In IPv4, changing a host's default gateway requires either a DHCP server (which requires the host to renew its lease) or ARP cache poisoning (which is more complex and detectable). The SLAAC mechanism makes rogue RA attacks particularly stealthy and immediate.

2. An RA Guard policy with `device-role host` is attached to a switch port. What happens when a Router Advertisement message arrives on that port?

A. The RA message is silently dropped by the switch at the ingress port — it is discarded before being forwarded into the VLAN or reaching any other host on the segment. The sending device receives no notification that its RA was dropped B. The RA message is forwarded but rate-limited — a maximum of one RA per minute is allowed through the host port to prevent flooding C. The RA message is forwarded to the switch's CPU for logging and then dropped — an SNMP trap is generated to alert the network administrator D. The RA message causes the port to enter err-disabled state — the switch shuts down the port to prevent further rogue RA attempts

Correct answer is A. RA Guard with device-role host silently drops all Router Advertisement messages at the ingress port. The drop happens in hardware (TCAM) before the RA is forwarded into the VLAN — other hosts on the segment never see it. The attacker's device does not receive an error message or acknowledgment that the RA was dropped; from the attacker's perspective, the RA was sent successfully. This silent drop behaviour is identical to how DHCP Snooping handles DHCPv4 server messages arriving on untrusted ports. There is no rate-limiting behaviour (option B) — the action is a complete drop. While some logging can be configured, the default action is a silent drop without err-disabling the port (option D), which would be too disruptive for environments where a misconfigured but legitimate host might accidentally send an RA.

3. An engineer creates an RA Guard policy on a Catalyst switch and sets `device-role host`, but `show ipv6 nd raguard policy` shows no targets. Rogue RAs are still reaching hosts. What is missing?

A. The policy is missing the no shutdown command — RA Guard policies must be explicitly enabled after creation B. The SDM template has not been set to dual-ipv4-and-ipv6 — the policy is created but the hardware cannot enforce it C. The policy needs a match ra prefix-list statement — without it, the policy has no match criteria and defaults to permit-all D. The policy was created but never attached to any interface or VLAN — creating a policy with ipv6 nd raguard policy HOST-PORT only defines the policy object. It must also be applied with ipv6 nd raguard attach-policy HOST-PORT on each host interface, or at the VLAN level with vlan configuration 10 then ipv6 nd raguard attach-policy HOST-PORT. The "no targets" output in show ipv6 nd raguard policy is the direct indicator of this missing step

Correct answer is D. This is the most common RA Guard deployment mistake. The two-step process is: (1) define the policy with ipv6 nd raguard policy [name] and set device-role host, and (2) attach the policy to interfaces or a VLAN with ipv6 nd raguard attach-policy [name]. Step 1 alone creates the policy object but does not enforce anything — it has no effect until attached. The "no targets" in the show output is the definitive evidence that step 2 was skipped. Option B (SDM template) would cause show ipv6 snooping features to show RA Guard as NOT READY, not zero targets. Option C is incorrect — the match ra prefix-list is optional advanced content validation; without it the policy still drops all RAs on host ports based on device-role alone.

4. What is the role of the `match ra prefix-list` option in an advanced RA Guard router-port policy, and what does it protect against that the basic device-role setting does not?

A. match ra prefix-list is required for the RA Guard policy to activate — without it, the device-role setting has no effect and all RAs are permitted regardless of port role B. The basic device-role router setting permits all RAs from the trusted port — even an RA advertising an unexpected or incorrect prefix. match ra prefix-list adds content validation: only RAs advertising prefixes matching the configured list are forwarded. This protects against a misconfigured legitimate router accidentally advertising the wrong prefix, or a compromised upstream device advertising a rogue prefix through the trusted uplink C. match ra prefix-list limits which hosts are allowed to use the advertised prefix — hosts not in the prefix list have their RA-derived addresses removed D. match ra prefix-list is only relevant on host ports — it has no effect on router ports where device-role router already permits all RA traffic

Correct answer is B. The basic device-role router policy is binary — it permits all RAs from that port with no inspection of the RA content. This is sufficient to stop rogue RAs from host ports, but does not protect against a trusted router port sending unexpected prefixes. Common scenarios where content validation adds value: (1) a misconfigured router advertising a summary prefix too broad (e.g., ::/0 instead of 2001:db8:10::/64), (2) a routing misconfiguration that causes the wrong subnet's prefix to be advertised, or (3) a compromised device upstream sending a rogue RA through what appears to be a legitimate router port. The match ra prefix-list ensures that even trusted ports can only forward RAs that advertise the specifically expected prefix, adding defence-in-depth beyond just port role assignment.

5. How does DHCPv6 Guard differ from RA Guard in terms of what messages it filters and which device role it uses for untrusted ports?

A. DHCPv6 Guard and RA Guard are identical — both drop the same ICMPv6 message types and use the same device-role keywords (router/host) B. DHCPv6 Guard drops all DHCPv6 messages (both client Solicit/Request and server Advertise/Reply) on untrusted ports — client-facing ports are silenced entirely C. DHCPv6 Guard filters DHCPv6 server reply messages (Advertise and Reply) — not client messages. On untrusted ports (device-role client), server replies are dropped while client messages (Solicit, Request, Renew) are still allowed to pass. The device-role keywords differ: RA Guard uses router/host; DHCPv6 Guard uses server/client D. DHCPv6 Guard filters UDP port 547 traffic only (server to client direction) — it has no effect on UDP port 546 (client to server) and uses the same router/host device-role keywords as RA Guard

Correct answer is C. This distinction is important for both the exam and for understanding why the features work correctly. DHCPv6 clients need to send Solicit, Request, Renew, and Release messages — these must be allowed through even on "untrusted" ports or DHCPv6 would not function at all. DHCPv6 Guard only blocks the server-to-client direction: Advertise (the server's response to Solicit) and Reply (the server's response to Request). A rogue DHCPv6 server on a host port cannot respond to client Solicits because its Advertise messages are dropped. The device-role keywords reflect these different semantics: RA Guard uses router (permit RAs) / host (drop RAs) while DHCPv6 Guard uses server (permit Advertise/Reply) / client (drop Advertise/Reply). Both follow the same trusted/untrusted port model but with appropriate protocol-specific terminology.

6. After applying RA Guard with `device-role host` on all access ports, hosts stop receiving global IPv6 addresses via SLAAC. `show ipv6 nd raguard statistics` shows RA drop counters incrementing on the uplink port (Gi0/1). What is wrong?

A. SLAAC does not work with RA Guard — switch to stateful DHCPv6 for address assignment when RA Guard is enabled B. The RA Guard feature requires IPv6 unicast routing to be enabled on the switch — run ipv6 unicast-routing globally C. The ROUTER-PORT policy is missing the permit ipv6 any any statement — without it all traffic is dropped on the router port D. The uplink port (Gi0/1) has the HOST-PORT policy (device-role host) attached instead of the ROUTER-PORT policy (device-role router) — the switch is dropping the legitimate router's RA messages on the uplink. Run interface Gi0/1 then ipv6 nd raguard attach-policy ROUTER-PORT to replace the host policy with the router policy on the uplink

Correct answer is D. The symptom — RA drops incrementing on Gi0/1 (the uplink) — is the definitive clue. RA drops should increment only on host ports where rogue RAs are blocked. If drops are incrementing on the uplink, it means the uplink port has a host-role policy and is dropping the legitimate router's RAs. This is a common misconfiguration when the host/client policy is applied globally (e.g., across all ports or at the VLAN level) without then overriding the uplink with the router/server policy. Fix: interface Gi0/1 → ipv6 nd raguard attach-policy ROUTER-PORT. After the fix, verify with show ipv6 nd raguard statistics — the uplink should show RA forwarded (not dropped), and SLAAC on hosts should resume within one RA interval (default 200 seconds maximum, often faster with solicited RAs).

7. What is the advantage of applying RA Guard and DHCPv6 Guard at the VLAN level rather than per-interface, and which policy takes precedence when both are configured?

A. VLAN-level policy applies automatically to all current and future ports in the VLAN with a single configuration — on a 48-port switch this avoids 48 repetitive interface commands. When both VLAN-level and interface-level policies are configured on the same port, the interface-level policy takes precedence. This enables the efficient pattern: apply the host/client policy to the entire VLAN, then override only the uplink ports with the router/server policy at the interface level B. VLAN-level policy is more secure because it cannot be overridden by an interface-level policy — this ensures no individual port can be accidentally excluded from protection C. VLAN-level and interface-level policies are additive — when both are present the most restrictive policy (device-role host) always wins regardless of which was applied at which level D. VLAN-level policy applies to trunk ports only; interface-level policy applies to access ports only — both are required for complete coverage on a switch with mixed port types

Correct answer is A. VLAN-level policy application is the scalable deployment pattern for RA Guard and DHCPv6 Guard. Instead of configuring 48 interfaces individually, you run two commands: vlan configuration 10 then ipv6 nd raguard attach-policy HOST-PORT. This applies to all current and future ports in VLAN 10 automatically. The precedence rule — interface-level overrides VLAN-level — is what makes this pattern work. You apply the restrictive host/client policy to the VLAN (covers everything) then apply the permissive router/server policy at the interface level on just the uplink ports (overrides the VLAN policy on those specific ports). The result: all host ports are protected by the VLAN policy; the uplink ports use the interface-level policy. New host ports added to VLAN 10 are automatically protected without additional configuration.

8. Which IPv6 First Hop Security feature is the closest equivalent to IPv4 Dynamic ARP Inspection, and what does it protect against?

A. DHCPv6 Guard — it prevents unauthorized address assignment in the same way DAI prevents ARP cache poisoning B. IPv6 ND Inspection — it validates Neighbour Advertisement (NA) and Neighbour Solicitation (NS) messages against a binding table, dropping NAs where the claimed IPv6-to-MAC mapping does not match the binding table. This is functionally equivalent to DAI, which validates ARP reply mappings against the DHCP snooping binding table C. IPv6 Snooping — it builds the binding table that other features use, analogous to DAI's role in inspecting ARP traffic D. RA Guard — it prevents NDP cache poisoning by ensuring only trusted routers can send Neighbour Advertisement messages

Correct answer is B. IPv6 uses Neighbour Discovery Protocol (NDP) instead of ARP — Neighbour Solicitation (NS) replaces ARP Request and Neighbour Advertisement (NA) replaces ARP Reply. NDP cache poisoning is the IPv6 equivalent of ARP cache poisoning: an attacker sends a crafted NA claiming "my MAC address is the mapping for this IPv6 address" to redirect traffic. IPv6 ND Inspection validates NA and NS messages against the IPv6 snooping binding table (which records legitimate IPv6-address-to-MAC-to-port mappings), dropping inconsistent NAs — exactly as DAI validates ARP replies against the DHCP snooping binding table. The mapping is: IPv6 Snooping ≈ DHCP Snooping (builds binding table), IPv6 Source Guard ≈ IP Source Guard (anti-spoofing), IPv6 ND Inspection ≈ Dynamic ARP Inspection (NDP cache protection), and RA Guard has no direct IPv4 equivalent since SLAAC has no IPv4 counterpart.

9. `show ipv6 snooping features` shows RA Guard state as NOT READY on a Catalyst 3560 switch. What is the most likely cause and fix?

A. The switch IOS version does not support RA Guard — upgrade to the latest IOS release B. RA Guard requires a Cisco DNA Advantage license — apply the license before RA Guard can be enabled C. The active SDM (Switching Database Manager) template on the Catalyst 3560 is the default IPv4-only template, which does not allocate TCAM space for IPv6 FHS features. Run sdm prefer dual-ipv4-and-ipv6 default, save the configuration, and reload the switch. After the reload, show ipv6 snooping features should show RA Guard as READY D. IPv6 unicast routing must be enabled on a Layer 2 switch for FHS features to work — run ipv6 unicast-routing globally

Correct answer is C. The Catalyst 3560 and 3750 series switches use an SDM (Switching Database Manager) template to allocate TCAM (ternary content-addressable memory) resources between different features. The default SDM template on these older platforms is IPv4-optimised and does not reserve TCAM space for IPv6 security features. When RA Guard or other IPv6 FHS features are configured on a switch running the wrong SDM template, they show as NOT READY because the hardware cannot enforce the policies. The fix is sdm prefer dual-ipv4-and-ipv6 default (or the routing version for Layer 3 switches), followed by write memory and reload. The SDM change requires a reload to reallocate TCAM. On modern Catalyst 3850 and 9000 series switches, the default SDM template already supports IPv6 FHS and no change is needed. IPv6 unicast routing (option D) is not required on a Layer 2 access switch for FHS features to work.

10. A switch port has both a VLAN-level RA Guard policy (HOST-PORT, device-role host) and an interface-level RA Guard policy (ROUTER-PORT, device-role router) applied. Which policy is enforced and why?

A. The VLAN-level policy (HOST-PORT) takes precedence — VLAN-level policies are more authoritative than interface-level overrides in Cisco FHS B. Both policies are enforced simultaneously — the most restrictive action wins, so the port behaves as device-role host and drops all RAs C. The switch returns a configuration error when both levels have conflicting policies — one must be removed before the other takes effect D. The interface-level policy (ROUTER-PORT, device-role router) takes precedence over the VLAN-level policy. This is the designed behaviour that enables the scalable deployment pattern: apply a restrictive host/client policy to the entire VLAN, then override only specific uplink ports at the interface level with the permissive router/server policy — the interface override wins on those specific ports while all other ports in the VLAN continue to use the VLAN-level host policy

Correct answer is D. Interface-level policy always takes precedence over VLAN-level policy in Cisco IPv6 First Hop Security. This is a deliberate design choice that makes scalable deployment possible. The typical deployment pattern uses this precedence: configure the host/client policy at the VLAN level (one command covers all 48 access ports), then apply the router/server policy at the interface level on just the 1–2 uplink ports. The uplink ports see the interface-level router policy; all other ports in the VLAN see the VLAN-level host policy. Without this precedence rule, you would need to either apply host policies per-interface on all 48 ports (defeating the purpose of VLAN-level policy) or create separate VLANs for uplinks (operationally complex). The same precedence applies to DHCPv6 Guard: VLAN-level client policy + interface-level server policy override on the uplink.

Back to Home