NDP Security: Protecting Against IPv6 Network Attacks

Neighbor Discovery Protocol (NDP) replaces ARP in IPv6, handling address resolution, router discovery, and network configuration. Unlike ARP's simple request-response model, NDP manages prefix announcements, duplicate address detection, and router advertisements—all critical network functions.

The problem: NDP was designed for trusted local networks. It has no authentication. Any device on your LAN can send Router Advertisements claiming to be the default gateway, announce arbitrary prefixes, or poison neighbor caches. In modern networks with guest access, BYOD policies, and potential insider threats, this trust model breaks.

Attack impact ranges from denial of service (breaking connectivity) to man-in-the-middle attacks (intercepting traffic). As IPv6 deployment grows, attackers increasingly target NDP vulnerabilities that network teams haven't secured.

Why NDP Security Matters#

NDP was designed for trusted local networks, but modern networks with guest access, BYOD policies, and potential insider threats break this trust model.

NDP Attack Vectors#

Understanding the threats helps prioritize defenses. Here are the primary attack patterns:

Rogue Router Advertisements#

The most common and dangerous attack. A malicious device sends Router Advertisements (RA) with:

• Different default gateway (man-in-the-middle)
• Shorter router lifetime (DoS by forcing constant reconfiguration)
• Malicious DNS servers
• Invalid prefixes
• Excessive RAs flooding the network

Impact: clients reconfigure automatically, sending traffic through attacker's system or losing connectivity entirely.

Real-world scenario: An employee brings a home router to the office and plugs it in. The router sends RAs on the corporate network. Hundreds of systems reconfigure, losing Internet access or worse, routing through the unmanaged device.

Neighbor Cache Poisoning#

Attackers send spoofed Neighbor Advertisements claiming ownership of another device's IPv6 address. The network updates its neighbor cache with the attacker's MAC address.

Legitimate: 2001:db8::100 → MAC aa:bb:cc:dd:ee:ff
Attack:     2001:db8::100 → MAC 11:22:33:44:55:66 (attacker)

Result: traffic destined for the legitimate host goes to the attacker instead.

This is IPv6's version of ARP poisoning. Same attack concept, different protocol.

Duplicate Address Detection (DAD) Attacks#

When a node configures an IPv6 address via SLAAC, it performs DAD—sending Neighbor Solicitations to verify no other device uses that address. If it receives a Neighbor Advertisement claiming that address, the node refuses to configure it.

Attackers respond to all DAD attempts, preventing legitimate nodes from obtaining addresses. Your network fills with "IPv6: DAD failed" logs and devices can't get addresses.

Redirect Message Attacks#

Routers send ICMPv6 Redirect messages telling hosts about better next-hop options. Without authentication, attackers forge redirects to hijack traffic flows.

Less common than RA attacks but equally dangerous when targeting specific communications.

Router Solicitation Flooding#

While less impactful, attackers can flood the network with Router Solicitations, causing legitimate routers to waste resources generating responses. Combined with other attacks, this amplifies disruption.

Defense Mechanisms#

Multiple security technologies exist, from simple switch features to cryptographic authentication. Layer these defenses for comprehensive protection.

RA Guard: First Line of Defense#

RA Guard (RFC 6105) is a switch feature that filters Router Advertisement messages. Think of it as port security for RAs—only authorized ports can send them.

How RA Guard Works#

The switch inspects ICMPv6 packets for Router Advertisements and applies policy:

┌─────────────────────────────────────────┐
│          Switch Port Types              │
├─────────────────────────────────────────┤
│ Host Port: Block all RAs               │
│ Router Port: Allow RAs from trusted IPs│
└─────────────────────────────────────────┘

Configuration defines:

• Host-facing ports: Block RAs entirely (end-user connections)
• Router-facing ports: Allow RAs (uplink to legitimate routers)
• Device-role verification: Match source addresses against authorized routers

Cisco RA Guard Configuration#

First, define which routers are trusted by creating an access list:

! Define IPv6 access list for trusted routers
ipv6 access-list TRUSTED-ROUTERS
 permit ipv6 host 2001:db8::1 any
 permit ipv6 host 2001:db8::2 any

Then create RA Guard policies for host-facing and router-facing ports:

! Create RA Guard policy
ipv6 nd raguard policy HOST-POLICY
 device-role host
 
ipv6 nd raguard policy ROUTER-POLICY
 device-role router
 match ipv6 access-list TRUSTED-ROUTERS

Finally, apply the policies to the appropriate interfaces:

! Apply to VLANs
interface range GigabitEthernet1/0/1-48
 description Access ports
 ipv6 nd raguard attach-policy HOST-POLICY
 
interface GigabitEthernet1/0/49
 description Uplink to router
 ipv6 nd raguard attach-policy ROUTER-POLICY

Juniper RA Guard Configuration#

# Define RA Guard on access ports
set protocols router-advertisement interface ge-0/0/0.0 no-advertise
 
# Allow RAs on uplink
set protocols router-advertisement interface ge-0/0/23.0

Linux Bridge RA Guard#

For Linux-based switches or KVM virtualization:

# Enable RA Guard on bridge port
echo 1 > /sys/class/net/vnet0/brport/protect_ra
 
# Or use ebtables
ebtables -A FORWARD -p IPv6 --ip6-proto ipv6-icmp \
  --ip6-icmp-type router-advertisement -i vnet0 -j DROP

RA Guard Limitations#

RA Guard inspects packets at Layer 2. Attackers can bypass it through:

• Fragmentation: Split RA across IPv6 fragments (first fragment doesn't show ICMPv6 type)
• Tunneling: Encapsulate RAs in other protocols
• Extension headers: Add hop-by-hop or destination options headers

Modern switches include "deep inspection" modes that reassemble fragments and parse extension headers. Verify your hardware supports this or accept residual risk.

DHCPv6 Guard#

Similar to RA Guard, DHCPv6 Guard blocks DHCPv6 server messages from unauthorized ports. This prevents rogue DHCPv6 servers from issuing addresses or DNS configurations.

Cisco DHCPv6 Guard#

ipv6 dhcp guard policy CLIENT-POLICY
 device-role client
 
ipv6 dhcp guard policy SERVER-POLICY
 device-role server
 
interface range GigabitEthernet1/0/1-48
 ipv6 dhcp guard attach-policy CLIENT-POLICY
 
interface GigabitEthernet1/0/49
 ipv6 dhcp guard attach-policy SERVER-POLICY

DHCPv6 Guard operates on these message types:

• ADVERTISE (server → client)
• REPLY (server → client)
• RECONFIGURE (server → client)

Blocking these from host ports prevents rogue DHCPv6 servers while allowing legitimate client requests.

SEND: Cryptographic Authentication#

Secure Neighbor Discovery (SEND, RFC 3971) adds cryptographic signatures to NDP messages. It provides strong authentication but requires PKI infrastructure and isn't widely deployed.

How SEND Works#

SEND uses CGA (Cryptographically Generated Addresses) where the IPv6 address cryptographically binds to a public key:

1. Node generates public/private key pair
2. Creates IPv6 address with hash of public key in interface ID
3. Signs NDP messages with private key
4. Recipients verify signature matches address

┌─────────────────────────────────────────────────┐
│ Router Advertisement (with SEND)                │
├─────────────────────────────────────────────────┤
│ Standard RA fields                              │
│ + CGA Parameters (public key, modifier)         │
│ + RSA Signature                                 │
│ + Timestamp                                     │
│ + Nonce (for replay protection)                 │
└─────────────────────────────────────────────────┘

Why SEND Isn't Widespread#

Despite being standardized since 2005, SEND adoption remains minimal:

Pros:

• Cryptographically secure (can't spoof without private key)
• No switch support required (end-to-end security)
• Protects all NDP message types

Cons:

• Complex PKI infrastructure requirement
• Limited OS support (some implementations exist, rarely enabled by default)
• Performance overhead of signature verification
• Backwards compatibility issues (SEND and non-SEND nodes don't interoperate well)
• Address management complexity (CGA addresses aren't human-friendly)

Most organizations find RA Guard and DHCPv6 Guard sufficient with better cost-benefit ratio.

When to Consider SEND#

Highly secure environments where:

• You control all endpoints (can enforce SEND everywhere)
• PKI infrastructure already exists
• Performance impact is acceptable
• Regulatory compliance requires cryptographic NDP protection

IPv6 First-Hop Security Suite#

Modern switches bundle NDP security features into comprehensive first-hop security:

IPv6 Source Guard#

Validates that source IPv6 address and MAC address match bindings learned through:

• NDP snooping (tracking legitimate Neighbor Advertisements)
• DHCPv6 snooping (tracking address assignments)
• Manual bindings

Blocks packets with spoofed source addresses.

IPv6 Prefix Guard#

Validates Router Advertisements and DHCPv6 Prefix Delegation messages against configured prefix policies. Prevents attackers from announcing unauthorized prefixes.

IPv6 Destination Guard#

Enforces that destination addresses in packets match the neighbor discovery binding table. Prevents traffic to non-existent addresses (used in some DoS attacks).

ND Inspection#

Snoops all NDP messages and builds binding tables mapping IPv6 address → MAC address → port. Other security features reference these bindings for validation.

Cisco Complete FHS Configuration#

Enable IPv6 routing and create comprehensive first-hop security policies:

! Enable IPv6 on the switch
ipv6 unicast-routing
 
! Create FHS policy
ipv6 access-list ipv6-acl-fhs
 permit ipv6 any any
 
ipv6 nd inspection policy FHS-POLICY
 device-role switch
 drop-unsecure
 limit address-count 1000
 tracking enable
 
ipv6 snooping policy FHS-SNOOPING
 device-role switch

Apply the policies to VLANs and configure trusted ports:

! Apply to VLAN
vlan configuration 10
 ipv6 nd inspection attach-policy FHS-POLICY
 ipv6 snooping attach-policy FHS-SNOOPING
 
! Configure trusted ports
interface GigabitEthernet1/0/49
 ipv6 nd inspection trust
 ipv6 snooping trust

Monitoring and Detection#

Prevention isn't enough. Monitor for attack attempts and anomalies.

Key Metrics to Track#

Router Advertisement Activity:

Monitor how frequently Router Advertisements appear on your network:

# Monitor RA frequency
rdisc6 eth0
 
# Expected: RAs every 200-600 seconds from known routers
# Alert: Multiple RAs per second, RAs from unknown sources

Neighbor Discovery Message Rates:

Track NDP messages using iptables logging:

# Linux packet counting
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j LOG --log-prefix "RA: "
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j LOG --log-prefix "NA: "
 
# Watch logs
journalctl -f | grep -E "RA:|NA:"

Neighbor Cache Churn:

Monitor for unusual neighbor table changes which may indicate poisoning attacks:

# Monitor neighbor table changes
watch -n 1 "ip -6 neigh show | wc -l"
 
# High churn indicates possible poisoning

Switch Security Violations#

Monitor for RA Guard and DHCPv6 Guard violations:

# Cisco
show ipv6 nd raguard policy
show ipv6 dhcp guard policy
 
# Look for drop counters incrementing
show platform hardware fed switch active qos queue stats internal cpu policer

SIEM Integration#

Forward security events to your SIEM:

Detection rules:

• Multiple Router Advertisements from different sources in short timeframe
• RAs with unusual lifetimes (very short or very long)
• High rate of Neighbor Solicitations (potential DAD attack)
• RAs from unexpected source addresses
• DHCPv6 server messages from host ports

Example Splunk query:

index=network sourcetype=cisco:ios ipv6 "RA Guard" action=dropped
| stats count by src_ip, interface
| where count > 10

Dedicated Security Tools#

ndpmon: Open-source NDP monitoring daemon

# Install
apt-get install ndpmon
 
# Configure allowed routers in /etc/ndpmon/config_ndpmon.xml
<router>
  <mac>aa:bb:cc:dd:ee:ff</mac>
  <lla>fe80::1</lla>
</router>
 
# Start monitoring
ndpmon -c /etc/ndpmon/config_ndpmon.xml

Alerts on:

• Rogue RAs
• Unexpected prefix changes
• MAC/IPv6 binding changes
• DAD attacks

Practical Deployment Guide#

Implement NDP security systematically to avoid disrupting legitimate traffic.

Phase 1: Visibility (Week 1)#

Goal: Understand current NDP behavior

1. Enable NDP logging on switches
2. Deploy ndpmon or similar on each VLAN
3. Document all legitimate routers (MAC, IPv6 address)
4. Capture one week of baseline RA/NA traffic
5. Identify any unexpected sources

Phase 2: Passive Protection (Week 2)#

Goal: Enable detection without enforcement

1. Configure RA Guard in monitor mode (if supported)
2. Set up alerting for violations
3. Verify no false positives from legitimate infrastructure
4. Tune policies based on alerts

Phase 3: Active Protection (Week 3-4)#

Goal: Enforce security policies

1. Enable RA Guard in blocking mode on test VLAN
2. Verify client connectivity and address assignment
3. Expand to production VLANs incrementally
4. Add DHCPv6 Guard and other FHS features
5. Document exceptions and trusted ports

Phase 4: Ongoing Management#

Goal: Maintain security posture

1. Review violation logs weekly
2. Update trusted router lists when infrastructure changes
3. Test security during vulnerability assessments
4. Train team on NDP security concepts

Configuration Best Practices#

For Access Switches#

! Default stance: all ports are host-facing
ipv6 nd raguard policy DEFAULT-HOST
 device-role host
 
! Apply to all ports by default
interface range GigabitEthernet1/0/1-48
 ipv6 nd raguard attach-policy DEFAULT-HOST
 ipv6 dhcp guard attach-policy CLIENT-POLICY
 ipv6 snooping
 
! Explicitly trust uplinks (use manual override)
interface GigabitEthernet1/0/49
 description Uplink to distribution
 ipv6 nd raguard attach-policy ROUTER-POLICY
 ipv6 dhcp guard attach-policy SERVER-POLICY
 ipv6 snooping trust

Principle: Deny by default, permit explicitly.

For Distribution/Core#

! Less restrictive since infrastructure is controlled
! But still validate sources
ipv6 nd raguard policy INFRA-POLICY
 device-role router
 match ipv6 access-list KNOWN-ROUTERS

For Wireless Controllers#

Guest networks especially vulnerable:

! Strict RA blocking on guest SSID
ipv6 nd raguard policy GUEST-POLICY
 device-role host
 no-ra

For Data Centers#

Virtualized environments need RA Guard on virtual switches:

VMware:

• vSphere 6.5+ supports IPv6 security policies
• Configure RA Guard on distributed virtual switch
• Apply to all guest VLANs

KVM/Linux bridges:

# Enable RA protection on all VM interfaces
for interface in /sys/class/net/vnet*/brport/protect_ra; do
  echo 1 > "$interface"
done

Attack Simulation for Testing#

Verify your defenses work before an attacker tests them for you.

Test RA Guard#

Use radvd to send test Router Advertisements from a host port:

# Install radvd
apt-get install radvd
 
# Configure test RA (/etc/radvd.conf)
interface eth0 {
  AdvSendAdvert on;
  prefix 2001:db8:bad::/64 {
    AdvOnLink on;
    AdvAutonomous on;
  };
};
 
# Start radvd
systemctl start radvd
 
# Expected: RA Guard blocks these messages
# Verify: Check switch logs for violations

Test ND Inspection#

Attempt neighbor cache poisoning:

# Send spoofed Neighbor Advertisement
ndsend eth0 2001:db8::victim -a aa:bb:cc:dd:ee:ff --na-override
 
# Expected: Source Guard or ND Inspection blocks
# Verify: Neighbor cache unchanged on target

Professional Testing Tools#

THC IPv6 Attack Toolkit:

# Install
apt-get install thc-ipv6
 
# Test RA flooding
flood_router6 eth0
 
# Test DAD attack
dos-new-ip6 eth0
 
# Expected: All attacks blocked by FHS features

Scapy for custom tests:

from scapy.all import *
 
# Craft malicious RA
ra = IPv6(dst="ff02::1")/ICMPv6ND_RA()/ICMPv6NDOptPrefixInfo(prefix="2001:db8:bad::")
send(ra, iface="eth0")

Only perform attack testing on isolated test networks or with explicit authorization.

Common Mistakes#

1. Forgetting Uplink Trust#

Configuring RA Guard on all ports without explicitly trusting uplinks blocks legitimate RAs. Your entire network loses IPv6 connectivity.

Symptom: Clients stop receiving addresses after enabling RA Guard.

Fix: Identify and trust ports connected to legitimate routers.

2. Inconsistent VLAN Coverage#

Applying security to some VLANs but not others. Attackers connect to unprotected VLANs and pivot.

Fix: Apply first-hop security policies to all VLANs, including management networks.

3. Not Testing Before Production#

Enabling blocking mode without testing causes outages when legitimate traffic gets filtered.

Fix: Always test in lab environment or monitor mode first.

4. Ignoring Wireless Networks#

Wireless controllers and access points often bypass RA Guard if not configured properly.

Fix: Verify security policies apply to wireless VLANs. Test from WiFi clients.

5. Neglecting Virtual Environments#

VMs can send RAs within virtual switches, attacking other VMs on the same host.

Fix: Enable RA protection on virtual switches and hypervisor networking.

When Security Breaks Legitimate Use Cases#

Some scenarios require RAs from host ports:

Bridge Mode Routers#

Small routers in bridge/passthrough mode relay RAs from upstream.

Solution: Explicitly trust these ports or use different network design.

Router Lab Environments#

Testing OSPF, BGP, or router configurations requires sending RAs.

Solution: Dedicated security policy for lab VLANs allowing RAs from any source.

Mobile Hotspot Tethering#

Smartphones providing hotspot functionality send RAs.

Solution: Guest networks can allow this, but corporate networks should block it.

Document all exceptions and review regularly.

The Future: Work in Progress#

NDP security evolves but challenges remain:

Positive developments:

• Broader RA Guard deployment
• Improved switch support for deep inspection
• Better integration with SIEM/SOC workflows

Ongoing challenges:

• SEND adoption still minimal
• Many IoT devices lack security awareness
• Operational complexity vs. IPv4's simpler ARP

Emerging technologies:

• Software-defined networking (SDN) enabling more flexible security policies
• Machine learning for anomaly detection in NDP traffic
• Automated response to detected attacks

Start Securing NDP Now#

NDP attacks are real and increasing. The security mechanisms exist and work—they just need deployment.

Minimum viable NDP security:

1. Enable RA Guard on all access switches
2. Trust only uplink ports
3. Monitor for violations
4. Respond to alerts

This stops 95% of NDP attacks with minimal effort. Add DHCPv6 Guard, Source Guard, and comprehensive monitoring for defense in depth.

Don't wait for an attack to start taking NDP security seriously. Your IPv4 network has firewall rules, port security, and DHCP snooping. IPv6 deserves the same attention.

Related Articles#

• IPv6 Neighbor Discovery Protocol - How NDP works and why it's essential
• IPv6 Security Best Practices - Comprehensive IPv6 security guide
• IPv6 Firewall Configuration - Securing IPv6 at the network edge

Frequently Asked Questions#