Design and Setup

Lessons learned during the trial period were positive enough to get the management approval for an IPv6 integration project. As with any networking project, there are several steps to go through before advertising IPv6 as a production service. One initial step is to develop a design of the IPv6 intranet and issue AC policies before the start of the rollout. This section does not indicate the amount of time required to achieve each phase. It is assumed that several months would be needed, depending on parameters such as IT department workload, cost control, and the availability of stable and affordable commercial solutions. Mandatory steps include the following:

• Definition of the IPv6 addressing scheme and rules

• Guidelines for IPv6 integration on existing intranet, including

  - Selection of routing protocol(s)

  - High-availability options on AC LANs

• Planning of IPv6 services to be set up, compliant with the requirements defined by the AC IT department:

  - Security Must provide a level of security equivalent with to that for IPv4 from day one for every site that is updated. Must also cope with the specifics of IPv6, including new services such as IP mobility.
  
  

  - Network management Integration of the IPv6 configuration and traffic management in the actual IPv4 NMS system is mandatory. Optionally, SNMP and management applications could run over an IPv6 network layer. Networking devices must support Management Information Bases (MIBs) for IPv6 statistics.
  
  

  - Multicast IPv4 multicast is an experimental service on the AC network. The operational side of dealing with multicast through NAT to cover the remote site was seen as too complex. IPv6 multicast service should become the de facto production service for multicast. AC expects to decrease the cost of operations and ease the full deployment of multicast.
  
  

  - Mobility This is a new service for AC. It will start as experimental. The purpose is to enable the deployment of new appliances and expand Internet connectivity in the AC fleet of vehicles.
  
  

  - QoS The goal is to ensure optimal operation of applications independently of the network layer protocol. Same QoS rules must apply to both IP versions.
  
  

IPv6 Addressing

Similar to the IPv4 design, one of the first actions is to define an address scheme. The next section introduces the AC plans for prefix and host address assignments.

Prefix-Assignment Scheme

At the time of this writing, the Registries only allocate an IPv6 prefixa ::/32 or greater address spaceto ISPs, NRNs, and government agencies, meaning an enterprise must get an IPv6 prefix (::/48) from its ISP. Part of the IPv6negotiation with T-World was the subscription of a prefix for AC; it is assigned 2001:0DB8:ACAC::/48.

The remaining 16 bits' significance has to be defined. They will be partitioned based on the scheme shown in Table 15-4.

Table 15-4. AC Corporation IPv6 Addressing Scheme

Region ID (3 Bits)	Headquarters and Attached Sites (5 Bits)	Link ID per Site (8 Bits)
North America (000)	San Francisco (00000) Atlanta (00100) Montreal (10000)	00-FF
Europe (001)	Budapest (00000) Paris (00100)	00-FF
Asia-Pacific (010)	Hong Kong (00000) Sydney (00100) Tokyo (10000)	00-FF
Africa and Middle East (011)	Dubai (00000) Johannesburg (00100)	00-FF
Latin and Central America (100)	Buenos Aires (00000) Mexico City (00100)	00-FF
Reserved for future (101111)	Reserved for future	00-FF

Address Configuration Rules

Although IPv6 specifications define the support of stateful and stateless autoconfiguration mechanisms to assign an IPv6 address to a host interface, as discussed in Chapter 3, most of the host implementations only support the stateless option. This means there are only two modes of IPv6 address allocation that can be practically considered for a deployment: manual or stateless.

With the prefix provided, the host needs an interface ID. There are several ways in which the interface ID can be selected. It can be manually configured, it can be derived from the MAC address following the EUI-64 rules, or it can be built using the "privacy extensions" defined in RFC 3041 (as described in Chapter 2, "An IPv6 Refresher"). Remember that an IPv6 host interface may have a set of unicast addresses in use.

The following guidelines were established for selecting interface IDs in the AC IPv6 network:

• DNS servers and network management stations get an IPv6 address manually configured. For resources not to be known from the Internet (for instance, NMSs), it is recommended to not set an obvious interface ID, such as x::1/128, to avoid easy distributed denial-of-service (DDoS) attacks.

• Application servers get an IPv6 interface ID manually configured unless they support Dynamic DNS, in which later case they can use stateless autoconfiguration with EUI-64.

• Networking devices can use EUI-64 as the interface ID, but at least one interfacetypically loopbackmust have an address with the interface ID manually configured for network management purposes. This eliminates the device reachability dependency on its hardware information. A complete swap of hardware can take place in case of failure, and the device will remain reachable by the NMS after the device configuration is reloaded.

• On point-to-point links, the 2001:0DB8:ACAC:nnnn::/64 prefix will be preferred to keep the configuration simple and aligned with the IPv6 address architecture (RFC 3513). For more information, refer also to RFC 3627.

• Hosts actually configured through DHCP for IPv4 get their IPv6 address through stateless autoconfiguration.

• Hosts supporting "privacy extensions" interface IDs must have a default value of 24 hours. Privacy extensions is a new capability, and its impact on traceability and managing DDoS threats may not be fully understood. Nevertheless, the basic policies related to the use of privacy extensions are as follows:

  - No host ACL should be used unless it only permits a specific IPv6 address and deny all.

  - A user-tracking network management application is required to identify the hosts.

Dual-Stack Deployment

The initial trial lessons and list of identified services AC intends to run over IPv6 led the team to choose a dual-stack approach. After running a network inventory, the needs to upgrade some hardware and software releases are known by the AC IT team and adequately budgeted in association with other programs for the next fiscal year.

On campus LANs, layer 3 switches will be configured to run native IPv6for instance, Catalyst 6500 series with supervisor engine 720 and native Cisco IOS 12.2(18)SXE release or Catalyst 3750 series and Cisco IOS 12.2(25)SEA release as minimum.

Remote sites connected through leased lines will get their router software releases updated to support dual-stack operation. To reduce the labor costs, this upgrade will be associated with the update program to the Cisco 1800 and 2800 series. The minimum release to match AC service needs is Cisco IOS 12.4(2)T. Table 15-5 summarizes the platform/IOS mapping targeted for the deployment.

Table 15-5. Platforms and Minimum Cisco IOS Software Used in the IPv6 Deployment

Network Location	Hardware Platform	Software(IOS)
Main campus	Catalyst 6500 SUP-720 Cisco 3750	12.2(18)SXE 12.2(25)SEA
Remote sites' WAN router	Cisco 1800 Cisco 2800	12.4(2)T 12.4(2)T

Remote sites connected via broadband access will have an IPv6-configured tunnel setup. Because IPv4 is the primary service and is already protected via the VPN tunnel between site-to-site routers to one of the main AC campuses, there is no local access security concern about adding IPv6 services. The configured tunnel allows the allocation of global IPv6 prefixes in accordance with AC rules. The addition of a global IPv6 prefix to those sites that are configured with a single static IPv4 address on the WAN link and private address on LAN ease the potential deployment of multicast and peer-to-peer applications. The IPv6 manually configured tunnels do not have to be terminated on the same device as the IPv4 IPsec VPN tunnel. When possible, they will get terminated on a Catalyst 6500 supervisor engine 720 that does support this tunnel mechanism in hardware.

Routing Protocols

To keep the learning curve and operational process at a minimal level, similar routing protocols will be deployed for IPv6 and IPv4, meaning EIGRP for IGP and MP-BGP4 for peering with T-World (see Chapter 4, "IPv6 Routing Protocols," for details and configuration on these protocols).

In the final phase of the project, the entire network is converted to dual stack. In an effort to keep the operational and management tasks as simple as possible, it is decided to align the IPv4 and IPv6 topologies for all routers and links in the network. The routing protocol parameters are configured to get all traffic flowing through similar paths. This decision is taken to ease the operational support, to avoid complex troubleshooting where communications between two nodes could work for a given IP version but not the other because different paths followed through the network.

First-Hop Router Redundancy

IPv6 hosts on a broadcast link learn about the presence of one or more gateways by receiving Router Advertisements (RAs) sent using the IPv6 Neighbor Discovery Protocol (see Chapter 2). The Router Advertisements are periodically sent via multicast at a rate high enough to ensure that hosts learn about the routers in the span of a few minutes, which therefore removes the need to set a "default gateway" (as in the case of IPv4). The selection of a given router depends on the host IPv6 stack implementation. On the other hand, by default, RAs are not sent frequently enough to rely on the absence of the router advertisement to detect router failures. Therefore, there is a need for tuning the ND process and leveraging additional protocols to improve the availability of first-hop routers:

• Tuning ICMPv6 and Neighbor Discovery

• Configuring Default Router Selection

• Enabling one of the first-hop redundancy router protocols: Cisco Hot Standby Router Protocol (HSRP), Cisco Gateway Load Balancing Protocol (GLBP), or Virtual Router Redundancy Protocol (VRRP)

Tuning Neighbor Discovery

Neighbor Discovery (Chapter 2) includes a mechanism called Neighbor Unreachability Detection (NUD), which is used to detect the failure of a neighbor node (router or host) or the forwarding path to a neighbor. This is done by sending Neighbor Solicitation messages to the neighbor node. To reduce the overhead of sending Neighbor Solicitations, the messages are only sent to neighbors to whom the node is actively sending traffic and only after there has been no positive indication that the router is up for a period of time. Using the default parameteripv6 nd reachable-timeit will take a host about 30 seconds to learn that a router is unreachable before it will switch to another router. This delay would be noticeable to users and can cause some transport protocol implementations to time out.

In the absence of any other first-hop router redundancy protocol, such as Cisco HSRP, tuning of NUD is a useful alternative. Setting of the ipv6 nd reachable-time parameter to a more aggressive value allows the speedup of the switchover time, but it has the downside of significantly increasing the overhead of ND traffic. This would be specially noticeable when there are hundreds of hosts on a link (because they all would try to determine the reachability of their gateways). A good tradeoff between potential ND bursts and switchover times seems to be 15 seconds versus the 30-second default value.

Example 15-12 shows how to configure the ND Reachable timer on a router's interface.

Example 15-12. ND Reachable Timer Configuration

R1# ! interface GigabitEthernet0/1 ipv6 address 2001:DB8:ACAC:1::/64 eui-64 ipv6 nd reachable-time 15000 !

On an AC network, this will only be configured when Cisco HSRP for IPv6 or other first-hop redundancy mechanisms are not available on layer 3 switches or routers; otherwise, default value are kept.

Configuring Default Router Selection

Because IPv6 ND did not initially specify a way to set a default router, IPv6 hosts learn about all routers available on a LAN through the ND RA mechanism. It is the responsibility of the hosts to maintain a default router list from which one is selected for forwarding traffic to off-link destinations. The selection for a destination is then cached, and the implementation of selecting gateways can be round robin or "always the same."

This is simple and works well in most cases, but in some situations, it is suboptimal:

• Some form of traffic engineering is desired (for example, when two routers on a link provide equivalent, but not equal-cost, routing). Policy may dictate that one is preferred. These are two relevant examples:

  - "Accidentally" deploying a new router before it has been fully configured could lead to hosts adopting it as a default router and traffic being black-holed. Management may want to indicate that some routers are more preferred than others.

  - Multiple routers that route to distinct sets of prefixes. Redirects (sent by nonoptimal routers for a destination) mean that hosts can choose any router and the system will work. But traffic patterns may mean that choosing one of the routers would lead to considerably fewer redirects.

• The IPv6 router selection IETF Internet Draft (draft-ietf-ipv6-router-selection) defines two optional extensions to ND RA messages:

  - Default Router Preferences (DRP) A coarse preference metric for default routers. This is an extremely simple extensionjust the definition of a few unused bits in existing RA messages to address the first example mentioned above.
  
  

  - More-Specific Routes (MSR) An option to allow routers to specify routes more specific than the default route, together with a lifetime; a coarse preference metric for each such routes to address the second case mentioned above.
  
  

Both are backward compatible with the existing RA mechanism and host behavior. DRP can be implemented without implementing MSR.

By default, Cisco IOS routers send RAs with a preference of medium. The no version of the command returns the configuration to the default value. On AC LANs, the routers managed by the IT will be set to high to avoid basic misconfiguration in case a new router is added to a segment.

Example 15-13 shows router preference set up to high on a router's interface loaded with Cisco IOS Release 12.4(2)T.

Example 15-13. Router Preference Setup

R1# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High !

Example 15-14 shows the command to check the configuration of both ND reachable timer and router preference.

Example 15-14. Display of ND Reachable Timer and Router Preference Setup

R1#show ipv6 inter e0/0 Ethernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:1F00 Global unicast address(es): 2001:DB8:ACAC:10:A8BB:CCFF:FE00:1F00, subnet is 2001:DB8:ACAC:10::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1F00 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 15000 milliseconds ND advertised default router preference is High

Enabling Cisco HSRP for IPv6

A first-hop redundancy protocol, such as Cisco HSRP, can provide a much faster switchover to an alternate router than can be obtained using standard ND procedures. Using HSRP, a backup router can take over for a failed default router in about 10 seconds using default parameters, or less than 1 second if millisecond HSRP timers are used. This is done without any interaction with the hosts, and with a minimum amount of HSRP traffic.

Most IPv4 hosts have a single router IP address configured as the default gateway. When Cisco HSRP is set up, the HSRP virtual IPv4 address is configured as the hosts' default gateway rather than the router IP address.

Most changes to HSRP for IPv6 are to the ND functions (Neighbor Advertisement, Router Advertisement, and ICMPv6 redirects).

An HSRP IPv6 group has a virtual MAC addressblock different from the Cisco HSRP one for IPv4that is derived from the HSRP group number. A virtual IPv6 link-local address is also derived, by default, from the HSRP virtual MAC address.

A common way to form an IPv6 link-local address is by appending an interface ID to the prefix FE80::/64. The interface ID for an HSRP group is based on the EUI-64 identifier derived from the HSRP group virtual MAC address. The EUI-64 is formed as shown in Chapter 2. For the MAC address 0005.73A0.0001, the interface ID is 00-05-73-FF-FE-A0-00-01, and the IPv6 link-local address is FE80::5:73FF:FEA0:1. Note that the U/L it is set to 0, indicating local significance.

Periodic RAs are sent for the HSRP virtual IPv6 link-local address when the HSRP group is active. These RAs stop after a final RA is sent when the group leaves the active state. No restrictions occur for the interface IPv6 link-local address other than that mentioned for the RAs. Other protocols continue to receive and send packets to this address.

In the case of IPv4, simple load sharing may be achieved by using two HSRP groups and configuring half the hosts with one virtual IP address and half the hosts with the other virtual IP address. In contrast, on IPv6 this happens by default. If there are two HSRP IPv6 groups on a link, the hosts learn of both through IPv6 ND RA messages. They are either multicast periodically, or solicited by hosts. Then a host chooses to use onedepending on the IPv6 stack implementationsuch that the load is shared among the advertised routers. Typically, a host may use a round-robin scheme to decide which to use from the list of learned routers.

Cisco HSRP is an efficient mechanism designed to provide high availability of first-hop routers for IPv6 hosts. It is therefore decided that on AC LANs, when several routers are available on a given links for IPv6 hosts, HSRP for IPv6 will be configured as shown in Figure 15-7.

Example 15-15 shows a configuration for routers R1 and R2 that requires a Cisco IOS Release 12.4(4)T as minimum:

Example 15-15. Cisco HSRP for IPv6 Configuration

Router R1 R1# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High standby version 2 standby 0 ipv6 autoconfig ! R1# Router R2 R2# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High standby version 2 standby 0 ipv6 autoconfig ! R2#

To verify the HSRP activation, the show standby command can be used, as shown in Example 15-16.

Example 15-16. Display of Cisco HSRP for IPv6 Setup

Router R1 R1#show standby Ethernet0/0 - Group 0 (version 2) State is Standby 1 state change, last state change 1d23h Virtual IP address is FE80::5:73FF:FEA0:0 Active virtual MAC address is 0005.73a0.0000 Local virtual MAC address is 0005.73a0.0000 (v2 IPv6 default) Hello time 3 sec, hold time 10 sec Next hello sent in 1.436 secs Preemption disabled Active router is FE80::A8BB:CCFF:FE00:6900, priority 100 (expires in 8.048 sec) MAC address is aabb.cc00.6900 Standby router is local Priority 100 (default 100) IP redundancy name is "hsrp-Et0/0-0" (default) R1# Router R2 R2#show standby Ethernet0/0 - Group 0 (version 2) State is Active 2 state changes, last state change 1d23h Virtual IP address is FE80::5:73FF:FEA0:0 Active virtual MAC address is 0005.73a0.0000 Local virtual MAC address is 0005.73a0.0000 (v2 IPv6 default) Hello time 3 sec, hold time 10 sec Next hello sent in 2.872 secs Preemption disabled Active router is local Standby router is FE80::A8BB:CCFF:FE00:6600, priority 100 (expires in 7.540 sec) Priority 100 (default 100) IP redundancy name is "hsrp-Et0/0-0" (default)

Network managers may want to configure another FHRP protocol to achieve a similar behavior. On Cisco IOS implementations, alternatives are either VRRP, if interoperability with other vendors' routers is required, or Cisco GLBP, when multiple upstream paths are available to improve performance by facilitating better use of network resources. Then, additional configuration options, such as Enhanced Object Tracking, can be turned on when available for IPv6.

Securing the IPv6 Deployment

As extensively described in Chapter 9, IPv6 security is a mix of challenges, both those that are IPv4 similar and potentially new challenges. By default, IPv4 security policies will be applied to IPv6 as well on the AC intranet. The IPv6 deployment will also benefit from all the underlying security mechanisms already in place for IPv4 (for example, AC has already secured the layer 2 access of its network with the wireless infrastructure).

Products currently deployed as IPv4 firewalls have to be upgraded to a software release supporting IPv6. When not possible, the upgrade of the current hardware to a new generation of firewall with IPv6 support must be planned. The IPv4 configuration of the firewalls has to be updated to block uncontrolled IPv6 over IPv4 tunnels from being set up across the AC network perimeter. Devices performing intrusion detection system (IDS) functions should also be evaluated for an immediate upgrade to IPv6 support.

The IPv6-specific security guidelines outlined in Chapter 9 are also formalized and implemented by the operation team in the AC network. With regard to security challenges raised by the new services deployed over IPv6, multicast and Mobile IP have to be addressed. The most important aspects of securing the multicast service relate to multicast domain management. The control and data multicast traffic has to be contained at the boundaries and blocked from entering the network. The RPs have to also be protected against possible DDoS. For the experimental deployment of MIPv6, an extended ACL will be edited to filter on the routing header Type field, permitting type = 2 (MIPv6) and denying type = 0 (source route) as available on Cisco IOS Release 12.4(2)T. See Chapter 9 for configuration details.

The Cisco 2821 router configured as an ISATAP router in the initial trial will be kept up and running, adding IPv6 connectivity to the Cisco VPN Client usersnot be confused with the VPN tunnels configured on broadband access routers located at remote sites.

Multicast

On the AC intranet, IPv4 multicast is an experimental service. It started a couple of months ago to stream audio and video files from headquarters to the rest of the world for scheduled training on new AC products and services as well as internal management broadcasts. In reality, the IPv4-based service is supported only at a limited number of locations (because of its operational challenges). The service trial shows it to be too complex to manage IPv4 multicast across the NAT/PAT devices. AC expects to decrease the cost of operations for the service by running it over IPv6. The same commercial applications as in the case of IPv4 multicast are already available, so it is now a matter of network support.

The first applications of the multicast service revolve around content distribution that would be well supported by a Source Specific Multicast (SSM) model. However, AC plans to roll out collaborative applications, which means the multicast sources might not always be located in the AC's data centers and with a well-known address. For this reason, AC opted for an Any Source Multicast (ASM) multicast design.

To avoid the transport of delay/jitter-sensitive traffic across large distances and over expensive circuits, AC's worldwide network is segmented into three areas, which represent independent multicast domains. This approach also provides the three regions with a certain level of independence that allows them to tailor content to the respective markets. Each domain is outfitted with content servers at a headquarters location as described in Table 15-6. It was also decided not to support the multicast traffic of other applications in crossing the boundaries of these domains.

Table 15-6. Multicast Server Distribution in AC's Network

Region	Served by Multimedia Server
Africa and Middle East	Paris
Asia-Pacific	Hong Kong
Europe	Paris
Latin and Central America	San Francisco
North America	San Francisco

For content-distribution purposes, two streaming servers are located per data center in the San Francisco, Paris, and Hong Kong headquarters. Content is actually created in San Francisco and then distributed to the other two locations over night. Each data center is responsible to stream the multimedia content in its respective region.

The service in each region will be similarly designed and will follow the guidelines and examples shown in Chapter 6, "Providing IPv6 Multicast Services." It will also rely on the existent IPv6 IGP for routing information and RPF calculation. The following protocols are used to support the multicast service:

• PIM Sparse Mode (PIM-SM) on routers and layer 3 switches. It starts running automatically when the network element is enabled to support multicast through the global command ipv6 multicast-routing.

• The Rendezvous Point (RP) mapping to the multicast group addresses is a key aspect in shaping the service design. The independent domain approach chosen for this deployment would warrant an elegant and dynamic solution based on BSR as described in Chapter 6. The concern, however, is with the multiple remote locations present within each multicast domain that connect to the main campuses over smaller bandwidth pipes and use lower-end network elements with limited resources. To limit the impact of BSR flooding and the state maintained for it, AC decided to select an embedded RP approach.

• Although MLDv2 is supported by default on the Cisco routers, at the time of planning the deployment most stacks actually support only MLDv1. AC decided to use both at its access layer.

• To optimize the use of resources for multicast forwarding, MLD snooping is turned on by default on all layer 2 switches deployed on AC LANs. This policy refers in particular to the Cisco Catalyst 6500 with supervisor engine 720 and Catalyst 3750 or 3560 series installed on all sites. The feature is enabled with the global configuration command ipv6 mld snooping.

The servers acting as sources for the multicasted content are located in the data centers of the three local headquarters serving each region. A prefix is allocated for these multicast resources in each data center, and it is identified by convention through bits 57 through 64 of the IPv6 address being set as DD:

• San Francisco: 2001:DB8:ACAC:00DD::/64

• Paris: 2001:DB8:ACAC:24DD::/64

• Hong Kong: 2001:DB8:ACAC:80DD::/64

The two gateways serving the server segment are set to be the RPs for the multicast groups used in that domain. A second prefix is used to identify these RPs. For this prefix, bits 57 through 64 are set to DF. The loopback interfaces of the RPs are assigned this prefix with the interface ID set as ::F. In the case of an embedded RP-based deployment, the multicast group addresses derive from the RP unicast address, as described in Chapter 6. Table 15-7 summarizes the prefixes relevant to the multicast service.

Table 15-7. Prefixes Used with the Multicast Service

Region	Multicast Servers	RP	Multicast Groups
San Francisco: -North America -Latin and Central America	2001:DB8:ACAC:00DD::/64	2001:DB8:ACAC:DF::F/128 2001:DB8:ACAC:DF::F/127	FF75:F40:2001:DB8:ACAC:DF:G -Where G is the 32 bits group ID
Paris: -Africa and Middle East -Europe	2001:DB8:ACAC:24DD::/64	2001:DB8:ACAC:24DF::F/128 2001:DB8:ACAC:24DF::F/127	FF75:F40:2001:DB8:ACAC:24DF:G -Where G is the 32 bits group ID
Hong Kong: -Asia-Pacific	2001:DB8:ACAC:80DD::/64	2001:DB8:ACAC:80DF::F/128 2001:DB8:ACAC:80DF::F/127	FF75:F40:2001:DB8:ACAC:80DF:G -Where G is the 32 bits group ID

Example 15-17 shows the relevant configuration of the RP router in the San Francisco data center.

Example 15-17. IPv6 Multicast Configuration

RP-1# ipv6 multicast-routing ! ipv6 pim rp-address 2001:DB8:ACAC:DF::F ! interface Loopback0 no ip address ipv6 address 2001:DB8:ACAC:DF::F/128 ipv6 enable !

The two segment gateways provide a certain level of redundancy for the RP functionality. The primary RP has the loopback address configured with the longer prefix /128, whereas the backup has its configured with the same address but the /127 prefix length. This means that as long as the primary is active, the longer prefix match will send all the PIM traffic to it. If it fails, the IGP will redirect it to its backup.

An important aspect of implementing the multicast design described is the multicast domain control. All types of multicast traffic, other than that with link-local scope, have to be blocked from traversing the border between AC's network and the IPv6 Internet. Moreover, to enforce the rules defined for the content services, the FF75:: multicast traffic has to be stopped from crossing the border between the three domains identified. The domain control is implemented with the help of eACLS on the relevant WAN routers. This can be easily done considering the well-defined scope and structure of the multicast addresses used.

The troubleshooting steps described in Chapter 6 can be used in the case of this deployment. This embedded-RP design simplifies significantly to service, making its support much easier than the alternative BSR-based design.

Network Management

A complex aspect of running a dual-stack network is its management. Hopefully, the new IP version is an addition to existent IPv4 services on the AC intranet so that there is no need to natively manage the equipment over an IPv6 network layer. Nevertheless, the NMS is upgraded to dual stack as well and configured with a manual IPv6 address to follow AC addressing rules. Other steps to update the management infrastructure to support IPv6 include the following:

• Releases of HP OpenView and Cisco Network Management applications are upgraded to the most recent versions, which include IPv6 applications as described in Chapter 10, "Managing IPv6 Networks."

• Additional scripts are written to handle IPv6 configurations on networking devices.

• The user-tracking application available from Cisco LMS 2.5 is leveraged to monitor the hosts configured with "privacy extension" addresses.

• Network Analyzer modules already deployed in AC's network will be updated to handle IPv6 protocols.

Overall, the NM policies and procedures have to be updated to reflect the specificities of IPv6.

Mobility

One of AC management's expectations about the integration of IPv6 is the deployment of new appliances supported through IP mobility. New generations of smart phones and PDAs, allocated to employees enabled with various wireless access technologies, should provide easy access intranet resources. The recent development of mobile router, such as Cisco MAR 3200, would also enable the AC fleet of vehicles to stay connected while being outfitted with a multitude of data collection and data delivery devices. Applications such as video security, maintenance, and tracking represent an opportunity to optimize resources. Because the implementations are still in their infancy, the AC IT team will begin an experimental service to learn the technology and validate the design.

In the beginning, only the San Francisco headquarters will be configured for MIPv6. If the experiment is deemed successful, the service will be expanded to other regional headquarters. Minimum steps to be achieved include the following:

• A new Ethernet segment is created on the DMZ that represents the MIPv6 home network.

• An IPv6 prefix, 2001:0DB8:ACAC:00FF::/64, is assigned to this segment.

• A Cisco 2821 router running Cisco IOS Release 12.4(2)T is configured, as shown in Example 15-18, as MIPv6 home agent for the experiment. See Chapter 8, "Advanced ServicesIPv6 Mobility," for details about the MIPv6 protocol.

  Examble 15-18. Router MIPv6 Home Agent Basic Setup

  MIPv6# ipv6 mobile home-agent ! interface GigabitEthernet0/0 ip address 10.151.1.7 255.255.255.0 ipv6 address 2001:0DB8:ACAC:00FF::/64 EUI-64 ipv6 mobile home-agent preference 1 ipv6 mobile home-agent ! Checking the Mobile IPv6 Home Agent availability MIPv6#show ipv6 mobile home-agents Home Agent information for GigabitEthernet0/0 Configured: FE80::20F:35FF:FE2D:38C9 preference 1 lifetime 1800 global address 2001:0DB8:ACAC:00FF:20F:35FF:FE2D:38C9/64 No Discovered Home Agents MIPv6#show ipv6 mobile globals Mobile IPv6 Global Settings: 1 Home Agent service on following interfaces: GigabitEthernet0/0 Bindings: Maximum number is unlimited. 1 bindings are in use 1 bindings peak Binding lifetime permitted is 262140 seconds Recommended refresh time is 300 seconds

• A laptop with WiFi and 3G interfaces loaded with Microsoft Windows XP SP1 and Mobile IPv6 technology preview acts as Mobile Node. Example 15-19 are the commands and displays from the Windows MIPv6 client.

Example 15-19. Microsoft Windows XP MIPv6 Client Technology Preview Configuration

Disabling IPSec authentication as it is not yet supported on Cisco IOS for Mobile IPv6 C:\> ipv6 gpu MIPv6Security off Manual HA Configuration C:\> ipv6 hau <HoA> <HA> C:\>ipv6 hau 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 Display MIPv6 Home Agent configuration C:\>ipv6 ha Home Address: 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c Home Agent: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 ESPTunnelSPI: 0 ESPTunnelSPD: 0 C:\> Display MIPv6 Binding Updates C:\> ipv6 bu Home Address: 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c Host: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 CoA : 6/2006:1::20c:29ff:feb9:8d7c Expires : 47s Comments : HOME_AGENT RRState : NO_RR ACTIVE

The purpose of the test is to enable the Mobile Node to reach its home network either from any internal AC subnet or any external location. Example 15-20 shows a Ping6 when the Mobile Node is away from its home network sent toward a node sitting on the home network shown in Figure 15-8.

Example 15-20. MIPv6 Testing

Ping6 command C:\> ping6 -t 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b Pinging 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b from 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c with 32 bytes of data: Reply from 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b bytes=32 time=137ms Reply from 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b bytes=32 time=137ms Ping statistics for 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 119ms, Maximum = 137ms, Average = 128ms Ctrl+C C:\> Display of MIPv6 Binding Cache during ping6 C:\> ipv6 bc Home Address: 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c Host: 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b CoA : 6/2006:1::20c:29ff:feb9:8d7c Expires : 27s BU_Rexmits : 2 RRState : AWAIT_ACK SEND_BU Host: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 CoA : 6/2006:1::20c:29ff:feb9:8d7c Expires : 39s Comments : HOME_AGENT RRState : NO_RR ACTIVE

Figure 15-8. Mobile IPv6 Test Bed

[View full size image]

This section gave a basic example of IP mobility configuration. Real production deployment with a large number of devices will present more challenges than a single mobile-node test. AC will continue the experimentation with more complex settings and challenges, such as the following:

• Adding multiple mobile nodes with various implementations of MIPv6 for a large-scale evaluation: Microsoft Mobile PC 2003 and its Mobile IPv6 Technology Preview and Linux MIPv6.

• Adding a Mobile RouterCisco MAR 3200as MIPv6 client. An IPv6 video camera will be attached to one of the MAR 3200 Ethernet interfaces to demonstrate video surveillance in a truck.

• At the time of writing, MIPv6 implementation on Cisco IOS does not include an authentication mechanism such as IPsec or Light Authentication. This will be validated when available on a commercial Cisco IOS release. Note that Microsoft Mobile IPv6 Technology Preview allows disabling the IPsec authentication.

• Security rules to protect the AC intranet from attacks when IP mobility is a production service. To begin with, extended ACLs to differentiate routing option header type 2 (MIPv6) from type 0 (source routing) are set on access routers.

Although there is still a long way to go before running an IP mobility production service, this represents a strong opportunity for innovation, helping AC to keep its technology leadership with its market through improved processes.

QoS

As discussed in Chapter 5, "Implementing QoS," the architectural model is similar between IPv4 and IPv6. The initial QoS setup on the AC network was done to guarantee the bandwidth of the IP telephony traffic and limit the throughput of the experimental IPv4 multicast traffic over the WAN links. Packets sent over both versions of IP consume the same resources, meaning that if one application is considered mission critical, its traffic has to be protected whatever the network layer version. With the assumption in mind that applications should be protocol agnostic, the AC network team decided that all QoS rules must be applied the same way to both versions of IP. This eases the integration of IPv6-capable applications because no further action is needed after the QoS rules are set for IPv4 (as long as IPv6 QoS is supported on routers and switches).

QoS is really an internal service for the AC intranet. It was defined to guarantee the bandwidth of IP telephony and control the throughput of multicast streams in locations where it was enabled. Class of service (CoS) definition has been limited to a minimum, as follows:

• All traffic DSCP=0

  This should be the default for all traffic except as indicated below. Traffic flowing from and to the Internet is re-marked on the AC edge router with DSCP=0.

• IP telephony DSCP=5

  This is reserved to the IP telephony traffic. This is the original QoS value set by the IP phones and must be preserved through the intranet.

• Management traffic DSCP=7

  The default value is intact for the network management traffic, (for example, routing protocol) that generates by default packets with such a value.

On Cisco IOS routers supporting IPv6 QoS through the Modular QoS CLI (MQC), the default action for QoS is to apply the same rules for both IPv4 and IPv6.

On AC LANs, the IP QoS to 802.1Q/p CoS correspondence is enabled to guarantee the bandwidth of the IP telephony. On Catalyst 6500 running Cisco IOS Release 12.2(18)SXE and higher, the correspondence between IPv6 Traffic Class field and 802.1Q CoS is supported for all CEF switched packets.

See Chapter 5 for a more detailed discussion about IPv6 QoS and its configuration.