- WAN/Branch Deployment Overview
- General WAN/Branch IPv6 Deployment Considerations
- WAN/Branch Implementation Example
- WAN/Branch Deployment over Native IPv6
- Summary
- Additional References
This chapter is from the book
This chapter is from the book
This chapter is from the book
General WAN/Branch IPv6 Deployment Considerations
Some general considerations apply to the deployment profiles described in this chapter. The following sections describe the general considerations to take into account when deploying IPv6 in a branch network, regardless of the deployment profile being used. If a specific consideration should be understood, the specific profile is called out, along with the consideration for that profile.
The branch IPv6 profiles described in this chapter leverage the existing Cisco branch network design best practices as the foundation for all aspects of the deployment. The IPv6 components of the profiles are deployed in the same way as IPv4 whenever possible.
It is critical to understand the Cisco branch design best practice recommendations before deploying IPv6 in the branch profiles described in this chapter. The Cisco branch design best practice documents can be found under the "Branch Office" and "WAN" sections at http://www.cisco.com/en/US/netsol/ns816/networking_solutions_program_home.html.
Addressing
In most cases, the use of a /64 prefix on point-to-point (P2P) links is just fine. IPv6 was designed to have a large address space, and even with the poor address management in place, the customer should not experience address constraints.
Some network administrators think that a /64 prefix for P2P links is a waste of address space. There has been quite a bit of discussion within the IPv6 community about the practice of using longer prefixes for P2P links. For those network administrators who want to more tightly control the address space, it is safe to use a /126 prefix on P2P links in much the same way as /30 is used with IPv4. A /127 prefix can be used if you are aware of the potential address overlap with special use addresses. IPv6 address considerations can be found in RFC 5375 at http://www.ietf.org/rfc/rfc5375.txt.
The P2P configurations shown in this chapter use a /64 prefix. The assignment of end-host IPv6 addresses is done either by using Stateless Address Autoconfiguration (SLAAC) (see RFC 4862, "IPv6 Stateless Address Autoconfiguration"), which advertises an IPv6 prefix (through an RA) on the router subinterface for the VLAN where PCs are located, or through stateful DHCPv6. The options for Domain Name System (DNS) server and domain name are assigned using stateless DHCPv6 or stateful DHCPv6. The configurations for the SLAAC, stateless, and stateful DHCPv6 will be shown later in the chapter.
More information can be found on IPv6 addressing services at the following URL: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/15_0/ipv6_15_0_book.html.
Physical Connectivity
Considerations for physical connectivity with IPv6 are the same as with IPv4, plus five additional elements:
- Sufficient bandwidth: One important factor for deployment of any new technology, protocol, or application is to ensure that there is a sufficient amount of bandwidth for both existing and new traffic. This issue is especially true with the branch because, in many cases, the connections to the WAN are low-speed links and the reliance on QoS to solve bandwidth problems goes only so far. Bandwidth requirements for IPv6 are outside the scope of this chapter because there are many variables to account for and should therefore be considered on a case-by-case basis.
- Maximum transmission unit (MTU) and fragmentation: The minimum MTU size for IPv6 is 1280 bytes. If the link layer does not support the MTU requirement, link-layer fragmentation and reassembly must be provided and be transparent to IPv6. A good starting point for understanding MTU and Path MTU Discovery (PMTUD) for IPv6 is with RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) and RFC 1981 (http://www.ietf.org/rfc/rfc1981.txt).
- IPsec VPN: When IPsec is used with GRE or manual tunnels, it is important to account for how to adjust the MTU value on the routers to ensure that the router is not forced to perform fragmentation of the IPv4 traffic because of the IPsec header and the additional tunnel overhead. By manually configuring the MTU values prior to IPv6 encapsulation, the MTU requirements can be met for IPv6 without fragmentation concerns. More information on this can be found in any of the IPsec design guides at http://www.cisco.com/en/US/tech/tk583/tk372/tech_design_guides_list.html.
- 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, there are considerations to IPv6 with WLAN environments such as managing WLAN devices (APs and controllers) through IPv6 and controlling IPv6 traffic through AP or controller-based QoS, VLANs, and access control lists (ACL). IPv6 must be supported on the AP and controller devices to take advantage of these more intelligent services on the WLAN devices. At the time of writing this chapter, Cisco does not yet have robust IPv6 support on its WLAN product family.
- IPv6 phone ports: It is important to point out that Cisco supports the use of IPv6-enabled hosts that are directly attached to Cisco IP Phone ports. These IP phone ports are switch ports and operate in much the same way as plugging the host directly into a Catalyst Layer 2 switch.
In addition to the previous considerations, Cisco recommends that a thorough analysis of the existing traffic profiles, memory use, and CPU use on both the hosts and network equipment, and the service level agreement (SLA) language, be completed prior to implementing any of the IPv6 models described in this chapter.
VLANs
VLAN considerations for IPv6 are mostly the same as for IPv4. When dual-stack configurations are used, both IPv4 and IPv6 traverse the same VLAN. For the current VLAN design recommendations, refer to the Cisco branch–LAN design best practice documents at http://www.cisco.com/en/US/docs/solutions/Enterprise/Branch/Overview.html.
The use of IPv6 on data VLANs that are trunked along with voice VLANs (behind IP phones) is fully supported. Care must be taken to ensure that the correct firmware and proper Cisco Unified Communications Manager configurations are made to ensure that the data and voice VLANs do not allow IPv6 router advertisements (multicast-based) to be bled between VLANs.
For more information on IPv6 and Cisco IP Phones and how to best support VLANs for those endpoints, refer to the section "Unified Communications Endpoints" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html. For information on how to deploy IPv6 on the Cisco Unified Communications Manager, refer to http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html.
Routing
Choosing an interior gateway protocol (IGP) to run in the branch network is based on a variety of factors: Platform capabilities, IT staff expertise, and the size of network are just a few. In this chapter, the IGP for both IPv4 and IPv6 is Enhanced IGRP (EIGRP). Open Path Shortest First version 2 (OSPFv2) for IPv4 and OSPFv3 for IPv6 can also be used.
As previously mentioned, every effort to implement the current Cisco branch design best practices has been made. Both the IPv4 and IPv6 IGPs have been tuned according to the current best practices for the branch. 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 routing protocol.
EIGRP has been configured to provide authentication for both IPv4 and IPv6 adjacencies and updates.
High Availability
Many aspects of High Availability (HA) are not applicable to or are outside the scope of this chapter. Many of the HA requirements and recommendations are met by leveraging the existing Cisco branch design best practices. The primary HA components described in this chapter are
- Redundant WAN connections: The deployment of redundant WAN links can vary greatly from customer to customer. Some customers deploy a T1 with a backup connection over a different connection, such as a broadband DSL connection. Redundant Frame Relay connections and/or MPLS connections are also quite common.
- Redundant routing and forwarding paths: This is accomplished by leveraging EIGRP for IPv4 and IPv6. In some cases, Equal Cost Multi-Path (ECMP) is used, and in other cases (IPsec GRE and manual tunnels), one path is preferred over another, but the secondary path is available for redundancy.
- High availability of the first-hop gateways: This level of HA applies to any branch and/or WAN head-end connection where there are two or more routers. HSRPv2 for IPv4 and IPv6 can provide first-hop gateway redundancy in this chapter. Cisco also supports gateway load balancing protocol (GLBP) for IPv4 and IPv6.
QoS
Cisco recommends that QoS policies be implemented in an application- or service-dependent methodology instead of a protocol- (IPv4 or IPv6) dependent methodology. Basically, if the existing QoS policy has specific classification, policing, and queuing for an application, that policy should treat the IPv4 and IPv6 traffic for that application equally.
The key consideration as far as Modular QoS CLI (MQC) is concerned is the removal of the ip keyword in the QoS match and set statements when IPv6 QoS is required.
Table 8-1 shows the modification in the QoS syntax to support IPv6 and IPv4.
Table 8-1. QoS Syntax Modifications
|
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 |
There are QoS features that 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).
Cisco provides an extensive collection of QoS recommendations for the WAN/branch. See the references section at the end of this chapter for a complete list.
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 that plague both IPv4 and IPv6.
There are many new threats with IPv6 that do not exist with IPv4 or they operate differently from IPv4. There are inherent differences in how IPv6 handles neighbor and router advertisement and discovery, headers, and even fragmentation. Based on all of these variables and possibilities, IPv6 security is an involved topic in general, and detailed security recommendations and configurations are outside the scope of this chapter. There are numerous efforts both within Cisco and the industry to identify, understand, and resolve IPv6 security threats. There is an excellent Cisco Press book dedicated to the topic of IPv6 security: IPv6 Security, by Scott Hogg and Eric Vyncke. (See the "Additional References" section at the end of this chapter for more information.)
This chapter points out some possible areas to address within the branch and gives basic examples of how to provide basic protection of IPv6 dual-stack and tunneled traffic.
General security considerations for network device protection that apply to branch profiles are as follows:
Controlling management access to the branch routers and switches: All the branch/WAN routers and switches for each profile have configurations in place to provide management access protection to the devices. All routers have loopback interfaces configured for management and routing purposes.
To more tightly restrict access to a particular switch/router 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 device. The IPv6 prefix used in this enterprise site (for example only) is 2001:db8:cafe::/48. See Example 8-1.
Example 8-1. Router VTY Configuration
interface Loopback0
ipv6 address 2001:DB8:CAFE:1F3::9/128!ipv6 access-list MGMT-INremark Permit MGMT only to Loopback0permit tcp 2001:DB8:CAFE::/48 host 2001:DB8:CAFE:1F3::9deny ipv6 any any log-input ! line vty 0 4 session-timeout 3 access-class MGMT-IN-v4 in password 7 08334D400E1C17ipv6 access-class MGMT-IN in #Apply IPv6 ACL to restrict#accesslogging synchronous login local exec prompt timestamp transport input ssh- Controlling access through HTTP: At the time of this writing, Cisco IOS does not support the use of IPv6 HTTP ACLs to control access to the device. This is important because switches and routers that currently use ip http access-class ACLs for IPv4 do not have the same level of protection for IPv6. This means that subnets or users who were previously denied access through HTTP/HTTPS for IPv4 now have access to the switch or router through IPv6.
- Control Plane Policing (CoPP): CoPP protects the router by preventing DoS or unnecessary traffic from negatively impacting CPU resources. Priority is given to important control plane/management traffic. The configuration of CoPP is based on a wide variety of factors, and no single deployment recommendation can be made because the specifics of the policy are determined on a case-by-case basis. You can find more information about CoPP at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html.
-
Controlling ingress traffic from the branch LAN: Filter which prefixes are allowed to source traffic. This is most commonly done on ingress on the LAN or subinterface on the branch router. Controlling IPv6 traffic based on source prefix can help protect the network against basic spoofing.
Example 8-2 shows a basic ACL example: applied ingress on a branch router's LAN interface.
Example 8-2. Basic Branch LAN Ingress ACL
ipv6 access-list DATA_LAN-v6 remark PERMIT ICMPv6 PACKETS FROM HOSTS WITH PREFIX 2001:DB8:CAFE:1004::/64 permit icmp 2001:DB8:CAFE:1004::/64 any remark PERMIT IPv6 PACKETS FROM HOSTS WITH PREFIX 2001:DB8:CAFE:1004::64 permit ipv6 2001:DB8:CAFE:1004::/64 any remark PERMIT ICMPv6 PACKETS SOURCED BY HOSTS USING LINK-LOCAL permit icmp FE80::/10 any remark PERMIT DHCPv6 ALL-DHCP-AGENTS REQUESTS FROM HOSTS permit udp any eq 546 any eq 547 remark DENY ALL OTHER IPv6 PACKETS AND LOG deny ipv6 any any log-input ! interface GigabitEthernet0/0.104 description VLAN-PC ipv6 traffic-filter DATA_LAN-v6 in
Cisco IOS IPv6 ACLs contain implicit permit entries for IPv6 neighbor discovery. If deny ipv6 any any is configured, the implicit neighbor discovery entries are overridden. It is important that if a manually configured catch-all deny statement is used for logging purposes, the following two permit entries must be added back in: permit icmp any any nd-na and permit icmp any any nd-ns.
- IPv6 stateful firewall services: Firewalls provide a stateful security inspection for IPv6 traffic entering or leaving a branch network. At the time of this writing, the Cisco ASA 5500 Series, Cisco IOS Firewall, and Cisco IOS Zone-based Firewall support IPv6 inspection at various levels. It is critical that you consult with Cisco documentation, a Cisco account team, and/or a Cisco partner to understand which Cisco Firewall solution is appropriate for the customer environment.
- Disabling unused services: Many services, such as HTTP server, are supported for IPv4 and IPv6. Enabling or disabling these services generally applies to both protocols. It is a long-standing recommendation to disable any services that are not in use.
Multicast
IPv6 multicast is an important service for any enterprise network design. One of the most important factors to IPv6 multicast deployment is to ensure that host/group control is handled properly in the branch LAN. Multicast Listener Discovery (MLD) in IPv6 is the equivalent to Internet Group Management Protocol (IGMP) in IPv4. Both are used for host multicast group membership control. MLD snooping is the ability to control the distribution of multicast traffic only to the ports that have listeners. Without it, multicast traffic meant for only a single receiver (or group of receivers) would be flooded to all ports on the branch LAN switch belonging to the same VLAN. In the branch LAN, it is important that the switches support MLD snooping for MLD version 1 and/or version 2.
Today, Cisco IOS supports the following Protocol Independent Multicast (PIM) implementations: PIM-SM, PIM-BSR, PIM-SSM, Bidirectional PIM, Embedded-RP, and Multiprotocol BGP for the IPv6 Multicast Address Family.
There are several documents on Cisco.com and within the industry that describe IPv6 multicast in detail. Other than generic references to the commands that are used to enable IPv6 multicast and requirements for Embedded-RP definition, no other configuration notes are made in this chapter. For more information, refer to the following URLs:
- Cisco IPv6 multicast: http://www.cisco.com/en/US/technologies/tk648/tk828/tk363/technologies_white_paper0900aecd8014d6dd.html
- Cisco IOS IPv6 multicast configuration: http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a0080203f7a.shtml
Management
Management for IPv6 is under development and has a long way to go. Many of the traditional management tools used in IPv4 also support IPv6. In this chapter, the only considerations for management of the branch network are related to basic control of management services (Telnet, SSH, and SNMP). All the IPv6-enabled devices in the two branch profiles described are manageable over IPv6 through the previously mentioned services except SNMP.
The deployment of Simple Network Management Protocol (SNMP) for IPv6 is the same as with IPv4. In the branch profiles described in this chapter, SNMPv3 (AuthNoPriv) can provide polling capabilities for the Cisco Network Management Systems (NMS) servers located in the HQ data center. Here is an example of the SNMPv3 configuration used in the branch routers in this chapter:
snmp-server contact John Doe - ipv6rocks@example.com snmp-server group IPv6-ADMIN v3 auth write v1default snmp-server user jdoe IPv6-ADMIN v3 auth md5 cisco1234
If information needs to be sent to a Cisco NMS server, an SNMP host can be defined. The host can be defined to send SNMP information over IPv4 and/or IPv6:
snmp-server host 2001:DB8:CAFE:100::60 version 3 auth jdoe
Another area of management that must be thoroughly researched is that of address management. The process of assigning large hexadecimal addresses to many network devices should, at some point, be automated or at least made more user-friendly than it is today.
Today, one way to help with the deployment of address prefixes on a Cisco router is through the use of the general prefix feature. This feature enables the customer to define a prefix or prefixes in the global configuration of the router with a user-friendly name. That user-friendly name can be used on a per-interface basis to replace the usual IPv6 prefix definition on the interface. The general prefix feature is most applicable in deployments where there is or can be frequent changes in the address prefix, such as during a pilot or in early production when the final IPv6 address policy is not fully nailed down. The following is an example of how to use the general prefix feature:
Step 1. Define the general prefix:
br1-1(config)# ipv6 general-prefix BRANCH-1 2001:DB8:CAFE::/48Step 2. Configure the general prefix named BRANCH-1 on a per-interface basis:
br1-1(config-if)# ipv6 address BRANCH-1 ::1005:0:0:0:1/64
Step 3. Verify that the general prefix was correctly assigned to the interface:
br1-1# show ipv6 interface g1/0.100 GigabitEthernet1/0.100 is up, line protocol is up IPv6 is enabled, link-local address is FE80::217:94FF:FE90:2829 No Virtual link-local address(es): Description: DATA VLAN for Computers Global unicast address(es): 2001:DB8:CAFE:1005::1, subnet is 2001:DB8:CAFE:1005::/64
You can find more information on the general prefix feature at the Cisco IOS IPv6 documentation page at http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1132473.
Cisco supports the management of IPv6-enabled network devices through a variety of network management products to include DNS, DHCPv6, device management and monitoring, and network management, troubleshooting, and reporting. You can find more information on the various Cisco Network Management solutions at http://www.cisco.com/en/US/products/sw/netmgtsw/index.html.
Chapter 11, "Managing IPv6 Networks," goes into greater detail on IPv6 management.
Scalability and Performance
This chapter is not meant to analyze scalability and performance information for the various platforms tested. The coverage of scale and performance is more focused on general considerations when planning and deploying IPv6 in the branch versus a platform-specific view.
Scalability and performance considerations for the branch network devices are as follows:
- Traffic utilization: In IPv6 implementations, it is common to see a change in traffic utilization ratios on the branch network links. As IPv6 is deployed, IPv4 traffic utilization is often reduced as users leverage IPv6 as the transport for applications that were historically IPv4-only. There is often a slight increase in overall network utilization, which usually derives from control traffic for routing and, if deployed, tunnel overhead.
- Routing/forwarding: It is important to understand the routing and forwarding capabilities of the branch routers. If the existing branch router is already running at high CPU and memory utilization rates for the handling of IPv4 routing tables and updates, it is a bad idea to add IPv6 to the existing router. If the routing platform is hardware based, the impact is less of a concern.
- ACL processing: It is imperative that the deployment of ACLs be carefully planned. IPv6 ACLs in the branch routers are used for QoS (classification and marking of ingress packets from the access layer), for security (controlling DoS, snooping, and unauthorized access for ingress traffic in the access layer), and for a combination of QoS + security to protect the control plane of the router from attack. The router can also provide Cisco IOS stateful firewalling services, intrusion detection systems/intrusion prevention systems (IDS/IPS), and voice services for IPv4 and new services for IPv6. Advanced services that are added to the branch router should support both IPv4 and IPv6. Performance will be impacted with all these added services plus the newly enabled IPv6 configuration.
Cisco has an IPv4/IPv6 performance comparison document that goes into some detail on these topics at http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf.