This document provides information about configuring features that comprise first hop security functionality in IPv6.
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, per-port address limit, IPv6 device tracking) to validate the link-layer address (LLA), the IPv4 or IPv6 address, and prefix binding of the neighbors to prevent spoofing and redirect attacks.
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.
Router advertisements (RAs) are used by routers to announce themselves on the link. IPv6 RA Guard analyzes these RAs and can filter out bogus ones sent by unauthorized routers.
The per-port address limit feature enables an operator to specify a maximum number of IPv6 addresses allowed on a port of the switch. This function is achieved by filtering out ND messages sourced with addresses beyond the per-port address limit.
IPv6 Device Tracking provides IPv6 host liveness tracking so that a neighbor table can be immediately updated when an IPv6 host disappears.
The Secure Neighbor Discovery for Cisco IOS Software feature is designed to counter the threats of the ND protocol. Secure neighbor discovery (SeND) defines a set of neighbor discovery options and two neighbor discovery messages. SeND also defines a new autoconfiguration mechanism to establish address ownership. The IPv6 PACL feature adds IPv6 port-based ACL support.
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see
Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Implementing First Hop Security in IPv6
You should be familiar with the IPv6 neighbor discovery feature. For information about IPv6 neighbor discovery, see "Implementing IPv6 Addressing and Basic Connectivity".
The SeND feature is available on crypto images because it involves using cryptographic libraries.
In order to use IPv6 port-based access list (PACL), you must know how to configure IPv6 access lists. For information about configuring IPv6 access lists, see "Implementing Traffic Filters and Firewalls for IPv6 Security".
Restrictions for Implementing First Hop Security in IPv6
The IPv6 PACL feature is supported only in the ingress direction; it is not supported in the egress direction.
RA Guard in Cisco IOS Release 12.2(33)SXI4
The RA guard feature does not offer protection in environments where IPv6 traffic is tunneled.
This feature is supported only in hardware by programming the TCAM.
This feature can be configured only on a switchport interface in the ingress direction.
This feature supports only host mode.
This feature is supported only in the ingress direction; it is not supported in the egress direction.
This feature is supported on ether channel, but not on ether channel port members.
This feature is not supported on trunk ports with merge mode.
This feature is supported on auxiliary VLANs and PVLANs. In case of PVLANs, primary VLAN features are inherited and merged with port features.
Packets dropped by the RA guard feature can be spanned.
If the platformipv6aclicmpoptimizeneighbor-discovery command is configured, RA guard feature configuration should not be allowed and an error message should be displayed. This command adds default global ICMP entries that will override the RA guard ICMP entries.
Information About Implementing First Hop Security in IPv6
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 to validate the link-layer address (LLA), the IPv4 or IPv6 address, and prefix binding of the neighbors to prevent spoofing and redirect attacks.
IPv6 Device Tracking
The IPv6 device tracking feature provides IPv6 host liveness tracking so that a neighbor table can be immediately updated when an IPv6 host disappears. The feature tracks of 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.
IPv6 Port-Based Access List Support
The IPv6 PACL feature provides the ability to provide access control (permit or deny) on L2 switch ports for IPv6 traffic. IPv6 PACLs are similar to IPv4 PACLs, which provide access control on L2 switch ports for IPV4 traffic. They are supported only in ingress direction and in hardware.
PACL can filter ingress traffic on L2 interfaces based on L3 and L4 header information or non-IP L2 information.
IPv6 Global Policies
IPv6 global policies provide policy database services to features with regard to storing and accessing those policies. IPv6 ND inspection and IPv6 RA guard are IPv6 global policies features. Every time an ND inspection or RA guard is configured globally, the attributes of the policy are stored in the software policy database. The policy is then applied to an interface, and the software policy database entry is updated to include this interface to which the policy is applied.
IPv6 RA guard provides support for allowing 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 these 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 L2 device with the information found in the received RA frame. Once the L2 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.
IPv6 ND 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. SA neighbor discovery message is considered trustworthy if its IPv6-to-Media Access Control (MAC) mapping is verifiable.
This feature mitigates some of the inherent vulnerabilities for the neighbor discovery mechanism, such as attacks on duplicate address detection (DAD), address resolution, router discovery, and the neighbor cache.
There are three IPv6 neighbor discovery trust models, which are described as follows:
All authenticated nodes trust each other to behave correctly at the IP layer and not to send any neighbor discovery or router discovery (RD) messages that contain false information. This model represents a situation where the nodes are under a single administration and form a closed or semiclosed group. A corporate intranet is an example of this model.
A router trusted by the other nodes in the network to be a legitimate router that routes packets between the local network and any connected external networks. This router is trusted to behave correctly at the IP layer and not to send any neighbor discovery or RD messages that contain false information. This model represents a public network run by an operator. The clients pay the operator, have the operator's credentials, and trust the operator to provide the IP forwarding service. The clients do not trust each other to behave correctly; any other client node must be considered able to send falsified neighbor discovery and RD messages.
A model where the nodes do not directly trust each other at the IP layer. This model is considered suitable where a trusted network operator is not available.
Nodes on the same link use ND to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. ND is used by both hosts and routers. The original ND specifications used IPsec to protect ND messages. However, not many detailed instructions for using IPsec are available. The number of manually configured security associations needed for protecting ND can be very large, which makes that approach impractical for most purposes. These threats need to be considered and eliminated.
SeND Protocol
The SeND protocol counters ND threats. It defines a set of new ND options, and two new ND messages (Certification Path Solicitation [CPS] and Certification Path Answer [CPA]). It also defines a new autoconfiguration mechanism to be used in conjunction with the new ND options to establish address ownership.
SeND defines the mechanisms defined in the following sections for securing ND:
Cryptographically generated addresses (CGAs) are IPv6 addresses generated from the cryptographic hash of a public key and auxiliary parameters. This provides a method for securely associating a cryptographic public key with an IPv6 address in the SeND protocol.
The node generating a CGA address must first obtain a Rivest, Shamir, and Adelman (RSA) key pair (SeND uses an RSA public/private key pair). The node then computes the interface identifier part (which is the rightmost 64 bits) and appends the result to the prefix to form the CGA address.
CGA address generation is a one-time event. A valid CGA cannot be spoofed and the CGA parameters received associated to it is reused because the message must be signed with the private key that matches the public key used for CGA generation, which only the address owner will have.
A user cannot replay the complete SeND message (including the CGA address, CGA parameters, and CGA signature) because the signature has only a limited lifetime.
Authorization Delegation Discovery
Authorization delegation discovery is used to certify the authority of routers by using a trust anchor. A trust anchor is a third party that the host trusts and to which the router has a certification path. At a basic level, the router is certified by the trust anchor. In a more complex environment, the router is certified by a user that is certified by the trust anchor. In addition to certifying the router identity (or the right for a node to act as a router), the certification path contains information about prefixes that a router is allowed to advertise in router advertisements. Authorization delegation discovery enables a node to adopt a router as its default router.
Deployment for SeND between hosts is straightforward. The hosts can generate a pair of RSA keys locally, autoconfigure their CGA addresses, and use them to validate their sender authority, rather than using a trust anchor to establish sender authority. The figure below illustrates this model.
Figure 1
Host-to-Host Deployment Model
Neighbor Solicitation Flow
In a neighbor solicitation scenario, hosts and routers in host mode exchange neighbor solicitations and neighbor advertisements. These neighbor solicitations and neighbor advertisements are secured with CGA addresses and CGA options, and have nonce, time stamp, and RSA neighbor discovery options. The figure below illustrates this scenario.
Figure 2
Neighbor Solicitation Flow
Host-Router Deployment Model
In many cases, hosts will not have access to the infrastructure that will enable them to obtain and announce their certificates. In these situations, hosts will secure their relationship using CGA, and secure their relationship with routers using a trusted anchor. When using RAs, SeND mandates that routers are authenticated through a trust anchor. The figure below illustrates this scenario.
Figure 3
Host-Router Deployment Model
Router Advertisement and Certificate Path Flows
The figure below shows the certificate exchange performed using certification path solicitation CPS/CPA SeND messages. In the illustration, Router R is certified (using an X.509 certificate) by its own CA (certificates CR). The CA itself (CA2) is certified by its own CA (certificates C2), and so on, up to a CA (CA0) that the hosts trusts. The certificate CR contains IP extensions per RFC 3779, which describes which prefix ranges the router R is allowed to announce (in RAs). This prefix range, certified by CA2, is a subset of CA2's own range, certified by CA1, and so on. Part of the validation process when a certification chain is received consists of validating the certification chain and the consistency of nested prefix ranges.
Figure 4
Router Advertisement and Certificate Path Flows
Single CA Model
The deployment model shown in the third figure above can be simplified in an environment where both hosts and routers trust a single CA such as the Cisco certification server (CS). The figure below illustrates this model.
Perform this task to provide fine grain control over the life cycle of an entry in the binding table for the IPv6 device tracking feature. This feature is available in Cisco IOS Release 12.2(50)SY. In order for IPv6 device tracking to work, the binding table needs to be populated (see the Configuring the IPv6 Binding Table Content).
Enables debugging for snooping information in the IPv6 RA guard feature
Configuring SeND for IPv6
Certificate servers are used to grant certificates after validating or certifying key pairs. A tool for granting certificates is mandatory in any SeND deployment. Many tools are available to grant certificates, for example, Open Secure Sockets Layer (OpenSSL) on Linux. However, very few certificate servers support granting certificates containing IP extensions. Cisco IOS certificate servers support every kind of certificate including the certificates containing the IP extensions.
SeND is available in host mode. The set of available functions on a host will be a subset of SeND functionality. CGA will be fully available and the prefix authorization delegation will be supported on the host side (sending CPS and receiving CPA).
To implement SeND, configure the host with the following parameters:
An RSA key pair used to generate CGA addresses on the interface.
A SeND modifier that is computed using the RSA key pair.
A key on the SeND interface.
CGAs on the SeND interface.
A Public Key Infrastructure (PKI) trustpoint, with minimum content; for example, the URL of the certificate server. A trust anchor certificate must be provisioned on the host.
SeND is also available in router mode. You can use the ipv6unicast-routing command to configure a node to a router. To implement SeND, configure routers with the same elements as that of the host. The routers will need to retrieve certificates of their own from a certificate server. The RSA key and subject name of the trustpoint are used to retrieve certificates from a certificate server. Once the certificate has been obtained and uploaded, the router generates a certificate request to the certificate server and installs the certificate.
The following operations need to be completed before SeND is configured on the host or router:
Hosts are configured with one or more trust anchors.
Hosts are configured with an RSA key pair or configured with the capability to locally generate it. Note that for hosts not establishing their own authority via a trust anchor, these keys are not certified by any CA.
Routers are configured with RSA keys and corresponding certificate chains, or the capability to obtain these certificate chains that match the host trust anchor at some level of the chain.
While booting, hosts and routers must either retrieve or generate their CGAs. Typically, routers will autoconfigure their CGAs once and save them (along with the key pair used in the CGA operation) into their permanent storage. At a minimum, link-local addresses on a SeND interface should be CGAs. Additionally, global addresses can be CGAs.
Hosts and routers must be configured with RSA key pairs and corresponding certificate chains before the SeND parameters are configured. Perform the following task to configure the certificate server to grant certificates. Once the certificate server is configured, other parameters for the certificate server can be configured.
(Optional) Specifies that the IP extensions are included in a certificate request either for enrollment or generation of a certificate authority (CA) for the Cisco IOS CA.
Step 6
revocation-check {[crl] [none] [ocsp]}
Example:
Router(ca-trustpoint)# revocation-check crl
(Optional) Sets one or more methods for revocation checking.
Step 7
exit
Example:
Router(ca-trustpoint)# exit
Returns to global configuration mode.
Step 8
cryptopkiservername
Example:
Router(config)# crypto pki server CA
Configures the PKI server and places the router in server configuration mode.
Step 9
grantauto
Example:
Router(config-server)# grant auto
(Optional) Grants all certificate requests automatically.
(Optional) Sets the URL name if the host is using a Certificate Revocation List (CRL).
Step 11
noshutdown
Example:
Router(config-server)# no shutdown
Enables the certificate server.
Configuring a Host to Enable SeND
SeND is available in host mode. Before you can configure SeND parameters in host mode, first configure the host using the following commands. Once the host has been configured, SeND parameters can be configured on it.
In the example, secure mode is configured on SeND.
Configuring a Router to Enable SeND
SeND is available in the router mode. Perform this task before you can configure SeND parameters in router mode. Once the router has been configured, the SeND parameters can be configured on it.
Generates the CGA modifier for a specified RSA key, which enables the key to be used by SeND.
Configuring Certificate Enrollment for a PKI
Certificate enrollment, which is the process of obtaining a certificate from a CA, occurs between the end host that requests the certificate and the CA. Each peer that participates in the PKI must enroll with a CA. In IPv6, you can autoenroll or manually enroll the device certificate.
In router mode, the key pair used to generate the CGA addresses on an interface must be certified by the CA and the certificate sent on demand over the SeND protocol. One RSA key pair and associated certificate is enough for SeND to operate; however, users may use several keys, identified by different labels. SeND and CGA refer to a key directly by label or indirectly by trustpoint.
Multiple steps are required to bind SeND to a trustpoint. First, a key pair is generated. Then the device refers to it in a trustpoint, and next the SeND interface configuration points to the trustpoint. There are two reasons for the multiple steps:
The same key pair can be used on several SeND interfaces
The trustpoint contains additional information, such as the certificate, required for SeND to perform authorization delegation
A CA certificate must be uploaded for the referred trustpoint. The referred trustpoint is in reality a trusted anchor.
Several trustpoints can be configured, pointing to the same RSA keys, on a given interface. This function is useful if different hosts have different trusted anchors (that is, CAs that they trust). The router can the provide each host with the certificate signed by the CA they trust.
Enables SeND on an interface and specifies which trustpoint should be used.
Configuring SeND Trust Anchors on the Interface
This task can be performed only in host mode. The host must be configured with one or more trust anchors. As soon as SeND is bound to a trustpoint on an interface (see Configuring the SeND Trustpoint), this trustpoint is also a trust anchor.
A trust anchor configuration consists of the following items:
A public key signature algorithm and associated public key, which may include parameters
A name
An optional public key identifier
An optional list of address ranges for which the trust anchor is authorized
Because PKI has already been configured, the trust anchor configuration is accomplished by binding SeND to one or several PKI trustpoints. PKI is used to upload the corresponding certificates, which contain the required parameters (such as name and key).
Perform this optional task to configure a trusted anchor on the interface. It allows you to select trust anchors listed in the CPS when requesting for a certificate. If you opt not to configure trust anchors, all the PKI trustpoints configured on the host will be considered.
SUMMARY STEPS
1.enable
2.configureterminal
3.cryptopkitrustpointname
4.enrollmentterminal [pem
5.exit
6.cryptopkiauthenticatename
7.interfacetypenumber
8.ipv6ndsecuredtrustanchortrustanchor-name
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
cryptopkitrustpointname
Example:
Router(config)# crypto pki trustpoint anchor1
Declares the trustpoint that your router should use and enters ca-trustpoint configuration mode.
Specifies a trusted anchor on an interface and binds SeND to a trustpoint.
Configuring Secured and Nonsecured Neighbor Discovery Message Coexistence Mode
During the transition to SeND secured interfaces, network operators may want to run a particular interface with a mixture of nodes accepting secured and unsecured neighbor discovery messages. Perform this task to configure the coexistence mode for secure and nonsecure ND messages on the same interface.
SUMMARY STEPS
1.enable
2.configureterminal
3.interfacetypenumber
4.ipv6ndsecuredtrustpointtrustpoint-name
5.noipv6ndsecuredfull-secure
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Router(config)# interface Ethernet 0/0
Specifies an interface type and number, and places the router in interface configuration mode.
The first task in configuring IPv6 PACL is to create an IPv6 access list. This task is described in detail in Implementing Traffic Filters and Firewalls for IPv6 Security.
Configuring PACL Mode and Applying IPv6 PACL on an Interface
Once you have configured the IPv6 access list you want to use, you must configure the PACL mode on the specified IPv6 L2 interface.
SUMMARY STEPS
1.enable
2.configureterminal
3.interfacetypenumber
4.access-groupmode {prefer {port | vlan}
| merge}
5.ipv6traffic-filteraccess-list-name {in | out
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Router(config)# interface fastethernet 0/0
Specifies an interface type and number, and places the router in interface configuration mode.
Step 4
access-groupmode {prefer {port | vlan}
| merge}
Example:
Router(config-if)# access-group mode prefer port
Sets the mode for the specified layer 2 interface.
The no form of this command sets the mode to the default value, which is merge.
The prefervlan keyword combination is not supported in IPv6.
Step 5
ipv6traffic-filteraccess-list-name {in | out
Example:
Router(config-if)# ipv6 traffic-filter list1 in
Filters incoming IPv6 traffic on an interface.
Note
The out keyword and therefore filtering of outgoing traffic is not supported in IPv6 PACL configuration.
Configuration Examples for Implementing First Hop Security in IPv6
Example IPv6 ND Inspection and RA Guard Configuration
This example provides information about the Ethernet 0/0 interface, on which the ND inspection and RA Guard features are configured:
Router# show ipv6 snooping capture interface ethernet 0/0
Hardware policy registered on Et0/0
Protocol Protocol value Message Value Action Feature
ICMP 58 RS 85 punt RA Guard
punt ND Inspection
ICMP 58 RA 86 drop RA guard
punt ND Inspection
ICMP 58 NS 87 punt ND Inspection
ICM 58 NA 88 punt ND Inspection
ICMP 58 REDIR 89 drop RA Guard
punt ND Inspection
Example RA Guard Configuration
This section provides a configuration example for the RA guard feature:
Router(config)# interface fastethernet 3/13
Router(config-if)# ipv6 nd raguard
Router# show run interface fastethernet 3/13
Building configuration...
Current configuration : 129 bytes
!
interface FastEthernet3/13
switchport
switchport access vlan 222
switchport mode access
access-group mode prefer port
ipv6 nd raguard
end
Example Configuring PACL Mode and Applying IPv6 PACL on an Interface
Once you have configured the IPv6 access list you want to use, you can configure the PACL mode on a specified IPv6 switchport. This section uses an access list named list1, provides an example of how to configure PACL mode, and applies IPv6 PACL to a GigabitEthernet interface.
Router(config)# interface gigabitethernet 3/24
Router(config-if)# access-group mode prefer port
Router(config-if)# ipv6 traffic-filter list1 in
The following example shows how to configure the router to enable SeND:
enable
configure terminal
crypto key generate rsa label SEND modulus 1024
ipv6 cga modifier rsakeypair SEND sec-level 1
crypto pki trustpoint SEND
subject-name C=FR, ST=PACA, L=Example, O=Cisco, OU=NSSTG, CN=router
rsakeypair SEND
revocation-check none
exit
crypto pki authenticate SEND
Certificate has the following attributes:
Fingerprint MD5: FC99580D 0A280EB4 2EB9E72B 941E9BDA
Fingerprint SHA1: 22B10EF0 9A519177 145EA4F6 73667837 3A154C53
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
crypto pki enroll SEND
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will include: C=FR, ST=fr, L=example, O=cisco, OU=nsstg, CN=route r % The subject name in the certificate will include: Router % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]:
Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate
Authority % The 'show crypto pki certificate SEND verbose' commandwill show the fingerprint.
*Feb 5 09:40:37.171: CRYPTO_PKI: Certificate Request Fingerprint MD5:
A6892F9F 23561949 4CE96BB8 CBC85 E64
*Feb 5 09:40:37.175: CRYPTO_PKI: Certificate Request Fingerprint SHA1:
30832A66 E6EB37DF E578911D 383F 96A0 B30152E7
*Feb 5 09:40:39.843: %PKI-6-CERTRET: Certificate received from Certificate Authority
interface fastethernet 0/0
ipv6 nd secured sec-level minimum 1
ipv6 cga rsakeypair SEND
ipv6 address fe80::link-local cga
ipv6 nd secured trustanchor SEND
ipv6 nd secured timestamp delta 300
exit
ipv6 nd secured full-secure
To verify that the certificates are generated, use the showcryptopkicertificates command:
Router# show crypto pki certificates
Certificate
Status: Available
Certificate Serial Number: 0x15
Certificate Usage: General Purpose
Issuer:
cn=CA
Subject:
Name: Router
hostname=Router
c=FR
st=fr
l=example
o=cisco
ou=nsstg
cn=router
Validity Date:
start date: 09:40:38 UTC Feb 5 2009
end date: 09:40:38 UTC Feb 5 2010
Associated Trustpoints: SEND
CA Certificate
Status: Available
Certificate Serial Number: 0x1
Certificate Usage: Signature
Issuer:
cn=CA
Subject:
cn=CA
Validity Date:
start date: 10:54:53 UTC Jun 20 2008
end date: 10:54:53 UTC Jun 20 2011
Associated Trustpoints: SEND
To verify the configuration, use the showrunning-config command:
Example Configuring a SeND Trustpoint in Router Mode
The following example shows how to configure a SeND trustpoint in router mode:
enable
configure terminal
crypto key generate rsa label SEND
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]: 778
% Generating 778 bit RSA keys, keys will be non-exportable...[OK]
ipv6 cga modifier rsakeypair SEND sec-level 1
crypto pki trustpoint trstpt1
subject-name C=FR, ST=fr, L=example, O=cisco, OU=nsstg, CN=sa14-72b
rsakeypair SEND
enrollment terminal
ip-extension unicast prefix 2001:100:1://48
exit
crypto pki authenticate trstpt1
crypto pki enroll trstpt1
crypto pki import trstpt1 certificate
interface Ethernet 0/0
ipv6 nd secured trustpoint trstpt1
Example Configuring SeND Trust Anchors in the Host Mode
The following example shows how to configure SeND trust anchors on an interface in the host mode:
enable
configure terminal
! Configure the location of the CS we trust !
crypto pki trustpoint B1
enrollment terminal
crypto pki authenticate anchor1
exit
! Only Query a certificate signed by the CS at B2 on this interface !
interface Ethernet0/0
ip address 204.209.1.54 255.255.255.0
ipv6 cga rsakeypair SEND
ipv6 address 2001:100::/64 cga
ipv6 nd secured trustanchor anchor1
Example Configuring CGA Address Generation on an Interface
The following example shows how to configure CGA address generation on an interface:
IPv6 Neighbor Discovery (ND) Trust Models and Threats
RFC 3779
X.509 Extensions for IP Addresses and AS Identifiers
RFC 3971
Secure Neighbor Discovery (SeND)
RFC 3972
Cryptographically Generated Addresses (CGA)
RFC 6105
IPv6 Router Advertisement Guard
Technical Assistance
Description
Link
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
http://www.cisco.com/cisco/web/support/index.html
Feature Information for Implementing First Hop Security in IPv6
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1
Feature Information for Implementing First Hop Security in IPv6
Feature Name
Releases
Feature Information
IPv6 Device Tracking
12.2(50)SY
This feature allows IPv6 host liveness to be tracked so the neighbor binding table can be immediately updated when an IPv6 host disappears.
The following commands were introduced or modified:
ipv6neighborbinding,
ipv6neighborbindingdown-lifetime,
ipv6neighborbindinglogging,
ipv6neighborbindingmax-entries,
ipv6neighborbindingstale-lifetime,ipv6neighborbindingvlan,
ipv6neighbortracking,
showipv6neighborbinding.
IPv6 ND Inspection
12.2(50)SY
The IPv6 ND Inspection feature learns and secures bindings for stateless autoconfiguration addresses in layer 2 neighbor tables.
The following commands were introduced: clear ipv6 snooping counters, debug ipv6 snooping,
device-role,
drop-unsecure,
ipv6ndinspection,
ipv6ndinspectionpolicy,
sec-levelminimum,
showipv6snoopingcapture-policy, showipv6snoopingcounters,showipv6snoopingfeatures,
showipv6snoopingpolicies,trackingtrusted-port.
IPv6 PACL
12.2(54)SG 12.2(33)SXI4 12.2(50)SY
The IPv6 PACL permits or denies the movement of traffic between Layer 3 (L3) subnets and VLANs, or within a VLAN.
The following commands were introduced or modified: access-group mode, ipv6 traffic-filter.
IPv6 RA Guard
12.2(54)SG 12.2(33)SXI4 12.2(50)SY
IPv6 RA guard provides support for allowing the network administrator to block or reject unwanted or rogue RA guard messages that arrive at the network switch platform.
Secure Neighbor Discovery for Cisco IOS Software
12.4(24)T
The Secure Neighbor Discovery (SeND) protocol is designed to counter the threats of the ND protocol. SeND defines a set of neighbor discovery options and two neighbor discovery messages. SeND also defines a new autoconfiguration mechanism to establish address ownership.
CPS--certification path solicitation. The solicitation message used in the addressing process.
CRL--certificate revocation list.
CS--certification server.
CSR--certificate signing request.
DAD--duplicate address detection. A mechanism that ensures two IPv6 nodes on the same link are not using the same address.
DER--distinguished encoding rules. An encoding scheme for data values.
LLA--link-layer address.
MAC--media access control.
nonce--An unpredictable random or pseudorandom number generated by a node and used once. In SeND, nonces are used to assure that a particular advertisement is linked to the solicitation that triggered it.
non-SeNDnode--An IPv6 node that does not implement SeND but uses only the neighbor discovery protocol without security.
NUD--neighbor unreachability detection. A mechanism used for tracking neighbor reachability.
PACL--port-based access list.
PKI--public key infrastructure.
RA--router advertisement.
RouterAuthorizationCertificate--A public key certificate.
RD--Router discovery allows the hosts to discover what routers exist on the link and what subnet prefixes are available. Router discovery is a part of the neighbor discovery protocol.
SeNDnode--An IPv6 node that implements SeND.
trustanchor--A trust anchor is an entity that the host trusts to authorize routers to act as routers. Hosts are configured with a set of trust anchors to protect router discovery.
ULA--unique local addressing.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.