Skip to content
Log in Sign up My account

3.4 IPv6 First Hop Security

Blueprint 3.4: Describe IPv6 First Hop security features

  • 3.4.a RA guard
  • 3.4.b DHCP guard
  • 3.4.c Binding table
  • 3.4.d ND inspection and snooping
  • 3.4.e Source guard

The verb is describe. You will not be asked to configure every option, but you must know which feature stops which attack, which features depend on the binding table, and what a port role means. Expect matching questions and short exhibits where a policy is attached to the wrong port.

Why IPv6 needs first hop security

On an IPv4 access switch you already know the defences: DHCP snooping, Dynamic ARP Inspection and IP Source Guard. IPv6 has the same problems, plus one new one, because so much of its first hop behaviour is automatic and trusts whoever answers first.

IPv6 mechanism What it does How it can be abused IPv4 analogy
Router Advertisement (RA) Tells hosts the default gateway, prefixes for SLAAC, and whether to use DHCPv6 Any host can send RAs and become the default gateway (man in the middle) or advertise a bogus prefix (denial of service) Rogue default gateway via DHCP
DHCPv6 Assigns addresses, DNS servers and other options A rogue server answers Solicits and hands out a malicious DNS server Rogue DHCP server
Neighbor Solicitation and Advertisement (NS, NA) Address resolution and Duplicate Address Detection (DAD) Spoofed NAs poison neighbor caches; answering every DAD probe stops hosts from getting an address ARP spoofing
Source address Any host can choose its own addresses with SLAAC Spoofed source addresses hide an attacker or launch reflection attacks IP spoofing

Cisco groups the switch features that address these under IPv6 First Hop Security (FHS). On current Catalyst 9000 software they are built on a common framework called Switch Integrated Security Features (SISF), configured with device-tracking and feature-specific policies.

graph TB
  subgraph Glean ["Learning"]
    SN["ND snooping<br/>NS, NA, DAD"] --> BT[("Binding table<br/>IPv6, MAC, VLAN, port")]
    DS["DHCPv6 snooping<br/>server replies"] --> BT
  end
  subgraph Enforce ["Enforcement that uses the table"]
    BT --> NDI["ND inspection<br/>validates NS and NA"]
    BT --> SG["Source guard<br/>validates data packets"]
  end
  subgraph Stateless ["Enforcement by port role, no table needed"]
    RAG["RA guard<br/>blocks RAs on host ports"]
    DHG["DHCPv6 guard<br/>blocks server messages on client ports"]
  end

RA guard

RA guard is defined in RFC 6105. The switch inspects Router Advertisements (ICMPv6 type 134) and Redirects arriving on a port, and drops them if the port's policy says no router lives there.

Device role Effect on incoming RAs
host (default) All RAs and redirects dropped
router RAs allowed, optionally checked against further criteria
switch Port connects to another switch; used for trusted inter-switch links
monitor RAs are not forwarded to the port but RS can be; used for a monitoring device

A router-role policy can do more than permit. It can check that RAs come from a known source and carry expected content:

ipv6 access-list LEGIT-ROUTERS
 permit ipv6 host FE80::1 any
ipv6 prefix-list LAN-PREFIX permit 2001:DB8:10::/64
!
ipv6 nd raguard policy HOST-RA
 device-role host
ipv6 nd raguard policy ROUTER-RA
 device-role router
 match ipv6 access-list LEGIT-ROUTERS
 match ra prefix-list LAN-PREFIX
 router-preference maximum medium
 hop-limit minimum 64
 managed-config-flag on
!
interface range GigabitEthernet1/0/1 - 46
 ipv6 nd raguard attach-policy HOST-RA
interface GigabitEthernet1/0/48
 ipv6 nd raguard attach-policy ROUTER-RA

Policies can also be attached to a VLAN (vlan configuration 10 then ipv6 nd raguard attach-policy HOST-RA), in which case they apply to every port in the VLAN unless a port has its own policy.

Limitations to know: RA guard only works on traffic that passes through the switch, so it does not protect two hosts on the same port behind an unmanaged hub. Early implementations could be bypassed by hiding the RA behind IPv6 extension headers or fragments. RFC 7113 describes how implementations should close that gap.

Exam trap

Attaching a host-role RA guard policy with an interface range that also covers the router uplink, or at VLAN level without a router-role override on the uplink, drops the legitimate router's RAs. Hosts then lose their default gateway when their existing router entry times out. The fix is a router-role policy (or no RA guard policy) on the uplink, not removing RA guard everywhere.

DHCPv6 guard

DHCPv6 guard does for DHCPv6 what RA guard does for RAs. It drops server-to-client messages, such as Advertise and Reply, arriving on ports where no DHCPv6 server or relay should exist.

Device role Effect
client (default) Server messages arriving on the port are dropped
server Server messages allowed, optionally checked against a list of server addresses, assigned prefixes and preference values 
ipv6 access-list DHCP-SERVERS
 permit ipv6 host FE80::1 any
 permit ipv6 host 2001:DB8:99::53 any
ipv6 prefix-list DHCP-PREFIXES permit 2001:DB8:10::/64 le 128
!
ipv6 dhcp guard policy CLIENT-DHCP
 device-role client
ipv6 dhcp guard policy SERVER-DHCP
 device-role server
 match server access-list DHCP-SERVERS
 match reply prefix-list DHCP-PREFIXES
 preference max 255
!
interface range GigabitEthernet1/0/1 - 46
 ipv6 dhcp guard attach-policy CLIENT-DHCP
interface GigabitEthernet1/0/48
 ipv6 dhcp guard attach-policy SERVER-DHCP

DHCPv6 guard and RA guard are independent. A network that uses SLAAC only still benefits from DHCPv6 guard, because a rogue DHCPv6 server can answer the Information-Request that hosts send for DNS settings when the RA has the Other-config flag set.

The binding table

The binding table is the core of SISF. It records, for each IPv6 (and IPv4) address seen on the switch, the MAC address, VLAN, port, how it was learned and its state. It is not a mitigation on its own. It is the database that ND inspection and source guard check traffic against.

Source of entries How it is learned
ND snooping Gleaned from DAD Neighbor Solicitations and from NS and NA exchanges
DHCPv6 snooping Gleaned from DHCPv6 Reply messages that assign an address
ARP and DHCPv4 The same table also tracks IPv4 entries on SISF platforms
Static device-tracking binding vlan 10 2001:DB8:10::50 interface Gi1/0/20 aabb.cc00.2000

Entries have a lifecycle. A new entry starts as tentative while DAD runs, becomes reachable when confirmed, turns stale if it is not refreshed, and is verified with a probe before being removed. When two ports claim the same address, the binding table decides which one is the owner, typically preferring a DHCP-assigned or static entry over a gleaned one and an existing reachable entry over a newcomer.

SW1# show device-tracking database
Binding Table has 3 entries, 3 dynamic (limit 200000)
Codes: L - Local, S - Static, ND - Neighbor Discovery, DH6 - IPv6 DHCP
    Network Layer Address          Link Layer Address  Interface  vlan  prlvl  age  state      Time left
ND  FE80::5054:FF:FE01:1           5254.0001.0001      Gi1/0/1    10    0005   20s  REACHABLE  284 s
ND  2001:DB8:10::5054:FF:FE01:1    5254.0001.0001      Gi1/0/1    10    0005   20s  REACHABLE  284 s
DH6 2001:DB8:10::1F3A              5254.0002.0002      Gi1/0/2    10    0024   41s  REACHABLE  262 s

The output above is abridged. Older platforms used ipv6 snooping commands and show ipv6 neighbors binding for the same information.

ND inspection and snooping

ND snooping is the learning half: the switch watches ND and DHCPv6 traffic and fills the binding table. ND inspection is the enforcement half: it validates NS and NA messages against the table and drops those that make false claims, such as an NA that announces an address bound to a different port or MAC.

On SISF platforms both are controlled by the security-level of the device-tracking policy:

Security level Behaviour
glean Learn bindings only. Nothing is dropped.
inspect Learn bindings and validate ND messages. Messages that conflict with an existing binding are dropped.
guard (default) Everything inspect does, and also reject RAs and DHCPv6 server messages unless the port is trusted or another policy allows them 
device-tracking policy ACCESS-TRACK
 security-level guard
 tracking enable
 limit address-count 10
!
device-tracking policy UPLINK-TRACK
 trusted-port
 device-role switch
!
interface range GigabitEthernet1/0/1 - 46
 device-tracking attach-policy ACCESS-TRACK
interface GigabitEthernet1/0/48
 device-tracking attach-policy UPLINK-TRACK

limit address-count caps how many addresses one port may own, which blunts attacks that try to exhaust the binding table or neighbor caches.

Exam trap

ND inspection and RA guard are often confused. RA guard looks at Router Advertisements and decides by port role. ND inspection looks at Neighbor Solicitations and Advertisements and decides by comparing them with the binding table. A spoofed NA that poisons a neighbor cache is ND inspection's job, not RA guard's.

IPv6 source guard

Source guard is a data plane filter. A packet arriving on a port is forwarded only if its source address is bound to that port in the binding table. Traffic from an address the switch never learned, or one learned on a different port, is dropped.

ipv6 source-guard policy ACCESS-SG
 validate address
!
interface range GigabitEthernet1/0/1 - 46
 device-tracking attach-policy ACCESS-TRACK
 ipv6 source-guard attach-policy ACCESS-SG

Because it depends entirely on the binding table, source guard needs snooping (device tracking) on the same port. A variant, prefix guard (validate prefix), checks that the source belongs to a prefix learned from the router's RAs or a DHCPv6 prefix delegation, rather than requiring every address to be individually learned.

IPv6 source guard uRPF
Where Access switch port Router interface
Checks the source against Binding table: address, MAC, port FIB: route back to the source
Granularity Individual host addresses Prefixes
Stops A host spoofing a neighbor's address on the same subnet Spoofed addresses from outside the prefixes behind the interface

Exam trap

A host with a valid address can be blocked by source guard if the switch never learned its binding, for example after the switch reloaded while the host kept its address and did not run DAD again. The symptom is a host that cannot send traffic although its configuration is correct. A static binding or forcing the host to re-run DAD resolves it.

Feature summary

Feature Threat Inspects Needs binding table Decides by
RA guard Rogue router, bogus prefixes RAs and Redirects No Port role
DHCPv6 guard Rogue DHCPv6 server DHCPv6 server messages No Port role, server ACL, prefix list
Binding table None by itself Stores address, MAC, VLAN, port Is the table n/a
ND snooping None by itself Gleans ND and DHCPv6 Fills the table n/a
ND inspection Neighbor cache poisoning, DAD attacks NS and NA Yes Comparison with the table
Source guard Source address spoofing All data packets Yes Comparison with the table

Lab: RA guard and DHCPv6 guard

This lab needs a switch image that supports IPv6 FHS. Use a Catalyst 9000v image if your CML release includes one, or a physical Catalyst 9000. Feature support on IOSvL2 varies by release: check with ipv6 nd raguard ? in global configuration before you start.

Topology

graph LR
  R1["R1 legitimate router<br/>2001:db8:10::1/64"] -- "Gi1/0/48" --- SW1["SW1 VLAN 10"]
  ROGUE["R2 rogue router and DHCPv6 server<br/>2001:db8:bad::1/64"] -- "Gi1/0/2" --- SW1
  H1["H1 IOSv as host<br/>SLAAC"] -- "Gi1/0/1" --- SW1

All three router ports are access ports in VLAN 10.

Steps

  1. On R1: ipv6 unicast-routing, and on the LAN interface ipv6 address 2001:DB8:10::1/64 and ipv6 address FE80::1 link-local.
  2. On H1 (IOSv): no ipv6 unicast-routing, then on the interface ipv6 address autoconfig default and ipv6 enable.
  3. On R2: ipv6 unicast-routing, ipv6 address 2001:DB8:BAD::1/64 on the LAN interface. Also build a rogue DHCPv6 server: ipv6 dhcp pool ROGUE with dns-server 2001:DB8:BAD::53, and on the interface ipv6 dhcp server ROGUE and ipv6 nd other-config-flag.
  4. Without FHS, run show ipv6 routers on H1. Expected: two routers, FE80::1 and R2's link-local address. show ipv6 route ::/0 may point at either one. H1 also has an address from the rogue 2001:DB8:BAD::/64 prefix in show ipv6 interface brief.
  5. On SW1, create HOST-RA and ROUTER-RA from the RA guard section, attach HOST-RA to Gi1/0/1 and Gi1/0/2, and ROUTER-RA (without the ACL and prefix-list matches, to keep it simple) to Gi1/0/48. Shut and re-enable H1's interface so it relearns. Expected: show ipv6 routers on H1 lists only FE80::1, and the rogue prefix disappears.
  6. Create CLIENT-DHCP and attach it to Gi1/0/1 and Gi1/0/2. On H1 configure ipv6 address dhcp temporarily or use debug ipv6 dhcp while bouncing the interface. Expected: no Advertise from R2 reaches H1.
  7. Break: attach HOST-RA to Gi1/0/48 as well. Expected: after the router entry ages out (or after bouncing H1's interface), H1 has no default router. show ipv6 nd raguard policy HOST-RA lists Gi1/0/48 as a target. Fix by attaching ROUTER-RA to Gi1/0/48 again.

Expected verification output

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

H1# show ipv6 routers
Router FE80::1 on GigabitEthernet0/0, last update 0 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
  HomeAgentFlag=0, Preference=Medium
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:10::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800

Quick check

Which two IPv6 first hop security features make their decision from port role alone, without consulting the binding table?

RA guard and DHCPv6 guard. Both drop server or router messages arriving on ports that are not designated as router or server ports.

An attacker sends Neighbor Advertisements claiming the default gateway's IPv6 address. Which feature drops them, and what does it rely on?

ND inspection. It compares the NA with the binding table, sees that the gateway's address is bound to a different port and MAC, and drops the message.

Why does IPv6 source guard require ND or DHCPv6 snooping on the same port?

Source guard forwards only packets whose source address is in the binding table for that port. Snooping is what fills the table. Without it, there are no bindings and legitimate traffic would be dropped.

References