IPv6 First-Hop Security Part 1: RA Guard and DHCPv6 Guard

In IPv4, a rogue DHCP server is a nuisance you can contain with DHCP snooping. In IPv6, the equivalent threat is worse and easier to trigger, because IPv6 hosts configure themselves from Router Advertisements, and any device on the segment can send one. A single misconfigured Windows laptop with connection sharing enabled, or a deliberate attacker, can broadcast an RA and reconfigure the default gateway for every host on the VLAN. This is not exotic. It happens by accident constantly.

IPv6 First-Hop Security (FHS) is the switch-side toolkit that stops it. This article configures RA Guard and DHCPv6 Guard and proves the block by flooding rogue RAs and confirming the victims never see them. It extends the Infrastructure Security cluster guide and builds on the IPv6 cluster guide.

Why IPv6 Is More Exposed

Recall from how IPv6 addressing works: the router advertises a prefix in an RA, and hosts autoconfigure from it. The RA also carries the default gateway. Critically, the RA is unauthenticated ND traffic, and the host has no way to tell a legitimate RA from a forged one. It believes whatever it hears.

So the attack is trivial:

The Principle: RAs Only Come From Router Ports

The insight behind RA Guard is that on any real network, you know which ports connect to routers and which connect to hosts. A legitimate RA only ever arrives on a router-facing port. An RA arriving on a host-facing access port is, by definition, either an attack or a misconfiguration. RA Guard enforces exactly that: it inspects ND traffic and drops RAs on ports designated as host ports.

You declare each port's role with a policy:

SW1(config)# ipv6 nd raguard policy HOST-PORTS
SW1(config-nd-raguard)#  device-role host
!
SW1(config)# ipv6 dhcp guard policy CLIENT-PORTS
!
SW1(config)# interface Ethernet0/1
SW1(config-if)#  ipv6 nd raguard attach-policy HOST-PORTS
SW1(config-if)#  ipv6 dhcp guard attach-policy CLIENT-PORTS
!
SW1(config)# interface Ethernet0/2
SW1(config-if)#  ipv6 nd raguard attach-policy HOST-PORTS
SW1(config-if)#  ipv6 dhcp guard attach-policy CLIENT-PORTS

device-role host is the operative setting: this port faces hosts, so RAs and DHCPv6-server messages arriving here are illegitimate and get dropped. The uplink toward the real router is left without the policy (or given device-role router), so legitimate RAs flow normally.

SW1#show ipv6 nd raguard policy HOST-PORTS
RA guard policy HOST-PORTS configuration:
  device-role host
Policy HOST-PORTS is applied on the following targets:
Target               Type  Policy               Feature        Target range
Et0/1                PORT  HOST-PORTS           RA guard       vlan all
Et0/2                PORT  HOST-PORTS           RA guard       vlan all

DHCPv6 Guard

The same idea, applied to DHCPv6 server messages. A DHCPv6 server reply (ADVERTISE, REPLY) should only come from a port where a legitimate server or relay lives. DHCPv6 Guard drops server-role DHCPv6 messages on host ports, blocking the rogue-DNS attack.

The policy above (CLIENT-PORTS attached to the host ports) means "clients live here, so anything pretending to be a DHCPv6 server on this port is dropped." A more elaborate policy can also verify the server's address against an allow-list and check the advertised preference, but at minimum, the role distinction blocks the obvious rogue.

Proof: Flood a Rogue RA, Watch It Vanish

Two hosts sit behind guarded access ports: H1 on Et0/1 and H2 on Et0/2. The legitimate router R1 is behind the unguarded uplink. H2 plays attacker, flooding rogue RAs that advertise a bogus prefix (2001:dead:beef::/64) and try to install itself as a gateway. The RA is crafted with a raw ICMPv6 socket, no special tools needed:

H2$ python3 rogue_ra.py
sent 15 rogue RAs advertising 2001:dead:beef::/64

The switch's RA Guard debug catches the ND traffic hitting the guarded port:

SW1#debug ipv6 snooping raguard
*Jul 12 01:37:31.624: SISF[RAG]: Et0/2 vlan 1 RS received by RA guard on Et0/2 from FE80::1C07:FDFF:FEF3:91BD

But the real proof is on the victim. Here is H1, behind the other guarded port, showing its addresses and routes after the flood:

H1$ ip -6 addr show dev eth0 scope global
    inet6 2001:db8:10:0:5054:ff:fedc:9702/64 scope global dynamic mngtmpaddr proto kernel_ra

H1$ ip -6 route show | grep -E 'dead|db8:10'
2001:db8:10::/64 dev eth0 proto kernel metric 256

Read that carefully, because it is the entire feature in two commands. H1 configured itself an address from 2001:db8:10::/64, the legitimate prefix advertised by R1 (note proto kernel_ra, meaning "I learned this from a Router Advertisement"). And the rogue prefix 2001:dead:beef:: is nowhere. Not in an address, not in a route. H2 flooded it fifteen times and H1 never saw a single one, because RA Guard dropped every rogue RA at H2's access port before it could reach the rest of the VLAN.

The legitimate RA from R1 (arriving on the unguarded uplink) passed through untouched. The rogue RA from H2 (arriving on a guarded host port) was silently discarded. Exactly the intended outcome, proven end to end.

FHS Is a Family

RA Guard and DHCPv6 Guard are the two you deploy first, but IPv6 First-Hop Security is a suite, and it depends on a shared foundation called device tracking (a binding table of which IPv6 address lives on which port and MAC). The companion piece, ND Inspection, Snooping, and Source Guard, covers the rest: building that binding table and using it to stop address spoofing and ND cache poisoning.

FAQ

Which ports get the policy?

Host-facing access ports get device-role host. Router-facing uplinks and trunks to other switches get no RA Guard, or an explicit device-role router policy. Never put a host policy on a real router port, or you drop the legitimate RA and break IPv6 for the segment.

Does RA Guard need SEND or RA authentication?

No. RA Guard is a stateless port-role filter, which is why it is deployable in practice. RFC 3971 SEND provides cryptographic RA authentication but is almost never deployed because hosts and infrastructure rarely support it. RA Guard is the pragmatic answer.

Can an attacker fragment the RA to evade RA Guard?

Historically yes, fragmented RAs were an evasion. Modern IOS XE RA Guard handles fragmentation, and RFC 6980 forbids fragmented ND, which most stacks now enforce. Keep switch software current.

Is this the same as DHCP snooping?

Conceptually parallel, but IPv6-specific. DHCP snooping protects IPv4 DHCP; DHCPv6 Guard protects IPv6 DHCP; RA Guard has no IPv4 equivalent because IPv4 has no Router Advertisements.

Key Takeaways

• IPv6 hosts trust Router Advertisements blindly, and any device can send one. A rogue RA hijacks the gateway; an accidental one (host with sharing on) does it by mistake.
• RA Guard drops RAs on ports declared device-role host. Legitimate RAs only arrive on router-facing ports.
• DHCPv6 Guard does the same for rogue DHCPv6 server messages, blocking the rogue-DNS attack.
• The lab proved it end to end: H2 flooded 15 rogue RAs for 2001:dead:beef::, and victim H1 learned only the legitimate 2001:db8:10:: prefix. The rogue never appeared.
• Apply host policies to access ports only. A host policy on a router uplink breaks IPv6.
• RA Guard and DHCPv6 Guard are the first two of the FHS suite; ND Inspection and Source Guard complete it.

Next: ND Inspection, Snooping, and Source Guard, or the Infrastructure Security cluster guide.