Deploying IPv6 Routing Protocols

One simple conclusion that can be drawn from the information presented in this chapter so far is that the implementation and operation of the IPv6 RPs are similar to their IPv4 counterparts. This means that as far as routing is concerned, all design rules and strategies used in deploying IPv4 networks apply to IPv6. The approach has to be hierarchical and it has to observe the specifics of each layer of the network: core, distribution/edge, and access.

Network Core

The network core is highly redundant to ensure uninterrupted service. The routing protocols deployed in the core have to leverage the infrastructure by providing fast reconvergence around failures. The traffic should be load balanced across the redundant, equal-cost paths.

The following IGPs are suitable for the network core:

• EIGRPIt is commonly used in enterprise networks. It could be used in the core of ISP networks, but to date has not been.

• OSPFIt is a scalable and fast-converging option that is commonly used in the core of both enterprise and ISP networks. It could be deployed in single or multiple areas, but it will impose topological constraints.

• IS-ISIt is commonly used in ISP networks and rarely in enterprise networks. Almost always, it is deployed in a single-area (level 2) design.

Note

Because it is expected that traffic engineering (TE) will be considered in IPv6 MPLS networks, it is important to remember that TE requires IS-IS or OSPF.

One of the main design concerns is the scale of the network in terms of number of nodes. OSPF topologies are limited by the network and router LSA size. IS-IS topologies are limited by the LSP count. In a well-designed network, these scalability limitations should not be encountered. If the same RP is used across the distribution/edge layer, however, OSPF should be using multiple areas (whereas IS-IS scales comfortably with its flat design). It is important to make sure that the distribution/edge layer is injecting a small number of prefixes in the core RPs, thus ensuring stability and rapid reconvergence.

IPv4 and IPv6 are expected to coexist in networks for a long time. This implies the coexistence of at least two RPs that have to be managed by the network operator and by the network devices. Some operators might not be willing to take on this task and prefer to minimize this impact of deploying IPv6 services. From this point of view, you have two options to consider:

• If the IPv6 topology can be identical with the IPv4 one in a dual-stack deployment, ISISv6 in single-topology mode addresses the manageability and resource duplication concerns.

• When tunneling (transition tunnels or 6PE) is used as an overlay to provide transport for IPv6 traffic, the IPv6 RP is not a concern for the IPv4 core. Inside the IPv6 network, iBGP running on edge routers (see the following section) can be used to exchange the IPv6 routing information, too. This implies the use of a single, already running RP for both IPv4 and IPv6.

In both of these cases, the operator will have to run a familiar protocol while saving router resources at the cost of some topology constraints. As the significance and amount of IPv6 traffic increases, the RP design of the network might need to be revisited to address new requirements.

Network Distribution/Edge

This network layer provides the interface between the access and the core layers. It also provides the interface with external networks. At this layer, IGPs are used alongside BGP.

The same IGPs recommended for the core are suitable for the distribution/edge layer, too. In fact, the same RP often times covers both network layers. If the protocol used is OSPF, a hierarchical approach is suggested with the core in the backbone area and the distribution/edge split in multiple areas. IS-IS and EIGRP extend flatly over this layer.

BGP is also deployed at this network layer. iBGP is used between distribution/edge routers for the following reasons:

• Tie up eBGP speakers together by propagating BGP-specific attributes (NEXTHOP, AS_PATH) across the core

• Avoid overloading the core with routing information that is not relevant to it that could impact its convergence time

• Exchange information with customers without having to expose the underlying IGP to the customer network complexities and instabilities

• Enable services such as VPNs or 6PE

The iBGP is deployed in a full mesh realized with the help of route reflectors, confederations, or by fully meshing all the participating routers.

eBGP is used in the following deployment cases:

• To exchange routing information between domains within large service provider or enterprise networks designed with multiple autonomous systems.

• To exchange routing information with external networks. It enables the use of policies and aggregation.

• To enable services such as "Carrier supporting Carrier" (CsC), which allow an ISP to be a transit for other ISPs.

Similar to IPv4 deployments, iBGP should be synchronized with the underlying IGP but, for scalability reasons, prefixes should not be distributed between them.

Network Access

The devices in the access layer are exposed to multiple users, but they tend to have less processing power than the ones in the other network layers. Moreover, because of IPv6 address assignment guidelines, it is likely that these devices will be exposed to large numbers of prefixes in the /64 to /48 range. For these reasons, complex and process-intensive RPs are not deployed in this network layer.

Although OSPF is used at the access layer, simpler routing protocols such as RIPng or EIGRP are sometimes favored. Static routing is also used actively. Static routes are manually configured or are dynamically installed during the address-assignment process (as is the case of DHCP-PD). The redistribution of static routes is common in this part of the network. Summarization is also an important aspect of the routing design. The upstream layers should be presented with a smaller number of prefixes to preserve resource in the aggregation nodes.