IPv6 First-Hop Security Part 2: ND Inspection, Snooping, and Source Guard

RA Guard and DHCPv6 Guard stop the loud attacks: rogue routers and rogue DHCP servers. But there is a quieter layer of IPv6 abuse that operates below them, at the level of individual addresses. A host that spoofs its neighbor's IPv6 address, or poisons the switch's understanding of who lives where, can intercept traffic without ever sending an RA. Stopping that requires the switch to actually know which address belongs on which port, and then enforce it.

That knowledge is the device-tracking binding table, and the features that build and enforce it are ND Inspection, IPv6 Snooping, and IPv6 Source Guard. This article covers all three. It is the companion to RA Guard and DHCPv6 Guard and extends the Infrastructure Security cluster guide.

Everything Depends on the Binding Table

The foundation of all IPv6 first-hop security is a table that maps, for each entry: an IPv6 address, the MAC address that owns it, the switch port it lives behind, and the VLAN. This is device tracking (the IPv6 analogue of the DHCP snooping binding table in IPv4).

SW1(config)# ipv6 nd inspection policy HOST-NDI
SW1(config)# vlan configuration 1
SW1(config-vlan-config)#  device-tracking attach-policy HOST-NDI

Once device tracking is running, the switch learns bindings by watching ND traffic (Neighbor Solicitations, Neighbor Advertisements, DAD) and DHCPv6 exchanges. Every legitimate host announces its address through normal ND, and the switch records it. That table then becomes the ground truth every other feature checks against.

On modern IOS XE the older ipv6 nd inspection and ipv6 snooping commands are being folded into the unified device-tracking policy framework. The switch tells you so directly when you use the legacy syntax:

SW1(config-vlan-config)# ipv6 nd inspection
WARNING: ipv6 nd inspection attach-policy to vlan deprecated, use device-tracking attach-policy

Take the hint and use device-tracking policies on current software. The concepts are identical; the CLI is consolidated.

ND Inspection: Validating the Neighbor Discovery Itself

Neighbor Discovery is IPv6's replacement for ARP, and like ARP it is unauthenticated and forgeable. ND Inspection validates ND messages against the binding table and drops the ones that lie.

The two abuses it stops:

ND Inspection cross-checks the source address and MAC in each ND message against the binding table. If a Neighbor Advertisement claims an address that the table says lives on a different port or MAC, it is a spoof, and it is dropped. The victim's traffic keeps flowing to the real owner.

IPv6 Source Guard: Enforcing at the Data Plane

ND Inspection validates the control traffic (the ND messages). Source Guard validates the data traffic. It is the enforcement teeth: for every packet arriving on a port, it checks the source IPv6 address against the binding table, and if the source does not match what the table says should be on that port, the packet is dropped.

SW1(config)# ipv6 source-guard policy HOST-SG
SW1(config)# interface Ethernet0/1
SW1(config-if)#  ipv6 source-guard attach-policy HOST-SG

The effect: a host on Et0/1 can only send packets sourced from the IPv6 address the binding table recorded for Et0/1. It cannot spoof its neighbor's address, cannot spoof the gateway, cannot spoof anything but itself. This is the IPv6 equivalent of IP Source Guard in IPv4, and it closes the loop that RA Guard and ND Inspection open: RA Guard stops rogue gateways, ND Inspection stops address theft in the control plane, and Source Guard stops spoofing in the data plane.

How the Layers Stack

The four features are not alternatives. They are a defence in depth, each closing a gap the others leave open:

Deploy them together on access ports and a compromised or malicious host is boxed in: it cannot be the gateway, cannot be the DNS server, cannot steal a neighbor's address, and cannot even spoof a source in the packets it sends. That is the IPv6 access-edge posture every campus should aim for.

Verifying the Binding Table

The command that shows you the ground truth:

SW1#show device-tracking database
    Network Layer Address       Link Layer Address  Interface  vlan  prlvl  age   state
 ND  2001:DB8:10::5054:FF:...   5054.00dc.9702      Et0/1      1     0005   30s   REACHABLE
 ND  FE80::5054:FF:FEDC:9702    5054.00dc.9702      Et0/1      1     0005   30s   REACHABLE

Each row is a validated binding: this address, on this MAC, behind this port. Source Guard permits only traffic matching these rows; ND Inspection permits only ND matching them. If a host's entries are missing, its traffic may be dropped, which is the number-one operational gotcha (see below).

Operational Reality

These features are powerful and they will break things if deployed carelessly. The honest guidance:

• Binding table timing. A host that has been silent may age out of the table, and then Source Guard drops its traffic until it speaks ND again. Tune the reachable/stale/down timers, and understand that a machine returning from sleep may have a brief blackout until it re-registers.
• Static entries for silent devices. Some devices (certain appliances, printers) barely emit ND. Add static binding entries for them, or Source Guard will treat them as spoofers.
• Trust the uplinks. Device tracking, like RA Guard, distinguishes host ports from infrastructure ports. Get the roles wrong and you either fail to protect or you break legitimate traffic on trunks.
• Roll out in stages. Deploy device tracking first and let the binding table populate and stabilise. Then add ND Inspection. Add Source Guard last, and watch for drops of legitimate but quiet hosts. Enabling all four at once on a live network is a way to generate a lot of tickets.
• Platform variance. The exact CLI and capabilities differ across Catalyst generations and IOS XE releases, and the legacy vs device-tracking syntax coexists awkwardly. Verify on your specific platform and code.

FAQ

Do I need all four features?

For a strong posture, yes, they cover different attack surfaces. If you deploy only two, RA Guard and DHCPv6 Guard stop the highest-impact attacks with the lowest operational risk. ND Inspection and Source Guard add depth but need more care.

What is the difference between ND Inspection and Source Guard?

ND Inspection validates ND control messages against the binding table. Source Guard validates data-plane packet sources against it. One protects the neighbor-discovery process, the other protects forwarding.

Why is legitimate traffic being dropped?

Almost always a missing or aged-out binding-table entry. Check show device-tracking database for the host. Silent devices need static entries or longer timers.

Is this related to DHCP snooping?

It is the IPv6 parallel. The device-tracking binding table plays the role that the DHCP snooping binding table plays for IPv4 Dynamic ARP Inspection and IP Source Guard.

Does device tracking work with SLAAC and DHCPv6 both?

Yes. It learns bindings from ND (which covers SLAAC addresses) and from DHCPv6 exchanges. Both addressing models are covered.

Key Takeaways

• All IPv6 first-hop security rests on the device-tracking binding table: which address, on which MAC, behind which port.
• ND Inspection validates Neighbor Discovery messages against that table, stopping NA spoofing and DAD abuse (the IPv6 ARP-poisoning equivalents).
• IPv6 Source Guard validates data-plane packet sources against the table, so a host can only send from its own address.
• Together with RA Guard and DHCPv6 Guard, they box in a malicious host completely: no rogue gateway, no rogue DNS, no address theft, no source spoofing.
• On modern IOS XE, use the unified device-tracking policy framework; the switch flags the legacy ipv6 nd inspection syntax as deprecated.
• Deploy in stages (tracking, then inspection, then source guard) and add static bindings for silent devices, or you will drop legitimate traffic.

Next: RA Guard and DHCPv6 Guard if you skipped it, or the Infrastructure Security cluster guide.