IPv6 ND Inspection and Source Guard Configuration

IPv6 replaced ARP with Neighbor Discovery, and with it inherited the same weakness: the protocol is unauthenticated and forgeable. A host that sends an unsolicited Neighbor Advertisement claiming someone else's address poisons its neighbours' caches, and a host that answers every Duplicate Address Detection probe prevents anyone else on the segment from configuring an address. IPv6 ND Inspection is the control-plane defence, and Source Guard is the data-plane enforcement that gives it teeth. This article covers both, plus the binding table that makes them work.

The foundation: a binding table

Every IPv6 first-hop security feature reads from the same table, which maps an IPv6 address to the MAC address that owns it, the switch port it lives behind, and the VLAN. Your chosen inspection feature builds that table, and the enforcement features check against it:

SW1# show ipv6 neighbors binding
SW1# show device-tracking database

Each row is a validated binding. If a host's entries are missing, its traffic may be dropped — that is the number-one operational gotcha, and the reason you verify the table immediately after enabling a policy.

What ND Inspection examines

When a Neighbor Advertisement claims an address the table says lives on a different port, inspection drops it. That single behaviour defeats NA spoofing in the control plane.

Configuring it on Cisco IOS / IOS-XE

On current software the unified device-tracking policy framework replaces the legacy commands. Attach a policy to the VLAN or to individual interfaces:

SW1(config)# device-tracking policy HOST-TRACK
SW1(config-device-tracking)# security-level guard
SW1(config-device-tracking)# tracking enable
SW1(config-device-tracking)# limit address-count 10
SW1(config-device-tracking)# exit

SW1(config)# vlan configuration 10
SW1(config-vlan-config)# device-tracking attach-policy HOST-TRACK

The older syntax still configures the feature but the switch tells you to move on:

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

Mark uplinks and router-facing ports as trusted with a separate policy so learned bindings from those ports are not challenged:

SW1(config)# device-tracking policy UPLINK-TRUST
SW1(config-device-tracking)# trusted-port
SW1(config-device-tracking)# device-role router
SW1(config-device-tracking)# exit
SW1(config)# interface GigabitEthernet1/0/24
SW1(config-if)# device-tracking attach-policy UPLINK-TRUST

The limit address-count parameter is a genuine DoS control: without it, an attacker can flood DAD solicitations and evict legitimate bindings from the table. Normal hosts need two to four addresses; virtualisation platforms need more, so set the limit per port class rather than globally.

Enforcing in the data plane with Source Guard

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

ND Inspection validates ND messages; Source Guard validates forwarded data. With both attached, a host on Ethernet0/1 can only send packets sourced from the address the binding table recorded for that port. It cannot spoof its neighbour, the gateway, or anything else.

Juniper EX switches

Juniper calls the feature Neighbor Discovery Inspection and configures it under the dhcp-security hierarchy. Enabling it automatically enables DHCPv6 snooping for the VLAN, because inspection validates ND messages against the DHCPv6 snooping binding table:

set vlans v10 forwarding-options dhcp-security neighbor-discovery-inspection
set vlans v10 forwarding-options dhcp-security ipv6-source-guard
set vlans v10 forwarding-options dhcp-security group SERVERS overrides trusted
set vlans v10 forwarding-options dhcp-security group SERVERS interface ge-0/0/23.0

show dhcp-security binding
show neighbor-discovery-inspection statistics

The four layers, deployed together

• Device tracking / snooping — builds the binding table everything else reads.
• RA Guard — stops rogue gateways advertising themselves.
• DHCPv6 Guard — stops rogue DHCPv6 servers handing out a malicious DNS server.
• ND Inspection — stops address theft in ND.
• Source Guard — stops source spoofing in forwarded traffic.

They are not alternatives; each closes a gap the others leave open. Deployed together on access ports, a compromised host cannot be the gateway, cannot be the DNS server, cannot steal a neighbour's address, and cannot spoof a source in the packets it sends.

Rollout checklist

1. Enable tracking on one VLAN with a small address limit and watch the binding table populate.
2. Confirm trusted ports (uplinks, router ports, hypervisor trunks) are marked before enabling guard-level enforcement.
3. Apply Source Guard to access ports first; a missing binding on a hypervisor trunk breaks every VM on it.
4. Alert on binding-table churn — a spike is either a busy subnet or an attack.

See also: IPv6 first-hop security: RA Guard and DHCPv6 Guard, SLAAC vs DHCPv6 in the enterprise, and 802.1X and MAB port authentication.

原文链接：https://pinglabz.com/ipv6-nd-inspection-source-guard