Definitive MPLS Network Designs [Electronic resources] نسخه متنی

IPv6 Over MPLS Networks

IP version 6 (IPv6) is a new version of IP designed to replace IP version 4 (IPv4), which is currently deployed and used extensively throughout the world. IPv6 benefits are mainly a result of its much larger addressing space, which is required to cope with the Internet expansion and with the explosion of Internet-capable appliances.

As of early 2004, about two-thirds of the total IPv4 address space had been allocated. Increasingly stricter allocation policies have significantly curbed the rate of address allocation to the point where it is unlikely that the entire IPv4 address space will be fully allocated in the foreseeable future. However, in the face of the growing number of devices requiring IP connectivity, such policies have forced widespread use of address conservation techniques such as the use of private addresses along with Network Address Translation (NAT) devices. NAT dynamically maps many private addresses into a small number of public addresses, typically at the network edge between private networks and the public Internet. A further address-saving technique is on-demand allocation of IP addresses from a shared pool to devices that do not require permanent connectivity. Although these address-conservation techniques have reduced the address allocation requirements in the past few years, they are incompatible with a number of fundamental new evolution trends on the Internet:

Peer-to-peer applications Although most applications in the past were based on client/server architecture, many applications developed recently rely on a peer-to-peer architecture. This includes VoIP, open file-sharing applications such as Napster, and gaming applications. Although these can be made to work through NAT, this entails a significant operational cost and requires application-specific handling within the NAT device.

Explosion of Internet-enabled devices Although PCs are the key devices requiring IP connectivity, many other types of devices now also need Internet connectivity, such as mobile phones, portable entertainment devices, personal digital assistants, and home and industrial appliances.

"Always-on" connectivity Because of the advancement and multiplication of access technologies, such as broadband and wireless, many devices now enjoy "always-on" connectivity.

This results in renewed pressure for a much more generous address allocation policy, which only IPv6 can offer.

Because IPv6 is now gaining acceptance, service providers have been asked by their customers, or will be asked in the coming years, to offer IPv6 services.

After providing an overview of IPv6, the following sections discuss the deployment options available to service providers that currently operate an IPv4 MPLS backbone, particularly the IPv6 Provider Edge (6PE) and IPv6 VPN Provider Edge (6VPE) approaches. 6PE allows for global IPv6 reachability service, and 6VPE allows for IPv6 VPN service over a pure IPv4 MPLS/IP backbone.

Overview of IPv6

IPv6 was designed in the early 1990s within the Internet Engineering Task Force (IETF). It is composed of a whole suite of protocols and procedures. The key topics of IPv6 are presented in the following sections.

IPv6 Header

The base IPv6 protocol is specified in [IPv6]. The key changes in the protocol header from IPv4 to IPv6 are as follows:

The size of the network address field is quadrupled to 16 bytes, affording theoretically 3.4 * 10³⁸ addressable nodes, which provides more than enough globally unique IP addresses for every network device on the planet.

The header format is simplified through the use of fixed-length fields and daisy chaining of optional headers (between the fixed IPv6 header and the transported data).

The IP header checksum is removed.

Support for hop-by-hop segmentation is removed.

Alignment on 64-bit boundaries is achieved.

Figure 1-23 compares the IPv4 header and the IPv6 header.

Figure 1-23. Comparison of IPv6 and IPv4 Headers

[View full size image]

IPv6 Addressing

[ADDR-ARCH] specifies IPv6 address representation and addressing architecture.

IPv6 addresses, which are 128 bits long, are represented as a series of eight 16-bit fields separated by colons. Each 16-bit field is represented as four hexadecimal characters. 200A:1234:00CD:0000:0000:005C:7F3C:E34B is an example of an IPv6 address.

To allow more concise representation, one occurrence of a successive 16-bit field equal to 0000 can be represented by a double colon, and leading 0s in each 16-bit field can be omitted. Thus, the address just mentioned can be represented more concisely as 200A:1234:CD::5C:7F3C:E34B.

For prefix representation, the same prefix notation as IPv4 is used. For example, 200A:1234:00CD::/48 designates a 48-bit IPv6 prefix.

[UNIQLOCAL].

As with global IPv4 addresses, the global IPv6 unicast addresses are structured in a hierarchical manner that allows efficient aggregation of prefixes for routing in the IPv6 Internet. IANA has allocated a prefix range to each Regional Internet Registry (RIR). In turn, the RIRs have defined a coordinated allocation policy [IPV6RIR] to allocate a subset of their own prefix range to entities requesting IPv6 addresses, such as an ISP. In turn, the ISP allocates a subset of its prefix ranges to end users, who then allocate different prefixes from that range to their network links.

Neighbor Discovery and Autoconfiguration

A lot of care has been put into the design of IPv6 to minimize configuration and facilitate plug-and-play operations. To that end, the neighbor discovery protocol (see [IPv6-DISC]) allows IPv6 hosts and routers on a link to dynamically discover or exchange the relevant information local to that link. The functions supported by neighbor discovery include the following:

Prefix discovery IPv6 hosts discover the set of address prefixes on the link.

Parameter discovery IPv6 nodes learn link parameters such as the link MTU.

Address autoconfiguration IPv6 nodes automatically allocate an IPv6 address to an interface.

Address resolution IPv6 nodes determine the link-layer address of destinations on the link (equivalent to ARP for IPv4).

Handling of unreachability issues IPv6 nodes detect neighbor unreachability as well as duplicate addresses. IPv6 hosts can be instructed to redirect their traffic to a better firsthop router.

[AUTO-CONF]), an IPv6 host can automatically generate its unique interface addresses by combining an interface identifier that uniquely identifies the interface on the link (for example, using an IEEE MAC address) and the prefix advertised by the routers for that link. With the IPv6 stateful address autoconfiguration, IPv6 hosts can communicate with a server using Dynamic Host Configuration Protocol for IPv6 (DHCPv6; see [DHCP-IPv6]) to obtain configuration information such as IPv6 addresses.

Graceful renumbering of hosts is supported in IPv6 via the assignment of multiple addresses to an interface and the concept of address lease lifetime, allowing smooth phasing out of old addresses.

IPv6 Routing

Because IPv6 forwarding is also based on a longest match on variable-length prefixes, IPv6 routing is very similar to IPv4 routing, except for the requirement to handle the increased address size of IPv6.

All the routing protocols commonly used today for IPv4 have been extended to support IPv6 routing. RIP has been extended by [RIP-IPv6] to support IPv6. This is called RIPng or RIPv6. IS-IS has been extended in [ISIS-V6] to simultaneously support IPv4 and IPv6 routing in an integrated manner. On the other hand, OSPFv3, specified in [OSPF-IPv6], supports IPv6 routing only. Where both IPv4 and IPv6 routing are required, OSPFv3 needs to run in "ships in the night" mode for IPv6 routing at the same time as OSPFv2 for IPv4 routing. [BGP-IPv6] specifies how Multiprotocol-BGP (MP-BGP) is used to support IPv6 interdomain routing.

IPv6 Quality of Service

Quality of service (QoS) in IPv6 is the same as in IPv4 and also relies on the Differentiated Services model (see [DIFF-ARCH]) or the Integrated Services model (see [INT-SERV]) along with RSVP signaling (see [RSVP]). As described in the section "The IETF DiffServ Model and Mechanisms" in Chapter 2, the Traffic Class field initially defined in the IPv6 header has been superseded to convey the Differentiated Services field.

The IPv6 header also contains a Flow Label field initially intended for QoS applications. Its actual use is still under discussion and is now receiving much less attention because of the wide acceptance of the Differentiated Services model for QoS.

IPv6 Security

Security is very similar in IPv6 and IPv4 because most of the network layer security components, such as the IPSec architecture (see [IPSEC-ARCH]), are equally applicable to IPv4 and IPv6.

Deploying IPv6 Over an MPLS Network

Many migration approaches are available to a service provider to add IPv6 services to its current service portfolio. However, those need to be assessed in the corresponding light when the operator is already running IPv4 MPLS in the network core. For example, an IPv4 MPLS core is likely to be the underpinning infrastructure for very significant revenue-generating services (such as MPLS VPN services) as well as for transit of key overlay networks (such as PSTN trunking or ATM trunking). Therefore, it is of paramount importance that the migration to IPv6 services avoid introducing risks of instability in the multiservice core. Also, a number of advanced MPLS features may be deployed in the core, such as traffic engineering, fast reroute, and MPLS QoS. The IPv6 migration approach must not disturb operations of these features for the IPv4 traffic and should allow the IPv6 traffic to benefit from them. Finally, where the installed equipment has very high MPLS forwarding performance, it may be desirable for the IPv6 migration approach to take advantage of MPLS forwarding for IPv6 traffic.

The most obvious approach for introducing IPv6 services is of course to upgrade the whole network to support IPv6 routing and forwarding natively. Although this approach is the most intuitive and clearly offers very scalable support of global IPv6 connectivity, service providers running an IPv4 MPLS network often do not retain that approach, at least in the short-to-midterm, for the following reasons:

They prefer to avoid (or at least postpone) the corresponding introduction of native IPv6 in the core network, which involve risks and costs that can be avoided with other approaches.

This approach does not allow MPLS features deployed in the core, such as FRR, TE, and MPLS QoS, to be immediately picked up by the IPv6 traffic.

It requires high-performance native IPv6 forwarding on all the installed equipment, as it doesn't take advantage of MPLS forwarding.

It is not easily extendable to enrich the IPv6 connectivity services to MPLS VPN services.

Another possible migration approach is to use IPv6 over IPv4 tunneling. This involves creating IPv4 tunnels on CE routers and run IPv6 routing on top of these tunnels. This uses simple well-known techniques and requires absolutely no upgrade in the backbone (not even on PE routers). And because tunneled IPv6 traffic automatically benefits from the VPN isolation of the IPv4 MPLS VPN service, such a tunneling approach from CE router to CE router is deployed by some service providers as a way to kick-start an IPv6 service with fast time to market. However, deploying IPv6 services using this approach entails custom design, configuration, and operations. Also, this approach suffers from the usual scalability challenges of tunneling techniques (creating and managing tunnels, as well as routing, from every CE router to every other CE router). For these reasons, operators are looking at other approaches to support largescale production IPv6 services.

Pseudowire technology, discussed later in the section "Layer 2 Services and Pseudowires", allows ATM circuits, Frame Relay circuits, port-to-port Ethernet, or VLAN connections to be emulated over an IPv4 MPLS backbone. These can in turn be used to interconnect IPv6 routers, eventually resulting in IPv6 connectivity supported over an IPv4 MPLS network. Like the IPv6 over IPv4 tunneling approach, this approach avoids any IPv6 upgrade to the core but also comes with comparable scalability challenges because the corresponding mesh of circuits needs to be provisioned across the IPv6 devices. Like IPv6 over IPv4 tunneling, this approach has been used by some service providers for early introduction of IPv6 services.

Finally, the 6PE and 6VPE approaches specified in [6PE] and [6VPE], respectively, allow support of global IPv6 reachability services and IPv6 VPN services over an IPv4 MPLS backbone. These approaches have proven very attractive to operators running an IPv4 backbone because

They do not require any upgrade to P routers, hence preserving the backbone stability and minimizing operational costs.

They allow very gradual deployment by upgrading only the PE routers offering the IPv6 services (and where route reflectors are used, either upgrading those or deploying a separate mesh of route reflectors for IPv6).

They are very scalable because they rely on the same single-sided provisioning model as the MPLS VPN architecture, whereby adding a new site involves only configuration on the attachment port for that particular site.

They take advantage of MPLS forwarding in the core and its very high performance.

They ensure that the IPv6 traffic automatically benefits from the advanced MPLS features that may be deployed in the core, such as FRR, TE, and MPLS QoS.

IPv6 Provider Edge (6PE)

The Layer 3 MPLS VPN architecture presented earlier in this chapter introduces a fundamental paradigm. This paradigm is the routing and transport of IPv4 VPN traffic transparently over an IPv4 MPLS core that remains entirely unaware of these IPv4 VPN routes and that remains aware of only the operator's internal IPv4 routes. This is achieved by combining the following:

Hierarchical routing, in which the core network establishes IPv4 PE-to-PE connectivity while IPv4 VPN reachability is advertised only between the PE routers transparently over the core

Tunneling of IPv4 VPN packets through the core from PE router to PE router in IPv4 MPLS LSPs so that the core does not need any IPv4 VPN awareness

The 6PE solution uses this same transparent routing and transport paradigm to achieve global IPv6 reachability over an IPv6-unaware IPv4 MPLS backbone. The key difference obviously is that the reachability information advertised among PE routers via MP-BGP is no longer IPv4 VPN prefixes but rather IPv6 prefixes. So the PE routers become dual-stack (meaning that they run IPv4 and IPv6) and are called 6PE routers. They support IPv6 (and typically also IPv4) on access interfaces but still support only IPv4 and IPv4 MPLS on the core-facing interfaces.

P routers remain IPv6-unaware and run the usual IPv4 routing and IPv4 label distribution. This architecture is illustrated in Figure 1-24.

Figure 1-24. 6PE Architecture

[2547bis] (such as VRFs, route distinguishers, and route targets), because the routing and forwarding tables of IPv6 are naturally separated from those of IPv4.

From a control plane perspective, the following steps take place before IPv6 communication can happen from a source IPv6 site connected to a 6PE router (called the ingress 6PE router) to an IPv6 destination located in another IPv6 site also connected to a 6PE router (called the egress 6PE router):

Reachability of the IPv4 address of the egress 6PE router loopback interface is advertised in the core network via the IPv4 IGP to all P routers and to all other 6PE routers (see Step 1 in Figure 1-25).

Figure 1-25. 6PE Control Plane Operations

[View full size image]

Labels are distributed in the core to all P routers and 6PE routers for this IPv4 loopback address through the usual IPv4 label distribution techniques, such as the LDP protocol. In particular, this results in establishing IPv4 connectivity from the ingress 6PE router to the egress 6PE router in the form of an IPv4 LSP (see Step 2 in Figure 1-25).

The 6PE routers run MP-BGP among each other using the labeled IPv6 address family. Because the core supports only IPv4, the MP-BGP sessions run over an IPv4 stack. Upon learning reachability toward the destination IPv6 prefix (for example, via an IPv6 routing protocol running with the IPv6 CE router, as in Step 3 of Figure 1-25, or via configuration of an IPv6 static route), the egress 6PE router advertises reachability for this prefix to all other 6PE routers using MP-BGP, as in Step 4 of Figure 1-25. Because the core provides IPv4 connectivity only among 6PE routers, when advertising the IPv6 reachability, the egress 6PE router must convey to other 6PE routers its IPv4 address as the BGP next hop. However, the BGP protocol specifications assume that the BGP Next Hop field is of the same address family as the reachability information (IPv6 in that case). As discussed, the IPv6 addressing architecture defines the IPv4-mapped IPv6 address format precisely for the purpose of representing the address of an IPv4 node as an IPv6 address. Thus, the IPv4 address of the egress 6PE router is encoded in the BGP Next Hop field as an IPv4-mapped IPv6 address. A label is also advertised by the egress 6PE router for the IPv6 prefix. Finally, the egress 6PE router populates an entry in its LFIB for this label/prefix that indicates how to forward the packets received with that label. Depending on the label allocation policy, this might be to pop the label and forward to the next hop interface to the destination, or it might be to pop the label and perform a lookup in the IPv6 forwarding information base.

After running the usual BGP route-selection algorithm, the ingress 6PE router populates its IPv6 forwarding information base with an entry for the advertised IPv6 prefix that indicates that a packet destined for that IPv6 prefix

- Is to be encapsulated using MPLS with a label stack whose bottom label is the label advertised in MP-BGP for the IPv6 prefix and whose top label is the label advertised in the core for the IPv4 loopback address of the egress 6PE router that is the BGP next hop for that IPv6 prefix

- Is to be forwarded to the interface on the IPv4 shortest path to the egress 6PE router

If a routing protocol is used between the source site and the ingress 6PE router, the ingress 6PE router advertises the reachability of the IPv6 prefix in that routing protocol, as in Step 5 in Figure 1-25.

IPv6 communication can now take place over the IPv4 MPLS backbone. When the ingress 6PE router receives an IPv6 packet, it performs a lookup on the destination IPv6 address in its IPv6 forwarding information base that matches the entry populated by the control plane, as just discussed. Thus, the ingress 6PE router pushes a label stack in front of the IPv6 packet with a bottom label that is the one advertised in MP-BGP for the IPv6 prefix and with a top label that is the one advertised by the core label distribution protocol for the BGP next-hop IPv4 loopback address. The 6PE router finally forwards that labeled packet toward the core on the next-hop interface to the egress 6PE router.

The P routers perform regular IPv4 label-switching operations, resulting in the swapping of the topmost label (or the popping of that label on the penultimate router if PHP is used).

Finally the packet is received by the egress 6PE router. Where PHP is used in the core, the packet is received with a single label, which is the label advertised in MP-BGP for the IPv6 prefix. Otherwise, the egress 6PE router first pops the IPv4 label, thereby exposing the label advertised in MP-BGP. When performing a lookup in its label information base for that label, the egress 6PE router finds the entry populated by the control plane, which tells it how to properly forward that packet.

Packet forwarding at every hop is illustrated in Figure 1-26. In this example, PHP is used and MP-BGP allocates a separate label to each IPv6 prefix so that the packet can be label-switched by the egress 6PE router without requiring an IPv6 lookup.

Figure 1-26. 6PE Data Plane Operations

[View full size image]

You can see that IPv6 devices in the IPv6 sites are unaware that IPv6 packet forwarding occurs over MPLS in the core; they operate in their regular IPv6 way. Similarly, P routers in the MPLS core are unaware that the MPLS packets they are switching actually carry IPv6 traffic.

As with the MPLS VPN architecture, the 6PE routers can run a full mesh of MP-BGP sessions for exchange of IPv6 reachability or can use the usual BGP scaling techniques, such as route reflectors.

The 6PE approach can operate across multiple autonomous systems. One such scenario is where the 6PE solution is localized within each autonomous system. In this case, the ASBRs of these autonomous systems exchange regular IPv6 reachability information (perhaps without even being aware that the other network uses the 6PE approach). Another scenario is where the 6PE solution spans multiple autonomous systems. In that case, the labeled IPv6 reachability information is exchanged between the route reflectors (or directly between the 6PE routers) of the different autonomous systems. At the same time, labeled IPv4 routes for the 6PE routers' loopback addresses are exchanged between the ASBRs of the different autonomous systems to ensure that the 6PE routers can be reached across the different autonomous systems via IPv4 LSPs.

IPv6 VPN Provider Edge (6VPE)

In addition to IPv6 global connectivity services that can be offered by the 6PE approach, service providers are asked by their customers to offer IPv6 VPN services. The prime driver for such IPv6 VPN services is the exact same need for isolation of end users' intranets as sought with IPv4 VPN services. The 6VPE approach combines the "IPv6 handling" of 6PE with the "VPN handling" of IPv4 MPLS VPNs (described earlier, in the section "MPLS VPN Services in MPLS/IP Networks") to support such IPv6 VPN services over an IPv4 MPLS backbone.

The salient extensions to the 6PE approach are as follows:

Use of a different address family in MP-BGP defined for the 6VPE purpose, which is the VPN-IPv6 address family (Address Family Identifier AFI = 2 for "IPv6", Sub Address Family Identifier SAFI = 128 for "labeled VPN"). A VPN-IPv6 address is a 24-byte entity, beginning with an 8-byte route distinguisher (RD) and ending with a 16-byte IPv6 address. The role and encoding of the RD is exactly as with IPv4 VPNs.

Use of the VRF concept of the Layer 3 MPLS VPN architecture, in which each VPN has a separate set of routing and forwarding tables, along with all the associated mechanisms to control import and export of routes into and out of VRFs, including tagging of routes with route targets.

The 6VPE approach yields the same benefits as the 6PE approach. For example, as with 6PE, only the PE routers that actually connect IPv6 VPN services need to be upgraded to support IPv6 and the 6VPE functionality. Thus, the service provider can also introduce IPv6 VPN services without any upgrade or configuration changes on the core routers.

Also, because the 6VPE approach relies on the very same mechanisms as Layer 3 MPLS VPN for IPv4, the service provider can offer the end user the exact same VPN service and features for IPv6 as for IPv4, making the IPv6 VPN service much simpler to understand and integrate within the customer intranet.

Finally, the service provider can rely on the exact same set of Operations, Administration, and Maintenance (OAM) tools to support both the IPv4 and IPv6 VPN service, thus dramatically reducing operational costs.