Tools Available for Securing IPv6 Networks

The threat analysis leads to the conclusion that more similarities than differences exist between IPv4 and IPv6 as far as security is concerned. Until end-to-end IPsec and a reliable key-distribution protocol is consistently deployed for IPv6, the proven IPv4 security best practices and tools should be used to secure the IPv6 networks, too. It is thus important to evaluate the IPv6 readiness of these tools. Although perimeter security is critical, security policies and tools are implemented and used in multiple parts of the network.

IPsec for IPv6

IPsec is the networking community's answer to the need for secured communication. It was defined in RFC 2401, and conceptually it operates under the same principles in IPv4 and in IPv6.

IPsec Concepts

The implementation of IPsec has two elements:

• Authentication Header (AH) is defined in RFC 2402, and it provides source authentication, connectionless integrity, and protection against replay. In IPv6, it is implemented through an AH extension header.

• Encapsulating Security Payload (ESP) is defined in RFC 2406, and it provides confidentiality, source authentication, connectionless integrity, and replay protection. In IPv6, it is implemented through an ESP extension header.

You can use AH by itself (if regulations do not allow traffic to be encrypted and the use of an ESP).

There are two modes of securing the traffic between two hosts:

• Transport mode In transport mode, IPsec is used end to end between the hosts. In this case, only the payload of the packet is secured. This is the model promoted by IPv6.

• Tunnel mode In tunnel mode, the packets from a host are transported over a trusted network to a security gateway. They are then encapsulated in another packet and securely transported to the destination or to another security gateway that places them on another trusted network for the destination. In this case, the entire original packet, payload, and header are secured. This model is commonly used in IPv4 networks today.

In both cases, the process of securing the communication is started by establishing a security association (SA), which is a unidirectional logical connection that encompasses all the participating elements. These elements include the authentication algorithm, authentication key, encryption algorithm, encryption key, and so on. These parameters are negotiated between the two participants in the SA. In transport mode, a host clearly has to establish multiple SAs. It can differentiate between them by using a Security Parameters Index (SPI). These two IDs, the SA and the SPI, are referenced in every IPsec-protected packet.

In IPv6, two EHs were defined to support IPsec. Figure 9-3 shows their format.

Figure 9-3. Authentication and Encapsulating Security Payload EHs

[View full size image]

The sequence number is a variable that is initialized to zero when the SA is set up. It ticks up with every packet sent, and that helps keep track of out-of-sequence packets and of played-back packets.

Using IPv4 IPsec to Secure IPv6 Tunnels

IPsec is frequently deployed in today's IPv4 networks to secure communication over VPNs. It is used for access VPNs as well as inter-site VPNs. IPv6 transition mechanisms can leverage such an infrastructure to achieve a certain level of security, even in the absence of IPv6 IPsec.

Remote IPv4 hosts access private networks by establishing an encrypted access VPN to a gateway set up for these purposes. If the same host is enabled for IPv6, it can thread an IPv6 tunnel through this IPv4-secured communication channel. Because the IPv4 VPN places the remote host on the private network, a natural IPv6 tunnel choice is the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), which is suitable for intra-site communication. In practice, however, you can use any type of IPv6 tunnel as long as it is supported by the host and a gateway is set up for it inside the private network.

The configurations for the IPv4 access VPN and the IPv6 tunnel are completely independent. The IPv4 VPN configuration is beyond the scope of this book, but there are plenty of examples in references dedicated to this topic (refer, for example, to IPSec VPN Design by Vijay Bollapragada, et al.). Chapter 3, "Delivering IPv6 Unicast Services," contains router configuration examples for the various IPv6 tunnel types. From a host perspective, the tunnel configuration depends on the particular operating system used. For example, if ISATAP is used in the topology shown in Figure 3-11 (Chapter 3) and the host is running Windows XP, the host tunnel configuration would be just one line entered in the command window:

netsh interface ipv6 isatap set router 200.13.13.1

In this example, the IPv4 VPN initiated by the host is terminated at the edge of the private network not identified in Figure 3-11.

The "Topologies Examples" section of Chapter 7 shows an example of how to secure the IPv6 traffic between two routers by setting up an IPv6 tunnel through an inter-site IPv4 IPsec VPN. Although the example discusses the case of a manually configured tunnel, the same concept applies to any IPv6 tunnel type, static or dynamic. The example uses a static crypto map, which implies the fact that the routers have fixed IPv4 addresses and are using shared keys. You can implement dynamic maps when the routers acquire their IPv4 addresses dynamically, as in the case of remote sites provisioned every time they connect to the network.

Securing Routerto-Router Communication with IPv6 IPsec

Until IPv6 IPsec is extensively and uniformly deployed as suggested by RFC 2460, it can still be used on a smaller scale. IPv6 IPsec can be leveraged to secure both the control and the data plane between two routers. The "OSPFv3" section of Chapter 4, "IPv6 Routing Protocols," shows an example of using IPsec (with static key) to secure a routing protocol. Cisco IOS software also offers a mechanism for securing the data traffic between two routers through a new type of tunnel that employs IPv6 IPsec. IKEv1 is used for key management. Figure 9-4 shows a topology in which this feature is used between Routers A and B.

Figure 9-4. Using IPv6 IPsec to Secure the Data Exchange Between Two Routers

[View full size image]

Except for the tunnel itself, the configuration of this feature is similar to that used in securing the communication between two routers with IPv4 IPsec. On Router A, the steps to configure the IPsec portion are as follows:

• Create the ISAKMP policy. Pre-shared keys are used in this example:

  crypto isakmp policy 1
    authentication pre-share

• Define the pre-shared key and the address of the peer:

  crypto isakmp key myPreshareKey0 address ipv6 2001:B:1::1/128

• Configure the IPsec transform set that will be offered during negotiation to support ESP/3DES and the integrity algorithm:

  crypto ipsec transform-set 3des ah-sha-hmac esp-3des

• Define the IPsec parameters that are to be used for IPsec encryption between the two IPsec routers:

  crypto ipsec profile ExampleIPsec
    set transform-set 3des

Figure 9-4 shows the tunnel interface configuration for each router.

The operation of this feature is similar to the IPv4 one, so the same troubleshooting commands and methods apply in the case of IPv6 IPsec (refer to IPSec VPN Design by V. Bollapragada, et al.). This is a useful tool to secure the inter-site communication.

Access Control Lists

Access control lists have proven themselves to be versatile instruments in identifying targeted traffic for further or particular processing or for filtering. For the most part, the IPv6 ACLs are similar to the IPv4 ACLs, but a few differences are worth pointing out:

• The packet header format offers several extra fields that should be recognized by the ACLs.

• New ICMP types are supported.

• The implicit rules of the ACLs need to account for the fact that the ND process relies on a layer 3 protocol (ICMPv6).

• The use of multiple addresses per interface has to be accounted for when designing the ACLs.

• IPv6's renumbering features can present challenges for ACLs when two different prefixes coexist on a given network segment.

• The existence of potentially multiple EHs makes the ACL matching against the first fragment nondeterministic.

The differences between the IPv4 and IPv6 ACLs stem from the IPv6 protocol specificities that have been discussed throughout this book.

Extended IPv6 ACLs and Stateful Filtering

Extended ACLs are supported for IPv6 in a similar way to IPv4. Numbered ACLs are not supported for IPv6. Additional parameters are available to deal with some of the IPv6 protocol and operational specifics listed earlier.

Example 9-1. Options Available in Cisco IOS Command Line When Configuring an IPv6 Access List

Router(config)#ipv6 access-list EXAMPLE Router(config-ipv6-acl)#permit host 2001:1::1 2001:2::/64 ? dscp Match packets with given dscp value flow-label Flow label fragments Check non-initial fragments log Log matches against this entry log-input Log matches against this entry, including input reflect Create reflexive access list entry routing Routing header sequence Sequence number for this entry time-range Specify a time-range

The implicit rules at the end of the IPv6 ACLs reflect the operational importance of ND. They permit the neighbor advertisement and neighbor solicitation ICMP traffic, as shown here:

permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any

Similar to IPv4, if the packet does not meet any of the matching criteria, it is dropped by default.

Stateful filtering is supported with IPv6 ACLs, too. The reflect option enables an ACL's permit statement to generate an access entry for the return packets of a flow it allowed through (refer to the book Implementing Cisco IPv6 Networks by Regis Desmeules). This dynamic access entry can be in turn applied to other ACLs with the use of the keyword evaluate, as shown in Example 9-2.

Example 9-2. Reflexive Access List Configuration Example

interface FastEthernet6/1.10 ipv6 address 2001:1::1/64 ipv6 traffic-filter IN in ipv6 traffic-filter OUT out ipv6 access-list IN permit tcp any eq www host 2001:2::1 reflect REF ipv6 access-list OUT evaluate REF

Based on the ACL called IN, any www TCP connection request that comes inbound interface FastEthernet6/1.10 for the server 2001:2::1 will be allowed through. For each connection, a dynamic permit entry is built under REF for the reply packet coming from the server. REF is included in the ACL called OUT, which will apply the return path dynamic entry outbound on the interface.

The reflexive ACL entries are active for a period of time (3 minutes by default) or until a FIN is detected for a TCP session.

Time-based ACLs can be created for IPv6 in the same fashion as for IPv4. They identify ACLs that are valid only for certain time intervals.

IPv6 ACLs and Fragmentation

When IP packets are fragmented, not all the fragments contain the information relevant to the ACL matching process. In IPv4, most of the layer 3 and layer 4 information is available in the first fragment, so the ACL can perform a full match on it. The noninitial fragments typically would not contain the layer 4 information, so at most a match can be done on the layer 3 header. Because a host cannot use the noninitial fragments if the first fragment was filtered, it is safe to apply an ACL statement that contains layer 4 criteria only on the first fragment. The keyword fragment in an IPv4 ACL indicates that after the layer 3 information is checked, all noninitial fragments are permitted or pushed through the subsequent ACL line depending on whether the statement is a permit or a deny (refer to the Cisco document "Access Control Lists and IP Fragments" at Cisco.com).

In IPv6, on the other hand, the router has to first parse through several Next headers before reaching the Fragmentation header to extract the information on the fragment. Then it must parse through some more EHs to get to the upper-layer information. Therefore, the first fragment might not contain all the necessary information. In IPv6 ACLs, the keyword fragment has the same meaning as in IPv4 with the exception that the filter applies to all noninitial fragments as well if the upper-layer protocol cannot be determined from the first fragment.

Firewalls can handle fragmented packets comprehensively. They can track all fragments by source address, destination address, protocol, and IP ID. This allows both the PIX and the Cisco IOS Firewall to apply the filtering policies to all fragments without any of the assumptions mentioned earlier.

IPv6 Access List Example

The concepts presented in this section of the chapter are captured in a practical example for the topology shown in Figure 9-5.

Figure 9-5. Topology for the Access List Example

[View full size image]

The edge router (ER) has to implement the following policies with the help of ACLs:

• Stop traffic with unique-local source addresses from leaving the internal network. It should log any attempts to do so to track misconfigured hosts.

• Block any outside traffic with the routing EH.

• Deny any outside traffic with undetermined transport.

• Allow only DNS traffic from 2001:B:1::/64 to reach the DNS server and for the DNS to reply to that traffic.

• Allow only WWW traffic from 2001:B:1::/64 to reach the web server daily between 8 a.m. and 5 p.m.

• Allow traffic necessary to support the PMTU Discovery process.

• Secure the Telnet access to the router.

• Permit all traffic sourced from inside of the network if it uses the global unicast address.

These conditions are met with the ACL and interface configuration shown in Example 9-3.

Example 9-3. Access List Configuration Implementing the Policies Listed Above

interface FastEthernet0/0 ipv6 address 2001:1:1::1/64 ipv6 traffic-filter EXAMPLE-IN in ipv6 traffic-filter EXAMPLE-OUT out ! interface FastEthernet0/1 ipv6 address 2001:A:1::1/64 ipv6 address FD01:A:1::1/64 ! ipv6 access-list EXAMPLE-IN deny ipv6 any any routing deny ipv6 any any undetermined-transport permit udp 2001:B:1::/64 host 2001:A:1::D eq domain reflect REF-D permit tcp 2001:B:1::/64 host 2001:A:1::F eq www time-range TimeExample reflect REF-T permit icmp any 2001:A:1::/64 packet-too-big ! ipv6 access-list EXAMPLE-OUT deny ipv6 FD00::/8 any log evaluate REF-D evaluate REF-T permit ipv6 2001:A:1::/64 any permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any ! ipv6 access-list VTY-protection permit tcp FD00::/8 any eq telnet permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any log ! time-range TimeExample periodic daily 8:00 to 17:00 ! line vty 0 4 ipv6 access-class VTY-protection in

The output of show ipv6 access-list summarizes the filtering policies configured on the router.

Firewall Functions

Firewalls have been mentioned as powerful tools used to enforce security policies at the edge of the network. Figure 9-1 depicts the most commonly deployed security topology in IPv4, with the focus on the firewall. Such perimeter defenses will most likely be used in IPv6 networks, too.

Two types of firewalls are offered through Cisco products: Cisco IOS Firewall features and the PIX family of products. Both these options are widely used in IPv4 networks, and now they support IPv6, too.

Cisco IOS Firewall

The Cisco IOS Firewall capabilities are often used in current IPv4 deployments. Many of these capabilities have been extended to support IPv6 (refer to the Cisco document "Implementing Security for IPv6" at Cisco.com):

• Packet fragment inspection uses the virtual fragment reassembly (VFR) to check for out-of-sequence fragments and duplicated fragments to identify possible DoS attacks.

  Note

  The Cisco IOS Firewall inspects the following IPv6 packet header fields: Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, and Source/Destination Address.

  
  

• IPv6 DoS attack mitigation is implemented in exactly the same way as in IPv4.

• Tunneled packet inspection is not performed inside the encapsulating IPv4 packet, but it can be done on the decapsulated IPv6 packet.

• Stateful inspection of UDP, TCP, ICMP, and FTP sessions.

• Stateful inspections of packets that are translated between IPv4 and IPv6.

• It handles EHs, Routing, Hop-by-Hop, Options, and Fragment headers.

• Port-to-application mapping (PAM) is a feature that enables network administrators to customize the TCP and UDP ports being used (that is, so that they are different from the well-known ports). This feature enables them to exercise content-based access control even on a wider range of ports.

Cisco IOS Firewall can perform these firewall features for both IPv4 and IPv6 at the same time and on the same interfaces.

Cisco IOS Firewall feature configuration involves several considerations. You can modify various parameters that are used for decision making in the inspection process in the global configuration, as shown in Example 9-4.

Example 9-4. Cisco IOS Firewall Feature Configuration Options

Router(config)#ipv6 inspect ? alert-off Disable alert audit-trail Enable the logging of session information (addresses and bytes) hashtable-size Specify size of hashtable max-incomplete Specify maximum number of incomplete connections before clamping name Specify an inspection rule one-minute Specify one-minute-sample watermarks for clamping routing-header Enable session routing header inspection tcp Config timeout values for tcp connections udp Config timeout values for udp flows

You can define inspection policies to include the various protocols recognized. The policy defined in Example 9-5 is named FW-EXAMPLE, and it includes inspection of all supported protocols: FTP, UDP, TCP and ICMP.

Example 9-5. Security Policy Configuration Example

Router(config)#ipv6 inspect name FW-EXAMPLE ftp timeout 100 Router(config)#ipv6 inspect name FW-EXAMPLE udp timeout 100 Router(config)#ipv6 inspect name FW-EXAMPLE tcp timeout 100 Router(config)#ipv6 inspect name FW-EXAMPLE icmp timeout 60 Router#show ipv6 inspect all Session audit trail is enabled Session alert is enabled Routing Header inspection is disabled one-minute (sampling period) thresholds are [400:500] connections max-incomplete sessions thresholds are [400:500] max-incomplete tcp connections per host is 50. Block-time 0 minute. tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec tcp idle-time is 3600 sec -- udp idle-time is 30 sec icmp idle-time is 10 sec Session hash table size is 1021 Inspection Rule Configuration Inspection name FW-EXAMPLE ftp alert is on audit-trail is on timeout 100 udp alert is on audit-trail is on timeout 100 tcp alert is on audit-trail is on timeout 100 icmp alert is on audit-trail is on timeout 60

After it has been defined, the policy is applied inbound or outbound to the interfaces of interest, as shown in Example 9-6.

Example 9-6. Applying Security Policies to Router Interfaces

Router(config-subif)#interface FastEthernet6/1.10 Router(config-subif)#ipv6 inspect FW-EXAMPLE in Router#show ipv6 inspect interface Interface Configuration Interface FastEthernet6/1.10 Inbound inspection rule is FW-EXAMPLE ftp alert is on audit-trail is on timeout 100 udp alert is on audit-trail is on timeout 100 tcp alert is on audit-trail is on timeout 100 icmp alert is on audit-trail is on timeout 60 Outgoing inspection rule is not set

To troubleshoot the inspection process, you can turn on the corresponding debug. In Example 9-7, the router is inspecting ICMPv6 traffic.

Example 9-7. Sample Debug of the Packet-Inspection Process

Router#debug ipv6 inspect icmp Mar 10 17:48:43.797: CBAC sis 69E1EAC4 L4 inspect result: PASS packet 6724896C ( 2001:2:2:1::1:0) (2001:2:C1:A001::2:0) bytes 1448 icmp Mar 10 17:48:45.797: CBAC sis 69E1EAC4 L4 inspect result: PASS packet 67249D34 ( 2001:2:2:1::1:0) (2001:2:C1:A001::2:0) bytes 1448 icmp

The other important tool used to properly inspect the traffic is the virtual reassembly process, which has to be enabled on the interface, as shown in Example 9-8.

Example 9-8. Enabling Virtual Reassembly on a Router Interface

Router(config-subif)#interface FastEthernet6/1.10 Router(config-subif)#ipv6 virtual-reassembly Router#show ipv6 virtual-reassembly FastEthernet6/1.10 %Interface FastEthernet6/1.10 IPv6 configured concurrent reassemblies (max-reassemblies): 64 IPv6 configured fragments per reassembly (max-fragments): 16 IPv6 configured reassembly timeout (timeout): 3 seconds IPv6 configured drop fragments: OFF IPv6 current reassembly count:1 IPv6 current fragment count:3 IPv6 total reassembly count:25 IPv6 total reassembly timeout count:0

Example 9-8 captures the output of the show virtual-reassembly command for the interface of interest. It lists the number of packets processed and the number of fragments that are being processed at the time.

PIX Firewall

The PIX Firewall is a device dedicated to implementing perimeter security policies. It is widely deployed in existent IPv4 networks, so it is important to understand its IPv6 capabilities. PIX Firewalls will most likely be used to secure IPv6 services, too.

PIX software release 7.0 is the first to support IPv6. It can perform security checks of IPv6 headers and EHs, multiple protocol (ICMP, UDP, TCP, SMTP, and HTTP) inspection, and through the adaptive security algorithm (ASA) it can perform stateful application inspection. For device-management purposes, the HTTP, SSH, and Telnet clients were also modified to support IPv6.

The IPv6 instructions for the PIX are Cisco IOS Firewall based, so they match the commands described in the "Access Lists" section of this chapter.

Authentication, Authorization, and Accounting

The authentication, authorization, and accounting (AAA) functions are critical in any deployment. AAA is used to manage users and devices or to collect service-usage information for billing. At the same time, AAA is a security tool, too. No large-scale IPv6 deployment could be rolled out without available AAA supporting IPv6.

In the first phase of the Cisco IPv6 implementation, the IPv6 AAA features were implemented by extending some of the vendor-specific attributes (VSAs) used for IPv4. Some of these VSAs have counterpart attributes that are RFC 3162 compliant and implemented for RADIUS. Table 9-2 summarizes the IPv6 RADIUS attributes and VSAs, and includes a brief description of their scope (refer to the Cisco document "Cisco IOS IPv6 Configuration Library" at Cisco.com).

Table 9-2. IPv6 AAA and RADIUS Attributes

RADIUS Attributes (RFC 3162)	VSAs	Description
NAS-IPv6-Address
Framed-Interface-Id		It is a per-user attribute used during IPv6 Control Protocol (IPv6CP) negotiation to indicate the IPv6 interface identifier to be configured.
Framed-IPv6-Prefix	IPv6 Prefix#	It is a per-user attribute used to indicate the prefix to be configured on the user in the case of virtual access. This prefix is advertised in the ND messages. The network access server (NAS) installs a static route for the prefix.
Login-IPv6-Host		It is a per-user attributed that indicates the system that the user connects with when the Login-Service attribute is present.
Framed-IPv6-Route	IPv6 Route	It is a per-user attribute that specifies the routing information that should be configured for the user on the NAS.
Framed-IPv6-Pool	IPv6 Pool	It is a per-user attribute that identifies a pool from which prefixes are assigned to the user. The pool can be configured on routers or RADIUS servers.
	IPv6 ACL	It specifies a full ACL that is applied to an interface while a user is logged in.

The configuration of these attributes is straightforward. Example 9-9 shows a user's profile configured on the RADIUS servers. When the user connects to the NAS via PPP, it is provided with the global prefix 2001:A:1::/64. An ACL will be applied outbound to stop any traffic sourced from the unique-local addresses used internally.

Example 9-9. RADIUS Server User Profile Example

user@isp.net Password = secret Service-Type = Framed, Framed-Protocol = PPP, Cisco-AVpair = "ipv6:prefix#1=2001:A:1::/64", Cisco-AVPair = "ipv6:outacl#1=deny FD00::/8 any"

These AAA features are important, particularly in the case of broadband deployments where large numbers of users have to be managed.

The other option for implementing the AAA functions is to use Terminal Access Controller Access Control System Plus (TACACS+). Despite being more versatile than RADIUS, TACACS+ is not as commonly deployed because it is more resource intensive (requires more processing and memory). At the time of this writing, TACACS+ is not implemented for IPv6 on Cisco IOS software.

Unicast Reverse Path Forwarding

Security policies that implement source address verification are important in eliminating spoofing attacks. These policies prevent spoofing of the source addresses at the prefix level. They should be implemented as close as possible to the location of unsecured devices and hosts.

An access network is a typical scenario where such policies can be applied. The service provider operating the network wants to make sure that its customers do not attempt to spoof an address on a different prefix from their own. Figure 9-6 shows the case where Host A is stopped from sending traffic using the address of Host B as a source address.

Figure 9-6. Securing an Access Network from Internally Sourced Spoofing Attacks

[View full size image]

The intent is to verify at the access router that customer packets received on an interface have a source address that belongs to the prefixes known (based on the routing table) to be out that interface. Access lists can, of course, be applied inbound to filter the traffic accordingly; however, this can involve management and provisioning burdens. Another way to achieve the same goal in a dynamic manner is to implement for unicast a mechanism similar to Reverse Path Forwarding (RPF) used in multicast forwarding. Unicast Reverse Path Forwarding (uRPF) checks the routing information to verify that the prefix of an inbound packet's source address is known to be reachable out the interface it was received on. The actual reverse lookup is done in the Cisco Express Forwarding (CEF) forwarding table.

If the reverse path calculated for the source address does not match the interface on which the packet was received or the source address cannot be identified (malformed source address), the packet is dropped.

This feature implements dynamically the functions of an inbound ACL. It is currently available in Cisco IOS software for both IPv4 and IPv6, and it represents a simple one-line interface configuration, as shown on Figure 9-6. If an ACL is designated at the end of the command ipv6 verify unicast reverse-path, the router applies it to the packet that failed the RPF check. The advantage of using the ACL option is that the ACL can be configured to log the matches and provide information that can be used to track policy violators.

Example 9-10. uRPF Configuration Example

interface ATM0/0/0.1 point-to-point ipv6 address 2001:1:1:1::1/64 ipv6 verify unicast reverse-path exampleRPF pvc 1/32 encapsulation aal5snap ipv6 access-list exampleRPF permit ipv6 2001:1:1:1::/64 any log-input deny ipv6 any any log-input

The ACL can simply be configured to permit all traffic and log it, in which case the violators of uRPF are let through but the violation is logged.

Depending on platform, the performance impact of enabling these features should be considered.

Protecting the Control Plane with Rate Limiting

To defend the network infrastructure from attacks, it is important to protect the control-plane resources of the network elements. Router resources (memory/CPU) on the line card or the route processor can be depleted by being overwhelmed with traffic that appears to be important to the control plane. Under such circumstances, the critical processes that maintain the router's integration in the network can be severely impacted.

This type of threat has been identified in the case of IPv4. IPv6 introduces new venues to attack a router's control plane, such as flooding it with router solicitation traffic or packets with the routing header.

At first, IPv6 services are likely to be considered of lower priority than the existent revenue-generating IPv4 services. This means that a router's control plane has to be particularly protected against IPv6 threats.

Certain types of traffic can be intelligently filtered out, but others cannot be identified a priori as a potential threat. In some of these cases, the attack is identified simply by the high rate of traffic received by the router. One defense against these flooding attacks is to limit that rate of traffic accepted by the router and thus preserve a minimum amount of CPU and memory for the control-plane operation.

The implementation of such mitigation plans depends on platform. Some platforms incorporate rate-limiting protection mechanisms in their default behavior, whereas others need to be configured for it. Some implement it in hardware, whereas others configure it in software. Cisco IOS command line offers a dedicated interface for configuring traffic rate limiting specifically for protecting a router's control plane, as shown here:

Router(config)#control-plane
Router(config-cp)#service-policy input <policy-name>

This interface leverages the standard QoS tools. A service policy has to be defined based on the guidelines discussed in Chapter 5, "Implementing QoS."