Many considerations apply to all the deployment models discussed in this topic. The following sections focus on the general ones that apply to deploying IPv6 in a campus network, regardless of the deployment model being used. If a particular consideration must be understood in the context of a specific model, this model is called out along with the consideration. Also, the configurations for any model-specific considerations can be found in the implementation section of that model.
All campus IPv6 models discussed in this topic leverage the existing campus network design as the foundation for providing physical access, VLANs, IPv4 routing (for tunnels), QoS (for tunnels), infrastructure security (protecting the tunnels), and availability (device, link, trunk, and routing). When dual-stack is used, nearly all design principles found in Cisco campus design best practice documents are applicable to both IPv4 and IPv6.
It is critical to understand the Cisco campus best practice recommendations before jumping into the deployment of the IPv6 campus models discussed in this topic. The Cisco campus design best practice documents can be found at the following URL: http://www.cisco.com/en/US/netsol/ns815/networking_solutions_program_home.html.
Addressing
As mentioned previously, this topic is not an introductory topic and does not discuss the basics of IPv6 addressing. However, it is important to discuss a few addressing considerations for the network devices, specifically for links.
Table 6-2 lists the options related to the use of various prefix lengths on links.
Notes for Table 6-2:
■ /64: On VLAN interfaces, it is recommended to use a /64 prefix because it is easy and consistent for address management. This is required for Stateless Address Autoconfiguration (SLAAC), Secure Neighbor Discovery (SEND), and privacy extension use.
Table 6-2 Prefix Length Considerations
|
64 Bits |
Greater Than 64 Bits |
Less Than 64 Bits |
|
Recommended by RFC 5375 and IAB/IESG |
Address space conservation |
Enables more hosts per broadcast domain |
|
Consistency makes management easy |
Special cases: - /126 – Valid for p2p - /127 – Valid for p2p if aware of overlapping addresses (RFC 3627) - /128 – Loopback |
Considered bad practice |
|
/64 required for SLAAC, SEND, and Privacy extensions |
Complicates management |
64 bits offers more space for hosts than media can support efficiently |
|
Significant address space loss |
Must avoid overlap with specific addresses: - Router Anycast (RFC 3513) - Embedded RP (RFC 3956) |
No real justifiable use case for this option |
■ Greater than 64: Many in the networking community think that a /64 prefix for p2p links is a waste of space. The debate rages on regarding the use of various prefix lengths on p2p links, and the reader is encouraged to balance the legalistic RFC stipulations with real-world deployment considerations. In many deployments, it is common to use a /64 on VLANs (or links where hosts reside), /126 on p2p links, /127 on p2p links if you are aware of the potential overlap with specific addresses (at the time of this writing, an IETF draft exists for the safe use of /127, "Using 127-bit IPv6 Prefixes on Inter-Router Links), and /128 on loopbacks. In this topic, /64 is used everywhere except for loopback interfaces, where a /128 is used.
■ Less than 64: There are no real use cases where a site needs more addressing on a link than a /64 can provide and is considered a bad practice.
RFC 3627, "Use of /127 Prefix Length Between Routers Considered Harmful," discusses the reasons why the use of a /127 prefix can cause address overlap with special use addresses..
Physical Connectivity
Considerations for physical connectivity with IPv6 are the same as with IPv4, with the addition of the following elements:
■ Ensuring that there is sufficient bandwidth for both existing and new traffic:
This is an important factor for the deployment of any new technology, protocol, or application.
■ Understanding how IPv6 deals with the maximum transmission unit (MTU) on a link: This topic is not an introductory topic for basic IPv6 protocol operation or specifications. A good starting point for understanding MTU and Path MTU Discovery (PMTUD) for IPv6 is with RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification," and RFC 1981, "Path MTU Discovery for IP version 6."
■ Operating IPv6 over wireless LANs (WLAN): IPv6 should operate correctly over WLAN access points in much the same way as IPv6 operates over Layer 2 switches. However, you must consider IPv6 specifics in WLAN environments, including managing WLAN devices (access points [AP] and controllers) through IPv6 and controlling IPv6 traffic through AP or controller-based QoS, VLANs, and ACLs. IPv6 must be supported on the AP and/or controller devices to take advantage of these more intelligent services on the WLAN devices.
In addition to the preceding considerations, Cisco recommends a thorough analysis of the existing traffic profiles, memory, and CPU utilization on both the hosts and network equipment. Also complete the Service Level Agreement (SLA) before implementing any of the IPv6 models discussed in this topic.
VLANs
VLAN considerations for IPv6 are the same as for IPv4. When dual-stack configurations are used, both IPv4 and IPv6 traverse the same VLAN. When tunneling is used, IPv4 and the tunneled IPv6 (protocol 41) traffic traverse the VLAN.
IPv6 on data VLANs that are trunked along with voice VLANs (behind IP phones) is fully supported. Depending on the configuration of the data and voice VLANs, you might experience an issue where the Layer 2 multicast router advertisements from the Layer 3 data VLAN interface might bleed over to the attached host (connected to the IP phone or a voice VLAN-enabled switch port). Basically, a PC connected to an IP phone can receive RAs for both the data and voice VLANs. This is an issue that can be manifest regardless of vendor and switch/phone version. Stay tuned for updated best practices on how to properly deal with this on the Layer 3 VLAN configurations or through a possible setting in the Cisco IP Phones that prevents flooding of IPv6 router advertisements on the data VLAN.
For the current VLAN design recommendations, see the references to the Cisco campus design best practice documents in the "Additional References" section, later in this topic.
Routing
The decision to run an IGP in the campus network is made based on a variety of factors such as platform capabilities, IT staff expertise, topology, and size of network. In this topic, the IGP for IPv4 is Enhanced IGRP (EIGRP), but Open Shortest Path First version 2 (OSPFv2) for IPv4 can also be used. The IGP configurations for IPv6 can either be EIGRP or OSPFv3. These IGPs are interchanged in some sections to show the reader what the basic configuration looks like for either IGP.
There are many similarities in how the IGPs function between IPv4 and IPv6, so you end up with similar behavior and expectations. As a rule of thumb, most deployments will start by using the same IGP as is used with IPv4. This allows a smaller learning curve because the staff already understands that IGP. However, in some cases, this is the time when some deployments can use a different IGP for IPv6. This is a greenfield deployment as it relates to IPv6, so it is up to you to figure out whether you want to go in a different direction for the IGP choice. Perhaps you stick with the same IGP but do a better job of summarization or use different functions within the IGP such as a distribution list—or whatever makes sense in your network. The bottom line is to use what works and what you are familiar with, but if the business or technical drivers within your environment dictate a change, make the change.
As previously mentioned, every effort has been made to implement the current Cisco campus design best practices. Both the IPv4 and IPv6 IGPs have been tuned according to the current best practices where possible. It should be one of the top priorities of any network design to ensure that the IGPs are tuned to provide a stable, scalable, and fast-converging network.
High Availability
Many aspects of high availability (HA) are not applicable to or are outside of the scope of this topic. Many of the HA requirements and recommendations are met by leveraging the existing Cisco campus design best practices. The following are the primary HA components discussed in this topic:
■ Redundant routing and forwarding paths: These are accomplished by using EIGRP or OSPFv2 for IPv4 when redundant paths for tunnels are needed, and EIGRP for IPv6 or OSPFv3 for IPv6 when dual-stack is used, along with the functionality of Cisco Express Forwarding (CEF).
■ Redundant Layer 3 switches for terminating ISATAP and manually configured tunnels: These redundant Layer 3 switches are applicable in the HM and SBM designs. In addition to having redundant hardware, it is important to implement redundant tunnels (ISATAP and manually configured). The implementation sections illustrate the configuration and results of using redundant tunnels for HM and SBM designs.
■ High availability of the first-hop gateways: In the DSM design, the distribution layer switches are the first Layer 3 devices to the hosts in the access layer. Traditional campus designs use first-hop redundancy protocols such as Hot Standby Routing Protocol (HSRP) and Gateway Load Balancing Protocol (GLBP). In this topic, configurations are shown with HSRP for IPv6. The configuration for first-hop routing protocols such as HSRP are discussed in the section "Implementing the Dual-Stack Model," later in this topic.
QoS
With DSM, it is easy to extend or leverage the existing IPv4 QoS policies to include the new IPv6 traffic traversing the campus network. Cisco recommends that the QoS policies implemented be application- and/or service-dependent instead of protocol-dependent (IPv4 or IPv6). If the existing QoS policy has specific classification, policing, and queuing for an application, that policy should treat equally the IPv4 and IPv6 traffic for that application.
Special consideration should be provided to the QoS policies for tunneled traffic. QoS for ISATAP-tunneled traffic is somewhat limited. When ISATAP tunnels are used, the ingress classification of IPv6 packets cannot be made at the access layer, which is the recommended location for trusting or classifying ingress traffic. In the HM and SBM designs, the access layer has no IPv6 support. Tunnels are being used between the hosts in the access layer and either the core layer (HM) or the SBM switches, and therefore ingress classification cannot be done.
QoS policies for IPv6 can be implemented after the decapsulation of the tunneled traffic, but this also presents a unique challenge. Tunneled IPv6 traffic cannot even be classified after it reaches the tunnel destination, because ingress marking cannot be done until the IPv6 traffic is decapsulated (ingress classification and marking are done on the physical interface and not the tunnel interface). Egress classification policies can be implemented on any IPv6 traffic now decapsulated and being forwarded by the switch. Trust, policing, and queuing policies can be implemented on upstream switches to properly deal with the IPv6 traffic.
Figure 6-7 illustrates the points where IPv6 QoS policies can be applied when using ISAT-AP in HM. The dual-stack links shown have QoS policies that apply to both IPv4 and IPv6. Refer to the "Additional References" section, later in this topic, for more information about the Cisco campus QoS documentation.
Figure 6-7 QoS Implementation – The Hybrid Model
The following list explains the two steps illustrated in Figure 6-7:
Step 1. In the HM, the first place to implement classification and marking is on the egress interfaces on the core layer switches. As was previously mentioned, the IPv6 packets have been tunneled from the hosts in the access layer to the core layer, and the IPv6 packets have not been "visible" in a decapsulated state until the core layer. Because QoS policies for classification and marking cannot be applied to the ISATAP tunnels on ingress, the first place to apply the policy is on egress.
Step 2. The classified and marked IPv6 packets (see item 1) can now be examined by upstream switches (for example, aggregation layer switches), and the appropriate QoS policies can be applied on ingress. These polices can include trust (ingress), policing (ingress), and queuing (egress).
Figure 6-8 illustrates the points where IPv6 QoS policies can be applied in the SBM when ISATAP manually configured tunnels are used.
Figure 6-8 QoS Policy Implementation – SBM (ISAT-AP/Manually Configured Tunnels)
The following list explains the two steps illustrated in Figure 6-8:
Step 1. The SBM switches receive IPv6 packets coming from the ISATAP interfaces, which are now decapsulated, and can apply classification and marking policies on the egress manually configured tunnel interfaces.
Step 2. The upstream switches (aggregation layer and access layer) can now apply trust, policing, and queuing policies after the IPv6 packets leave the manually configured tunnel interfaces in the aggregation layer.
Note At the time of this writing, microflow policing of IPv6 multicast packets on the Catalyst 6500 Supervisor 32/720 is not supported. In the SBM design, as of the release of this topic, the policing of IPv6 packets must take place on ingress, and the ingress interface must not be a tunnel. For more information, see the PFC3 QoS documentation at the following URL: http://tinyurl.com/2ewv7mp.
The key consideration for Modular QoS CLI (MQC) is the removal of the ip keyword in the QoS match and set statements. Modification in the QoS syntax to support IPv6 and IPv4 allows new configuration criteria, as shown in Table 6-3.
Table 6-3 QoS Configuration Changes – IPv4/IPv6
|
IPv4-Only QoS Syntax |
IPv4/IPv6 QoS Syntax |
|
match ip dscp |
match dscp |
|
match ip precedence |
match precedence |
|
set ip dscp |
set dscp |
|
set ip precedence |
set precedence |
Some QoS features work for both IPv6 and IPv4 but require no modification to the command-line interface (CLI), for example, weighted random early detection (WRED), policing, and weighted round robin (WRR).
The implementation section for each model does not go into great detail on QoS configuration in relation to the definition of classes for certain applications, the associated mapping of differentiated services code point (DSCP) values, and the bandwidth and queuing recommendations. Cisco provides an extensive collection of QoS recommendations for the campus, which is available on Cisco.com as well as in the Cisco Press book End-to-End QoS Network Design. Refer to the "Additional References" section, later in this topic, for more information about the Cisco campus QoS recommendations and Cisco Press books.
Security
Many of the common threats and attacks on existing IPv4 campus networks also apply to IPv6. Unauthorized access, spoofing, routing attacks, viruses/worms, denial of service (DoS), and man-in-the-middle attacks are just a few of the threats to both IPv4 and IPv6.
With IPv6, many threat possibilities do not apply or at least do not apply in the same way as with IPv4. There are inherent differences in how IPv6 handles neighbor and router advertisement and discovery, headers, and even fragmentation. There are numerous efforts, both within Cisco and in the industry, to identify, understand, and resolve IPv6 security threats. This topic points out some possible areas to address within the campus and gives basic examples of how to provide protection for IPv6 dual-stack and tunneled traffic. The section "Implementing the Dual-Stack Model," later in this topic, discusses first-hop security in a dual-stack deployment.
Note The examples given in this topic are in no way meant to be recommendations or guidelines, but rather are intended to challenge you to carefully analyze your own security policies as they apply to IPv6 in the campus.
The following sections describe general security guidelines for network device protection that apply to all campus models.
Making Reconnaissance More Difficult Through Complex Address Assignment
Addressing of campus network devices (Layer 2 and 3 switches) should be well planned. Many security professionals recommend that the global or unique local addressing (ULA) address of the switch is a value that is not easily guessed. An example of a well-known interface ID for a switch is if VLAN 2 has an address of 2001:db8:cafe:2::1/64 and VLAN 3 has an address of 2001:db8:cafe:3::1/64, where ::1 is the interface ID of the switch. This address is easily guessed and allows an attacker to quickly understand the common addressing for the campus infrastructure devices. Another option is to randomize the interface ID of all the devices in the campus. Using the VLAN 2 and VLAN 3 examples from the previous example, a new address can be constructed by using an address such as 2001:db8:cafe:2::a010:f1a1 for VLAN 2 and 2001:db8:cafe:3::c801:167a for VLAN 3, where "a010:f1a1" is the interface ID of VLAN 2 for the switch.
The addressing consideration described in this section introduces significant operational challenges. For the sake of easing operational management of the network devices and addressing, you should balance the security aspects of randomizing the interface IDs with the ability to deploy and manage the devices through the semirandomized addresses.
Controlling Management Access to the Campus Switches
To more tightly restrict access to a particular switch through IPv6, an ACL is used to permit access to the management interface (line vty) by way of the loopback interface. The permitted source network is from the enterprise IPv6 prefix. To make ACL generation more scalable for a wide range of network devices, the ACL definition can permit the entire enterprise prefix as the primary method for controlling management access to the device instead of filtering to a specific interface on the switch. The IPv6 prefix used in this enterprise site (example only) is 2001:db8:cafe::/48.
Example 6-1 illustrates how a basic ACL can be constructed to restrict VTY access to the switch.
Example 6-1 Line VTY Access Control List
The security requirements for running Simple Network Management Protocol (SNMP) are the same as with IPv4. If SNMP is needed, a choice should be made on the SNMP version and then access control and authentication/encryption. In the campus models di cussed in this topic, SNMPv3 (AuthNoPriv) is used to provide polling capabilities for the Cisco NMS servers located in the data center.
■ Example 6-2 shows the SNMPv3 configuration used in the campus switches in this topic.
Example 6-2 SNMP Configuration
At the time of this writing, Cisco Catalyst switches do not support the use of IPv6 HTTP ACLs to control access to the switch. This is very important because switches that currently use ip http access-class ACLs for IPv4 do not have the same level of protection for IPv6. This feature gap means that subnets or users that were previously denied access through HTTP/HTTPS for IPv4 now have access to the switch through IPv6. It is recommended that the HTTP/HTTPS server is disabled unless direct management access to the device over these protocols is required.
