Testing RA Guard with thc-ipv6 — Stop the RA-Flood CPU DoS

IPv6 hosts auto-configure themselves from Router Advertisements (RAs). That's elegant — until someone floods the LAN with thousands of bogus RAs a second. Each one forces the victim to add addresses and routes and re-run SLAAC, and the CPU disappears into softirq processing the storm — a classic denial of service where the host's receive queue backs up and it stops responding. The fix is RA Guard on the switch. This guide uses thc-ipv6 to reproduce the attack in a lab and prove RA Guard blocks it.

01Why an RA flood is a CPU DoS

An RA isn't a packet a host can ignore — it's an instruction. For every RA, the stack may add a prefix, generate a SLAAC address (and a privacy address), install a default route, and start timers. Send tens of thousands per second with random prefixes and routers and the victim spends all its time in kernel softirq context servicing the receive queue. On Linux that shows up as ksoftirqd pinned near 100%; the NIC backlog queue overflows and drops. The machine isn't "hacked" — it's drowning.

RA-flood DoS = N×RA/s × per-RA SLAAC work → softirq/CPU + receive-queue saturation

02The defense: RA Guard

RAs are legitimate only from your real routers, which live on known uplink ports. RA Guard (RFC 6105) teaches the access switch that fact: permit RAs on router ports, silently drop them on host ports. The flood never reaches the victim — it's filtered in hardware at the edge.

RA Guard = allow RA on router-role ports + drop RA on host-role ports

03Lab & install thc-ipv6

Three nodes on one VLAN: an attacker (Kali), a victim (Linux/Windows), and the switch between them. On the attacker:

sudo apt update && sudo apt install thc-ipv6     # Kali/Debian; tools are prefixed atk6-

The two tools we need: flood_router26 (the RA flood) and fake_router6 (a single rogue RA, to prove even one is caught).

04Reproduce the attack (watch the meltdown)

Attacker — start the flood (Ctrl-C to stop):

sudo atk6-flood_router26 eth0                    # classic name: flood_router26
# single rogue router variant:
sudo atk6-fake_router6 eth0 2001:db8:dead::/64

Victim (Linux) — watch the CPU queue and the address/route explosion:

top -o %CPU                                      # look for ksoftirqd near 100%
watch -n1 'echo routes=$(ip -6 route | wc -l) addrs=$(ip -6 addr show dev eth0 | grep -c inet6)'
cat /proc/net/softnet_stat                       # 2nd column climbing = packets dropped from the backlog queue

%CPU  COMMAND
 98.7 ksoftirqd/0            <- CPU buried in softirq, servicing the RA storm
routes=4127 addrs=511        <- exploding: the host obeys every forged RA
softnet_stat: 0007a1b2 00003fd9 ...   <- 2nd field rising = receive-queue drops

Victim (Windows): Task Manager shows a CPU spike (System / host process) and netsh interface ipv6 show route grows without bound. Either way you've reproduced the DoS — with RA Guard off. Stop the flood before moving on.

05Turn on RA Guard and re-test

On the access switch, mark the victim's port as a host port (no RAs allowed) and the router uplink as trusted:

ipv6 nd raguard policy HOST-PORTS
    device-role host                    ! host ports must never source RAs
!
interface GigabitEthernet1/0/10         ! the victim's access port
    ipv6 nd raguard attach-policy HOST-PORTS
!
interface GigabitEthernet1/0/1          ! uplink to the REAL IPv6 router — keep it trusted
    ipv6 nd raguard policy ROUTER       ! (device-role router)

Now run atk6-flood_router26 eth0 again from the attacker and watch the victim.

06What "protected" looks like

Victim: ksoftirqd stays low; ip -6 route / ip -6 addr counts hold steady; softnet_stat stops climbing. The flood is simply not arriving.
Switch: the RAs are dropped on the host port — confirm the policy and the drop activity:

show ipv6 nd raguard policy HOST-PORTS       # verify the policy + where it's attached
show ipv6 snooping counters interface GigabitEthernet1/0/10   # dropped RA/ND messages (platform-dependent)

Policy HOST-PORTS  device-role: host   Attached to: Gi1/0/10
Gi1/0/10  RA dropped: 48213   (rising while the flood runs)   <- filtered at the edge

proof = flood ON + RA Guard ON → ksoftirqd flat & switch "RA dropped" counter climbing

07Where to go next

RA Guard pairs with DHCPv6 Guard and IPv6 Snooping/Source Guard for a full first-hop-security set, and the same thc-ipv6 kit tests each (e.g. rogue DHCPv6). For the protocol mechanics behind RAs, NDP and SLAAC, see IPv6 Basics: Multicast, Router & Neighbor Discovery, DHCPv6. Back to the Knowledge Base, or more Networking guides.