IPv6 over the Backbone

The backbone network can be defined as the network portion of the communication system that provides aggregation, interconnection, and transfer between network accesses defined in the "IPv6 Network Access" section.

In a simple case, the backbone network is a single ISP infrastructure. Considering the complexity of the Internet, the backbone network is a combination of enterprises and ISP networks. In a typical topology, the backbone starts at the enterprise and spreads over several ISPs.

Note that although some of the methods for transporting IPv6 customer traffic over the backbone assume that the backbone itself supports IPv6, others envision the case where it does not. In that context, the transitioning and coexistence mechanisms are of primary importance.

There are basically three different approaches for deploying IPv6 over the backbone:

• Dual-stack routers and links IPv4 and IPv6 share the same link layer, and core routers run both IPv4 and IPv6 stacks.

• IPv6 (and IPv4) uses a separate link layer Some service provider backbones are simply using a layer 2 technology such as Frame Relay, ATM or Packet over SONET (PoS) to transport IPv4 traffic between edge routers. To establish IPv6 connectivity, routers attached to the ISP WAN or MANs can use the same layer 2 infrastructure as IPv4, but over separate ATM or Frame Relay PVCs, or over different optical lambda. Layer 2 links are terminated at the Internet exchange point or on the autonomous system boundaries where IPv6 (or dual-stack) routers handle layer 3 connectivity to the Internet or other ISPs.

• IPv6 on the edges, and tunnels to traverse the backbone

The long-term objectivesfor instance, deploy some IPv6 service (for an enterprise), offer an IPv6 access (for the ISP), transition from IPv4 to IPv6should drive tactical as well strategic choices. In the most likely scenarios, where IPv4-based networks are dominant in the backbone, tactical choices will typically deal with tunnel deployments, whereas dual-stack backbones will be seen as the long-term strategy. Tunnels tend to be initially cheaper to deploy because they deal with a subset of the backbone nodes. On the dark side, they deliver suboptimal paths in most cases while causing packet overhead (in the form of an extra header). Tunnels also carry some configuration and management overhead, which grows with the number of tunnels, getting to a crossing point where it becomes more cost-effective to migrate to dual-stack backbone.

When tunnel mechanisms are used to transport IPv6 traffic over the backbone, tunnel endpoints can always be set up between edge-router pairs (PE) or between customer-router pairs (CE).

Networks where a layer 2 transport technology or MPLS have been already deployed may keep IPv6 on the edge for a long time.

IPv6 connectivity across the backbone can be set up with multiple segments managed independently, using a variety of IPv6 transport mechanisms. For instance, the enterprise could decide to deploy a dual-stack network, and be attached to an MPLS ISP providing native IPv6 access through 6PE, itself connected to a second ISP providing IPv6 over IPv4 tunnels. The IPv6 traffic across the backbone will follow these network segments, so the mechanisms reviewed hereafter become building blocks assembled to enable IPv6 connectivity end to end. Although a particular enterprise or ISP will make its own choices and set up its own strategy for transporting IPv6 traffic, it will also have to deal with choices and strategies of other networks with which it is peering.

Native IPv6

The backbone network can provide the IPv6 connectivity by enabling IPv6 on all routers and the links interconnecting them. In theory, nothing prevents the backbone from being IPv6 only, but it remains likely that an existing IPv4 network will coexist with the IPv6 network. You have several strategies to choose from when deploying the IPv6 network:

• Upgrade all existing routers to dual stack, and set up the network to provide IPv6 connectivity.

• Upgrade a subset of the existing routers to dual stack, establish IPv6 dedicated circuits between them, and set up the IPv6 network as an overlay network on top of the IPv4 network. The circuits can be ATM or Frame Relay, using PVCs or SVCs.

• Build an IPv6 network as a parallel network to the existing IPv4 network. This scenario includes the case where an IPv6 network is built from scratch, without considerations on transition or coexistence.

In all of these cases, the IPv6 topology is likely to be different from the IPv4 topology. The IPv6 routers need to be configured with routing protocols, interface addresses, ACLs, QoS, and so on. Chapter 4, "IPv6 Routing Protocols," discusses routing protocols, but the extra configuration and operation costs of running two sets of routing protocols in the backbone are worth mentioning in the dual-stack approach.

Although the dual-stack approach carries twice the complexity of single stack, it appears to be the natural choice in the long run. It is the only one that allows separating at the finest level IPv4 and IPv6 topologies and services in the core. It is also the only approach that does not have to worry about traversing NATs (when leaving the enterprise boundaries), and it can support IPv6 multicast properly.

However, before investing in a dual-stack deployment throughout the backbone, remember that tunneling mechanisms offer a reasonable intermediary step. Many tunneling mechanisms exist, and they are covered throughout the remainder of this chapter. You should see, however, that dual-stack deployments do not compete with tunneling; instead, they complement each other during the transitioning period.

IPv6 over IPv4 Tunnels

When the backbone network does not support IPv6, some tunneling mechanism is required. IPv6 over IPv4 tunnels encapsulates IPv6 traffic into IPv4 packets to traverse the IPv4 backbone. Many tunneling mechanisms are available for deploying IPv6: They differ by the location of the tunnel endpoints and the way these endpoints are determined. All of them, however, require the tunnel endpoints to be dual stack. Two tunnel mechanisms have started to emerge in the context of an IPv4-only backbone: MCTs, among which IPv6 over IPv4 GRE tunnel is one; and automatic tunnels, in particular 6 to 4 tunnels. Other tunneling mechanisms, typically deployed on hosts, are discussed in the "IPv6 Network Access" section.

IPv6 over GRE

IPv6 over Generic Routing Encapsulation (GRE) tunnels represent another type of MCT; the first example of such was introduced in the "IPv6 Network Access" section. It enables IPv6 traffic forwarding over an existing IPv4 infrastructure, with minimum changes. Tunnel endpoints can be set up between provider edges. The tunnel endpoints are dual-stack routers, which encapsulate IPv6 traffic into IPv4, with both tunnel source and destination configured manually for GRE. Tunnels over GRE, specified in RFC 2473 and RFC 1701, have an extra encapsulation header (GRE header), with the protocol type of the encapsulated protocol (0x86DD for IPv6). This enables protocols other than IP to share the same tunnel (for instance, IS-IS) running over a layer 2 data link.

Figure 3-13 shows an example of an IPv6 over GRE tunnel.

Figure 3-13. GRE Tunnel

[View full size image]

GRE tunnels are point-to-point tunnels. The number of tunnels needed for the service grows with the number of endpoints, making them difficult to scale. This is a typical problem with manual tunneling mechanisms, and for this reason they are usually used just to interconnect a few sites.

6to4

6to4 is an automatic tunneling mechanism, specified in RFC 3056. It enables isolated IPv6 islands, using the 6to4 addressing plan, to interconnect over an IPv4-only backbone at minimum configuration costs. In particular, the tunnel destination is not explicitly configured as in other tunneling mechanisms, but obtained dynamically from the IPv4 address embedded in the destination IPv6 address of the packet. Figure 3-14 shows a 6to4 configuration.

Figure 3-14. 6to4 Tunnel

[View full size image]

Two deployment scenarios are possible. In the simple case, two or more IPv6 sites need to interconnect over an IPv4 backbone. Each site is configured with a 2002:V4ADDR::/48 prefix, where V4ADDR is a unique IPv4 address for the site.

For instance, in Figure 3-14, Site1 is allocated the prefix 2002:C80F:F01::/48, and Site2 has 2002:C80B:B01::/48. The embedded IPv4 address C80F:F01 (200.15.15.1) is the IPv4 address for Site1. IPv4 prefixes (200.15.15/24, for instance) are distributed by an IPv4 routing protocol running in the IPv4 backbone. When HostA sends traffic to HostB (destination 2002:C80B:B01:100::1), it is routed via the 6to4 Router1. This router has a 6to4 tunnel configured, with a tunnel source (200.15.15.1) but no tunnel destination. The tunnel destination is computed on-the-fly by extracting the embedded IPV4ADDR from the destination address (2002:C80B:B01:100::1/64, and used to encapsulate the IPv6 packet into IPv4 (source 200.15.15.1, destination 200.11.11.1). The reverse path is symmetrical. Example 3-21 highlights the relevant configuration for Router1 and Router2.

Example 3-21. Configuration of 6to4 Routers in Figure 3-14

Router1 interface Tunnel2002 ipv6 address 2002:C80F:F01::1/128 tunnel source Ethermet0/0 tunnel mode ipv6ip 6to4 ! interface Ethernet0/0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet1/0 ipv6 address 2002:C80F:F01:100::2/64 ! ipv6 route 2002::/16 Tunnel2002 !route to native IPv6 service ipv6 route ::/0 2002:C058:6301::1 Router 2 interface Tunnel2002 ipv6 address 2002:C80B:B01::1/128 tunnel source Ethernet0/0 tunnel mode ipv6ip 6to4 ! interface Ethernet0/0 ip address 200.11.11.1 255.255.255.0 ! interface Ethernet1/0 ipv6 address 2002:C80B:B01:100::2/64 ! ipv6 route 2002::/16 Tunnel2002 !route to native IPv6 service ipv6 route ::/0 2002:C058:6301::1

The second possible scenario is that of a 6to4 site that needs to access global, native IPv6 resources (2001::/16 Internet resources or 3FFE::/16 6bone resources, for instance). On the way out (from Site1 to the IPv6 backbone), traffic is routed into the 6to4 tunnel (for instance, using a default route ipv6 route ::/0 2002:C058:6301::1). This route provides the IPv4 tunnel destination (192.88.99.1). A dual-stack router on the boundary between the IPv4 network and the native IPv6 domain, namely a 6to4 relay, removes the IPv4 header and forwards the IPv6 packet natively. In the other direction, the 6to4 relay uses the destination (HostA 2002:C80F:F01:100::1, for instance) to determine the tunnel endpoint and impose the IPv4 header.

The configuration of the 6to4 Relay router in Figure 3-14 contains no specific elements for the 6to4 routers, as shown in Example 3-22.

Example 3-22. Configuration of 6to4 Relay Router

6to4-relay interface Tunnel2002 no ip address ipv6 address 2002:C80A:A01::1/128 tunnel source Loopback0 tunnel mode ipv6ip 6to4

Therefore, a 6to4 router willing to access a service hosted in an IPv6 native network behind the 6to4 relay will not require any configuration upgrade from the 6to4 relay.

Instead of using a default route to the 6to4 relay, the 6to4 router could peer with it using external Border Gateway Protocol (eBGP), address family IPv6 (see Chapter 4). The BGP configuration of eBGP peering with the 6to4 relay in Figure 3-14 is shown in Example 3-23.

Example 3-23. BGP Configuration for Peering with the 6to4 Relay

router bgp 100 neighbor 2002:C80A:A01::1 remote-as 200 neighbor 2002:C80A:A01::1 ebgp-multihop 255 ! address-family ipv6 neighbor 2002:C80A:A01::1 activate

Although this model allows for a more granular routing policy, it requires the BGP configuration of the 6to4 relay to be modified for each 6to4 peer. This would not be a scalable deployment approach. BGP peering should be reserved for 6to4 routers providing access to large sites.

With the promulgation of RFC 3068, 6to4 routers can use the anycast address 2002:C058:6301:: for their default 6to4 router to get to the nearest (in BGP terms) 6to4 relay router. This assumes that BGP (address family IPv4) is advertising 192.88.99/24, and it saves for each 6to4 router the need to find out by itself the address of the nearest 6to4 relay router.

The 6to4 transition mechanism has some advantages over manual tunnels. IPv4 tunnel endpoints do not have to be advertised: The IPv6 sites can get the address of the endpoints through a name-to-address lookup performed by a Domain Name Server (DNS). The tunnels are stateless, not consuming resources like manual tunnels do. Finally, after the 6to4 relays have been set up, no extra configuration is required to provide 6to4 sites with connectivity to a wide-area IPv6 routing infrastructure, such as the 6bone. They also have some disadvantages:

• The underlying IPv4 address determines the enterprise 6to4 IPv6 address prefix, so the migration to native IPv6 requires renumbering the network.

• When hosts within the 6to4 site have multiple addresses (6to4 and native) to select from, they must select their 6to4 address; otherwise, the 6to4 relay cannot dynamically figure out the endpoint of the tunnel.

  Note

  Rule 8 in RFC 3484, "Use longest matching prefix," seems to suggest otherwise.

  
  

• They are limited to static or BGP4+ routing.

IPv6 over MPLS

MPLS is an infrastructure technology deployed by ISPs and large enterprises to implement services such as virtual private networks (VPN), traffic engineering (TE), quality of service (QoS), and fast convergence. ISPs and enterprises that have selected the technology may view the integration of IPv6 services over an MPLS infrastructure as a normal evolution. For those unfamiliar with MPLS terminology, a PE is a provider edge router, and a CE is a customer edge router. A packet enters the MPLS backbone at the ingress PE and is label switched up to the egress PE. This mechanism uses what is known as a label switch path (LSP), set up by control-plane protocols such as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP). Refer to the book MPLS and VPN Architectures, by Ivan Pepelnjak and Jim Guichard, for detailed information on MPLS.

A motivation for deploying IPv6 transport capability over an MPLS backbone relates to the transitioning paradigm. MPLS stands for Multiprotocol Label Switching, and one would expect MPLS to be capable of transporting IPv4 or IPv6 datagrams seamlessly. Therefore, none or few changes would be expected to enhance an existing MPLS backbone, initially providing IPv4 connectivity, to transport IPv6 traffic: an attractive transitioning path for customers who have deployed an MPLS backbone, and want to enhance it to offer IPv6 connectivity at the edge.

In reality, this is partly true; although the label switch path is independent from the transported payload, two areas of the control plane are not, as noted here:

Several approaches are possible to offer IPv6 connectivity over the MPLS backbone. They differ from many standpoints: transitioning strategy, scalability, data overhead, and configuration. Table 3-3 below compares the different solutions.

Table 3-3. IPv6 over MPLS Mechanisms

Mechanism	Primary Use	Benefits	Limitations
IPv6 over a circuit transport over MPLS	Service provider with circuit to the CE (ATM, Ethernet, and so on)	Transparent to the service provider	Scalability
IPv6 over IPv4 tunnels over MPLS	Service provider willing to offer IPv6 service on top of an existing IPv4 MPLS service	Impact limited to PE	Tunnel overhead Configuration
IPv6 MPLS with IPv4-based core (6PE)	Service provider willing to offer IPv6 service on top of an existing IPv4 MPLS service	Impact limited to PE	Core unaware of IPv6; limitations in load balancing and troubleshooting (ICMP)
IPv6 MPLS with IPv6-based core	Service provider willing to offer MPLS services in an IPv6-only context	Full MPLS-IPv6 functionality	Impact on entire MPLS infrastructure Complexity if coexistence with an IPv4-MPLS service

IPv6 over a Layer 2 Circuit

While layer 3 mechanisms have a lot of advantages for connecting IPv6 over MPLS, they require mingling customer and service provider routing. However, some customers may just want connectivity (particularly at commodity pricing for connectivity without additional services). Using a layer 2 circuit to transport IPv6 traffic is an alternative solution to address this simple requirement, with no routing or any additional MPLS service.

Although layer 2 tunnels between CEs do not scale well in terms of number of tunnels (N²/2, where N is the number of CEs), they consume few resources at PEs and even less on Provider routers (P routers). When scaling is an issue because of the number of peers involved, you can implement a partial mesh of tunnels using hubs. However, doing so potentially leads to suboptimal routing, with traffic transiting the backbone twice or more. The layer 2 circuit can use Any Transport over MPLS (ATOM) or Ethernet over MPLS (EoMPLS). One advantage of this approach is that it has no configuration impact on any of the backbone boxes (including PE and P). The link between CEs is seen as a layer 2 link, running IPv6 Neighbor Discovery and any IPv6 routing protocol. The IPv6 traffic is tunneled over the MPLS backbone, as shown in Figure 3-15.

Figure 3-15. Ethernet over MPLS

[View full size image]

The relevant configuration of the routers in Figure 3-15 is shown in Example 3-24.

Example 3-24. Configuration of Routers in Figure 3-15

CE1 interface Ethernet0/0.10 encapsulation dot1Q 10 ip address 50.1.1.1 255.255.255.0 ipv6 address 2001:100::72A/64 PE1 interface Loopback0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet0/0.10 encapsulation dot1Q 10 xconnect 200.11.11.1 100 encapsulation mpls PE2 interface Loopback0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet0/0.10 encapsulation dot1Q 10 xconnect 200.10.10.1 100 encapsulation mpls CE2 interface Ethernet0/0.10 encapsulation dot1Q 10 ip address 50.1.1.2 255.255.255.0 ipv6 address 2001:100::72E/64

Note that this method may work well for a limited IPv6 deployment over a single ISP network. However, it is unlikely that two ISPs will interconnect using layer 2 links, making the approach unsuitable in environments where several ISPs have to be crossed by the IPv6 traffic. In an environment where the service provider already provides a layer 2 over MPLS service to transport IPv4 traffic, extending the service to IPv6 is low cost and straightforward.

IPv6 over an IPv4 Tunnel over MPLS

IPv6 over IPv4 over MPLS is one of these tunnel-in-tunnel methods that is quite easy to implement. After IPv4 connectivity between two PEs has been established, and an LSP set up between the PEs' IPv4 endpoints (using LDP combined with IS-IS, for instance), you can manually configure an IPv6 over IPv4 tunnel between these PEs using the same IPv4 endpoints. A routing protocol, such as MP-iBGP can then run over the tunnel to distribute IPv6 routes. From a transitioning or coexistence perspective, this solution has the advantage of requiring only the PEs to be dual stack. It has no impact on core MPLS routers.

In the forwarding plane, IPv6 traffic is encapsulated twicefirst into an IPv4 packet, and second into an MPLS frame. This double encapsulation, together with the extra configuration of the IPv6 over IPv4 tunnel, is the main drawback of the approach. Figure 3-16 illustrates a simple topology and relevant configuration to set up an IPv6 over IPv4 over MPLS LSP tunnel. Crossing SP boundaries with this approach is no different from doing it for VPNv4. The tunnel endpoints (IPv4 addresses) can be leaked between PEs, either by the IGP, or using MP-eBGP with label, which leads to an extra label in the label stack imposed at the ingress router (as described in RFC 2547bis, section 11, case c).

Figure 3-16. IPv6 over IPv4 over MPLS

[View full size image]

The relevant configuration of the PE routers in Figure 3-16 is shown in Example 3-25.

Example 3-25. Configuration of PE Routers in Figure 3-16

PE1 interface Loopback0 ip address 200.10.10.1 255.255.255.0 ! interface Tunnel100 ipv6 address 2001:100::1/64 tunnel source Loopback0 tunnel destination 200.11.11.1 tunnel mode ipv6ip ! router bgp 100 bgp log-neighbor-changes neighbor 2001:100::2 remote-as 100 ! address-family ipv6 neighbor 2001:100::2 activate PE2 interface Loopback0 ip address 200.11.11.1 255.255.255.0 ! interface Tunnel100 ipv6 address 2001:100::2/64 tunnel source Loopback0 tunnel destination 200.10.10.1 tunnel mode ipv6ip ! router bgp 100 bgp log-neighbor-changes neighbor 2001:100::1 remote-as 100 ! address-family ipv6 neighbor 2001:100::1 activate

IPv6 over 6PE

An IPv6 Provider Edge router (or 6PE) is an alternative solution to IPv6 over an IPv4 tunnel over MPLS. The goal of 6PE is to get the benefits of the IPv6 over IPv4 tunnel (no impact on core routers) while avoiding the tunnel overhead and the tunnel configuration.

6PE encompasses the following mechanisms:

• The setting of a LSP, which involves an IGP and a label distribution protocol

• The exchange of IPv6 routes between edge routers, which is generally performed by MP-BGP, and requires enabling of an IPv6 address family

• The MPLS forwarding mechanisms, based on label swapping and is independent of the payload

The key for leaving the core routers untouched (whether configuration wise, or software version wise) is to enable IPv6 traffic to be tunneled in LSPs set up with IPv4-based protocols. The LSP between edge routers can be used to transport any type of packets, including IPv6, providing that there exists some mechanism to associate the IPv6 path through the MPLS backbone with this LSP.

In the case of IPv6 over IPv4 over MPLS, this association is done via the tunnel endpoints, configured explicitly. In the case of 6PE, the association is controlled directly by MP-BGP, which correlates the next hop advertised with a given prefix with the LSP. The next hop is the IPv4-mapped IPv6 address (see the section "Special-Use Addresses" in Chapter 2 for details) built from the IPv4 address of the LSP tunnel endpoint. Figure 3-17 shows a simple 6PE topology.

Figure 3-17. 6PE Basic Topology

[View full size image]

The configuration in Example 3-26 illustrates how the LSP is associated with IPv6 paths.

Example 3-26. BGP Configuration for LSP-to-IPv6 Path Association

PE1 interface Loopback0 ip address 200.11.11.1 255.255.255.255 ! router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 ! address-family ipv6 neighbor 200.10.10.1 activate

An LSP is set up between 200.10.10.1 and 200.11.11.1, as shown in the forwarding entry details at PE1 (see Example 3-27).

Example 3-27. Forwarding Information on Router PE1 from Figure 3-17

PE1#show ip cef 200.10.10.1/32 det 200.10.10.1/32, epoch 0 local label info: global/17 nexthop 40.1.1.3 Ethernet1/0 label 17

Prefixes advertised by PE2 over MP-iBGP are reachable via the next hop 200.10.10.1, as shown in Example 3-28.

Example 3-28. Unicast Prefixes Learned by PE1 via MP-iBGP

PE1#show bgp ipv6 unicast Network Next Hop Metric LocPrf Weight Path *>i2001:200::/64 ::FFFF:200.10.10.1 0 100 0 300

The next hop (::FFFF:200.10.10.1) is the IPv4-mapped IPv6 address built from the IPv4 address of the LSP tunnel endpoint. It identifies the LSP to be used to reach the receive prefix (2001:200::/64), as shown in the forwarding table (Example 3-29).

Example 3-29. CEF Forwarding Table of Router PE1 in Figure 3-17

PE1#show ipv6 cef 2001:200::/64 details 2001:200::/64, epoch 0 recursive via 200.10.10.1 label 25 nexthop 40.1.1.3 Ethernet1/0 label 17

The exchange of IPv6 routes is performed with MP-iBGP, address family IPv6, using TCPv4 transport. (MP-BGP can operate indistinctly over an IPv6 or IPv4 transport.)

A careful reader may have noticed that a second label (label 25) appears in the forwarding entry for reaching a v6 prefix (2001:200::/64) over the LSP. In fact, the MPLS forwarding plane is not entirely independent from the payload. Here are the exceptions:

• At the penultimate hop, when penultimate hop popping (PHP) is enabled, and the label stack on the received packet is only one label, the MPLS forwarder is forwarding an IP packet.

• When multiple paths are available, the MPLS forwarder may hash the IP header to pick up one of those paths in a deterministic way and provide consistent load balancing.

• When an MPLS packet is undeliverable (for instance, because the label TTL [Time To Live] expired), the MPLS forwarder may need to send back an ICMP message to the source, which requires it to be IP-aware.

In these three cases, the MPLS forwarder requires some IP knowledge (and therefore some IPv6 knowledge when the payload is IPv6).

For the PHP, two options are possible. The first option is to disable PHP. Because the option is most generally configured at the box level, that would affect the IPv4 behavior and require some configuration change, including at the penultimate router (not a 6PE). The second option is to push a second label in the label stack, at the ingress edge router. The extra label guaranties that no router in the core, including the penultimate hop, will have to forward a nonlabeled packet (which means that the routers does not have to be capable of handling IPv6 packets). This second label is distributed by MP-iBGP, using the Subsequent Address Family (SAFI) label (value=4), as specified in RFC 3107. The following configuration example illustrates how to set it up.

Example 3-30. BGP Configuration of Router PE1 Exchanging Prefixes and Labels with PE2

PE1 router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 ! address-family ipv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-label

Note that on Cisco routers, the configuration of the SAFI "label" is required, to enable the IPv6 forwarder to use the MPLS LSP.

The MPLS forwarder also needs to be IPv6-aware for load balancing. Cisco routers are somewhat flexible in that regard; either the core router has been upgraded (software upgrade) with a recent version that is capable of hashing the IPv6 header and it will do so, or the hashing is performed on the bottom label.

The third potential issue in the forwarding plane arise when P-routers need to send an ICMPv6 message, upon receiving an undeliverable MPLS datagram. One easy way to get around that problem is to ignore it. The traceroute, executed between PEs or between CEs, is the most cumbersome method, because one would expect all nodes to respond. This can be hidden by using no mpls ip propagate-ttl at the PE (assuming fewer than 255 MPLS hops). If ICMPv6 support is a must for the service provider, P-routers must be upgraded with ICMPv6 support, and RFC 3032 (see section 2.3.2 in RFC 3032, or Chapter 7, "VPN IPv6 Architecture and Services") is used to provide P-routers with the capability to reach IPv6 nodes without any IPv6-forwarding capability.

Crossing multiple IPv4 autonomous systems is similar to IPv4 VPNs, as described in the update of RFC 2547 called RFC 2547bis. Three approaches are feasible:

• The two autonomous systems are connected over IPv6 links. The Autonomous System Boundary Routers (ASBRs) are both dual-stack 6PE routers that terminate the LSP in their respective autonomous system, and redistribute IPv6 routes to the other ASBRs using eBGP, address family IPv6. This approach is similar to scenario A, section 10, of RFC 2547bis.

• MPLS forwarding is enabled between ASBRs. Whether the link supports IPv4 or IPv6, a label can be advertised by eBGP (IPv6+label) on it so that an LSP end-to-end (from egress 6PE in one autonomous system to egress 6PE in the second autonomous system) is set up. The eBGP peer addresses between ASBRs determine the type of transport used (6PE if IPv4 addresses are used, native IPv6+label otherwise). This approach is similar to scenario b, section 10, of RFC 2547bis.

• 6PE peering is enabled directly across the two autonomous systems, usually via route reflectors. With route reflectors, IPv6 routes are neither maintained nor distributed by the ASBR routers, which do no need not be dual stack (can be IPv4 only). The ASBRs are required to leak labeled IPv4 /32 routes to the other autonomous system. This results in the creation of an IPv4 label switched path from the ingress 6PE router to the egress 6PE router, across autonomous system boundaries. This approach is similar to scenario c, section 10, of RFC 2547bis.

For further details, see Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network," and the Internet Draft draft-ooms-v6ops-bgp-tunnel (work in progress at the time of this writing).

Native IPv6 MPLS

At the time of this writing, no router implementation provides native IPv6 support for LDP or RSVP. However, specifications exist for both, and one could consider a valid evolution to migrate from one of the transitioning methods used to carry IPv6 over MPLS to a native IPv6 MPLS LSP setup. As for non-MPLS backbones, this would require the backbone routers to first become dual stack.

To set up an IPv6 LSP, you could use LDPv6. Similar to BGP, an LDP transport session (over TCP) is relatively independent from where the prefixes are being transported. You could have two separate LDP sessions: an LDPv4 session for transporting IPv4 prefixes, and an LDPv6 session for transporting IPv6 prefixes; alternatively, you could have a single LDP session (for instance, over TCPv4) that carries both types of prefixes. The prefix Forwarding Equivalence Class (FEC) element contains an Address Family field, per RFC 1700, which encodes the IPv6 address family when the address in the Prefix field is IPv6.

In addition to the label distribution protocol, there should be an IPv6 IGP that advertises the PE and the core routers' reachability within the MPLS backbone. As in the non-MPLS IPv6 dual-stack case, this could be OSPFv3 or IS-IS; the latter choice being preferred when the ISP does not want to run multiple routing processes on the same box. (See Chapter 4 for an in-depth analysis of routing protocols.)

To advertise customer prefixes between PE routers, you would still use MP-BGP, address family IPv6, but MP-BGP could run over TCP/IPv4 or TCP/IPv6.

Given the nature of MPLS LSPs, which can transport any sort of payload regardless of which protocol is used to set up these LSPs, you might wonder why it is necessary to set up LSPs using an IPv6 control mechanism. One reason is that core topologies for IPv4 and IPv6 are separate, and traffic follows different paths with different routing policies for both. In that case, of course, many core routers are likely to end up with two IGP instances (for instance, OSPFv2 and OSPFv3) and two LDP instances (IPv4 and IPv6). Although this scenario offers greater flexibility, it also entails more configuration and management complexity. The dual-stack MPLS core is not different from the non-MPLS case when both IPv4 and IPv6 are deployed natively.