First Hop Security in
IPv6 (FHS IPv6) is a set of IPv6 security features, the policies of which can
be attached to a physical interface,
or a VLAN. An IPv6 software policy database service stores and
accesses these policies. When a policy is configured or modified, the
attributes of the policy are stored or updated in the software policy database,
then applied as was specified. The following IPv6 policies are currently
supported:
-
IPv6 Snooping
Policy—IPv6 Snooping Policy acts as a container policy that enables most of the
features available with FHS in IPv6.
- IPv6 FHS Binding Table
Content—A database table of IPv6 neighbors connected to the switch is created
from information sources such as Neighbor Discovery (ND) protocol snooping.
This database, or binding, table is used by various IPv6 guard features (such
as IPv6 ND Inspection) to validate the link-layer address (LLA), the IPv4 or
IPv6 address, and prefix binding of the neighbors to prevent spoofing and
redirect attacks.
-
NDP Address
Gleaning—The NDP address gleaning feature is enabled by default when you
configure the
ipv6 snooping
policy global configuration command. To disable this function, enter the
no protocol ndp
global configuration command and attach the policy to the target port or
VLAN.
-
IPv6 DHCP Address
Gleaning—The IPv6 DHCP address gleaning feature provides the ability to extract
addresses from DHCP messages and populate the binding table. The switch
extracts address binding information from the following types of DHCPv6
exchanges (using User Datagram Protocol (UDP), ports 546 and 547):
-
DHCP-REQUEST
-
DHCP-CONFIRM
-
DHCP- RENEW
-
DHCP-REBIND
-
DHCP-REPLY
-
DHCP-RELEASE
-
DHCP-DECLINE
After a switch
receives a DHCP-REQUEST message from a client, one of the following can happen:
-
The switch
receives a DHCP-REPLY message from the DHCP server and a binding table entry is
created in the REACHABLE state and completed. The reply contains the IP address
and the MAC address in the Layer 2 DMAC field.
Creating an
entry in the binding table allows the switch to learn addresses assigned by
DHCP. A binding table can have one of the following states:
-
INCOMPLETE—Address resolution is in progress and the link-layer
address is not yet known.
-
REACHABLE—The table is known to be reachable within the last
reachable time interval.
-
STALE—The
table requires re-resolution.
-
SEARCH—The
feature creating the entry does not have the Layer 2 address and requests the
binding table to search for the Layer 2 address.
-
VERIFY—The
Layer 2 and Layer 3 addresses are known and a duplicate address detection (DAD)
Neighbor solicitation (NS) unicast message is sent to the Layer 2 and Layer 3
destinations to verify the addresses.
-
DOWN—The
interface from which the entry was learned is down, preventing verification.
-
The DHCP
server sends a DHCP-DECLINE or DHCP release message and the entry is deleted.
-
The client
sends a DHCP-RENEW message to the server that allocates the address or
aDHCP-REBIND message to any server and the lifespan of the entry is extended.
-
The server
does not reply and the session is timed-out.
To enable this
feature, configure a policy using the ipv6 snooping policy policy-name global
configuration command.
You can configure
a policy and attach it to a DHCP guard to prevent the binding table from being
filled with forged DHCP messages.
- IPv6 Neighbor Discovery
Inspection—IPv6 ND inspection learns and secures bindings for stateless
autoconfiguration addresses in Layer 2 neighbor tables. IPv6 ND inspection
analyzes neighbor discovery messages in order to build a trusted binding table
database and IPv6 neighbor discovery messages that do not conform are dropped.
An ND message is considered trustworthy if its IPv6-to-Media Access Control
(MAC) mapping is verifiable.
This feature
mitigates some of the inherent vulnerabilities of the ND mechanism, such as
attacks on DAD, address resolution, router discovery, and the neighbor cache.
For detailed information
about IPv6 Neighbor Discovery Inspection, see the “IPv6 Neighbor Discovery
Inspection” chapter of the Cisco IOS IPv6 Configuration Guide Library on
Cisco.com.
-
IPv6 Binding Table
Recovery Mechanism—The IPv6 first-hop security binding table recovery feature
recovers the missing binding table entries when the resolution for a
destination address fails in the destination guard. Upon a failure, a binding
table entry is recovered by querying the DHCP server or the destination host
depending on the configuration.
The recovery
mechanism blocks any data traffic sourced from an unknown source, that is, a
source not already specified in the binding table and previously learned by
using NDP or Dynamic Host Configuration Protocol (DHCP) gleaning.
For detailed
information about IPv6 binding table recovery, see the “IPv6 First-Hop Security
Binding Table” chapter of the Cisco IOS IPv6 Configuration Guide Library
on Cisco.com.
-
IPv6 Data
Address Gleaning—The IPv6 data address gleaning feature provides the ability to
extract addresses from redirected datatraffic, to discover neighbors, and to
populate binding tables.
When a port
receives a data packet where the binding is unknown, that is, the neighbor is
in an INCOMPLETE state and the link-layer address is not yet known, the switch
sends a DAD NS NDP unicast message to the port from which the data packet was
received.
After the host
replies with a DAD Neighbor Advertisement (NA) NDP message, the binding table
is updated and a private VLAN ACL (PVACL) is installed in the hardware for this
binding.
If the host does
not reply with a DAD NA, after the binding table timer expires, the hardware is
notified and any resources associated with that binding are released.
To enable this
feature, configure a policy with
data-glean
and attach the policy to a target port. To debug the policy, use the
debug ipv6
snooping privileged EXEC command.
-
IPv6 Router
Advertisement Guard—The IPv6 Router Advertisement (RA) guard feature enables
the network administrator to block or reject unwanted or rogue RA guard
messages that arrive at the network switch platform. RAs are used by routers to
announce themselves on the link. The RA Guard feature analyzes the RAs and
filters out bogus RAs sent by unauthorized routers. In host mode, all router
advertisement and router redirect messages are disallowed on the port. The RA
guard feature compares configuration information on the Layer 2 device with the
information found in the received RA frame. Once the Layer 2 device has
validated the content of the RA frame and router redirect frame against the
configuration, it forwards the RA to its unicast or multicast destination. If
the RA frame content is not validated, the RA is dropped.
For detailed information
about IPv6 Router Advertisement Guard, see the “IPv6 Router Advertisement
Guard" chapter of the Cisco IOS IPv6 Configuration Guide Library on
Cisco.com.
-
IPv6 Device
Tracking—The IPv6 device tracking feature provides IPv6 host liveness tracking
so that a neighbor table can be updated when an IPv6 host disappears. The
feature tracks the liveness of the neighbors connected through the Layer 2
switch on regular basis in order to revoke network access privileges as they
become inactive.
For detailed
information about IPv6 Device Tracking, see the “IPv6 Device Tracking"
chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.
-
IPv6 DHCP
Guard—The IPv6 DHCP Guard feature blocks reply and advertisement messages that
come from unauthorized DHCPv6 servers and relay agents. IPv6 DHCP guard can
prevent forged messages from being entered in the binding table and block
DHCPv6 server messages when they are received on ports that are not explicitly
configured as facing a DHCPv6 server or DHCP relay. To use this feature,
configure a policy and attach it to an interface or a VLAN. To debug DHCP guard
packets, use the
debug ipv6
snooping dhcp-guard privileged EXEC command.
-
IPv6 Port-Based
Access List Support—The IPv6 port-based access list (PACL) feature provides the
ability to provide access control (permit or deny) on Layer 2 switch ports for
IPv6 traffic. IPv6 PACLs are similar to IPv4 PACLs, which provide access
control on Layer 2 switch ports for IPv4 traffic.
With Catalyst
3750-E, 3750X, 3560E, 3560-X, 3750v2, and 3560 v2 switches, this feature is
supported in hardware and only in ingress direction. In a mixed stack scenario
where the stack has a switch that does not support IPv6 FHS, the VLAN target is
disabled on the whole switch for security. Port targets are allowed on the IPv6
FHS-capable ports of the switch. If a non-supporting switch becomes the stack
master, the IPv6 FHS functions are still supported on the IPv6 FHS-capable
ports of the switch.
Access lists
determine which traffic is blocked and which traffic is forwarded at switch
interfaces and allow filtering based on source and destination addresses,
inbound and outbound, to a specific interface. Each access list has an implicit
deny statement at the end. To configure an IPv6 PACL, you have to create an
IPv6 access list and then configure the PACL mode on the specified IPv6 Layer 2
interface.
PACL can filter
ingress traffic on Layer 2 interfaces based on Layer 3 and Layer 4 header
information or non-IP Layer 2 information.
-
IPv6 Source
Guard—Like IPv4 Source Guard, IPv6 Source Guard validates the source address or
prefix to prevent source address spoofing.
A source guard
programs the hardware to allow or deny traffic based on source or destination
addresses. It deals exclusively with data packet traffic.
The IPv6 source guard
feature provides the ability to use the IPv6 binding table to install PACLs to
prevent a host from sending packets with an invalid IPv6 source address.
To debug
source-guard packets, use the debug ipv6 snooping source-guard privileged EXEC
command.
Note |
The IPv6 PACL
feature is supported only in the ingress direction; it is not supported in the
egress direction.
|
The following
restrictions apply:
-
An FHS
policy cannot be attached to an physical port when it is a member of an
EtherChannel group.
-
When IPv6
source guard is enabled on a switch port, NDP or DHCP snooping must be enabled
on the interface to which the switch port belongs. Otherwise, all data traffic
from this port will be blocked.
-
An IPv6
source guard policy cannot be attached to a VLAN. It is supported only at the
interface level.
-
You cannot
use IPv6 Source Guard and Prefix Guard together. When you attach the policy to
an interface, it should be "validate address" or "validate prefix" but not
both.
-
PVLAN and
Source/Prefix Guard cannot be applied together.
For more
information on IPv6 Source Guard, see the
IPv6 Source Guard
chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.
-
IPv6 Prefix
Guard—The IPv6 prefix guard feature works within the IPv6 source guard feature,
to enable the device to deny traffic originated from non-topologically correct
addresses. IPv6 prefix guard is often used when IPv6 prefixes are delegated to
devices (for example, home gateways) using DHCP prefix delegation. The feature
discovers ranges of addresses assigned to the link and blocks any traffic
sourced with an address outside this range.
For more
information on IPv6 Prefix Guard, see the
IPv6 Prefix Guard
chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.
-
IPv6 Destination
Guard—The IPv6 destination guard feature works with IPv6 neighbor discovery to
ensure that the device performs address resolution only for those addresses
that are known to be active on the link. It relies on the address glean
functionality to populate all destinations active on the link into the binding
table and then blocks resolutions before they happen when the destination is
not found in the binding table.
Note |
IPv6
Destination Guard is recommended only on Layer 3. It is not recommended on
Layer2.
|
For more
information about IPv6 Destination Guard, see the IPv6 Destination Guard
chapter of the Cisco IOS IPv6 Configuration Guide Library on Cisco.com.
-
IPv6 Neighbor
Discovery Multicast Suppress—The IPv6 Neighbor Discovery multicast suppress
feature is an IPv6 snooping feature that runs on a switch or a wireless
controller and is used to reduce the amount of control traffic necessary for
proper link operations.
-
DHCPv6
Relay—Lightweight DHCPv6 Relay Agent—The DHCPv6 Relay—Lightweight DHCPv6 Relay
Agent feature allows relay agent information to be inserted by an access node
that performs a link-layer bridging (non-routing) function. Lightweight DHCPv6
Relay Agent (LDRA) functionality can be implemented in existing access nodes,
such as DSL access multiplexers (DSLAMs) and Ethernet switches, that do not
support IPv6 control or routing functions. LDRA is used to insert relay-agent
options in DHCP version 6 (DHCPv6) message exchanges primarily to identify
client-facing interfaces. LDRA functionality can be enabled on an interface and
on a VLAN.
For more
information about DHCPv6 Relay, See the
DHCPv6 Relay—Lightweight
DHCPv6 Relay Agent section of the IP Addressing: DHCP Configuration
Guide, Cisco IOS Release 15.1SG.