by Tejas Suthar, TELUS Communications Inc.

We are all aware of the evolution of the Internet Protocol (IP) and its dominance on all aspects of our lives, either directly or indirectly. Currently IP Version 4 delivers critical business application traffic in a so-called new world of the Internet. As the evolution goes on, IP Version 6 (IPv6) [5] is becoming a necessary element of the network. IPv6 will enable businesses to expand their capabilities exponentially without having any limitations or restrictions. As technologies evolve and the adoption of IP-enabled devices accelerates, IP will enter a new era as the protocol of choice for communications. Using globally unique IPv6 addresses increases the opportunity for service providers to create new business models and add revenue, and it increases the portfolio of services. However, the major demand for support of IPv6 will be mobile applications; the IT world will also tie in all the systems for transparent operation. The days are not far when permanent IPv6 addresses will be assigned to individuals for their communication purposes—either Voice over IP (VoIP), video over IP, video on demand, wireless Internet access, unified messaging, etc. Also, IP smart appliances are becoming more and more popular, and the result will be explosive usage and adoption of IPv6 addresses. Articles outlining the importance of IPv6 and limitations of IPv4 abound. This article is mainly geared toward highlighting the service provider networks that are built or currently being built to support IPv6 in a VPN fashion.

Multiprotocol Label Switching (MPLS) [4] is widely accepted as a core technology for the Next-Generation Internet that provides speed and functions in packet forwarding. Service providers that offer MPLS/VPN services to their customers are looking forward to adding IPv6 VPN services to their portfolio. Service providers that want to support IPv6 in traditional ways have few options, such as tunneling methods (for example, manual, Tunnel Broker, Generic Routing Encapsulation [GRE], or Intrasite Automatic Tunnel Addressing Protocol [ISATAP], which has scalability problems); or Native IPv6 with dual-stacked MPLS core. However, consider the following:

	For MPLS VPN services, service providers made a significant investment in building the IPv4/MPLS backbone. The return on investment thresholds are probably yet to be achieved.
	Backbone stability is another critical factor; service providers must offer reliable services, especially with regard to voice over MPLS. Most service providers have recently managed to stabilize their IPv4 infrastructure, and they are hesitant to make another significant move when it comes to supporting IPv6 unless the integration is smooth.

Standards bodies with help from vendors and leading service providers are addressing these concerns. Currently service providers have two approaches that they can deploy to support IPv6 without making any changes to the current IP (v4) MPLS backbones, namely 6PE [1] and 6VPE [2] , originally defined in RFC 2547.

The 6PE approach lets IPv6 domains communicate with each other over an IPv4 cloud without explicit tunnel setup, requiring only one IPv4 address per IPv6 domain. The 6PE technique allows service providers to provide global IPv6 reachability over IPv4 MPLS. It allows one shared routing table for all other devices. Typical applications are IP toll voice traffic and Internet transit services over a common MPLS infrastructure. The 6PE technique does not provide any logical separation because it is for MPLS VPN.

The newest feature to facilitate the RFC 2547bis-like VPN model for IPv6 networks is called 6VPE. It will save service providers from enabling a separate signaling plane, and it takes advantage of operational IPv4 MPLS backbones. Thus there is no need for dual-stacking within the MPLS core. This represents a huge cost savings from the operating expenses perspective and addresses the security limitations of the 6PE approach. 6VPE is more like a regular IPv4 MPLS-VPN provider edge, with an addition of IPv6 support within Virtual Routing and Forwarding (VRF). It provides logically separate routing table entries for VPN member devices. This article reviews this approach in more detail because it is the likely approach to succeed in the service provider network.

Under the Hood of 6VPE
Before we look into the 6VPE, it is important to clarify the definition of “dual stack,” a technique that allows IPv4 and IPv6 to coexist on the same interfaces. Today, IPv4 has roots in most of the hosts that run applications. Moreover, stability as well as reliability of new applications over IPv6 is maturing. Therefore, coexistence of IPv4 and IPv6 is a requirement for initial deployment. With regard to supporting IPv6 on a MPLS network, two important aspects of the network should be examined:

Core: The 6VPE technique allows carrying IPv6 in a VPN fashion over a non-IPv6-aware MPLS core. It also allows IPv4 or IPv6 communities to communicate with each other over an IPv4 MPLS backbone without modifying the core infrastructure. By avoiding dual-stacking on the core routers, the resources can be dedicated to their primary function to avoid any complexity on the operational side. The transition and integration with respect to the current state of networks is also transparent.

Access: In order to support native IPv6, the access that connects to IPv4/IPv6 domains need to be IPv6-aware. Service provider edge elements (provider edge routers) can exchange routing information with end users. Hence dual stacking is a mandatory requirement on the access layer as shown in Figure 1.

Figure 1: 6VPE Overview



The IPv6 VPN solution defined in this article offers many benefits. Especially where a coexistence of IPv4 and IPv6 is concerned, the same MPLS infrastructure can be used without putting additional stress on the provider router. Also the same set of Multiprotocol Border Gateway Protocol (MPBGP) peering relationships can be used. Because it is independent of whether the core runs IPv4 or IPv6, the IPv6 VPN service supported before and after a migration of the core to IPv6 can be done independent of the customer VPN.

Within the MPLS core, the backbone Interior Gateway Protocol (IGP) (Intermediate System-to-Intermediate System [IS-IS] or Open Shortest Path First [OSPF]) populates the global routing table (v4) with all provider edge and provider routes. As outlined in the draft for IPv4 MPLS VPN (2547-bis), 6VPE routers maintain separate routing tables for logical separation. This allows the VPN to be private over a public infrastructure.

The VRF table associated with one or more directly connected sites (customer edge devices) form close IPv6 or IPv4 speaking communities. The VRFs are associated to physical or logical interfaces. Interfaces can share the same VRF if the connected sites share the same routing information. MPLS nodes forward packets based on the top label. IPv6 packets and IPv4 packets share the same common set of forwarding characteristics or attributes, also known as Forwarding Equivalence Class (FEC) within the MPLS core.

6VPE Operation
When IPv6 is enabled on the sub-interface that is participating in a VPN, it becomes an IPv6 VPN. The customer edge-provider edge link is running IPv6 or IPv4 natively. The addition of IPv6 on a provider edge router turns the provider edge into 6VPE, thereby enabling service providers to support IPv6 over the MPLS network.

Figure 2: 6VPE Route Advertisement



As outlined in Figure 2, provider edge routers use VRF tables to maintain the segregated reachability and forwarding information of each IPv6 VPN. MPBGP with its IPv6 extensions distributes the routes from 6VPE to other 6VPEs through a direct internal BGP (iBGP) session or through VPNv6 route reflectors. The next hop of the advertising provider edge router still remains the IPv4 address (normally it is a loopback interface), but with the addition of IPv6, a value of ::FFFF: gets prepended to the IPv4 next_hop. The technique can be best described as automatic tunneling of the IPv6 packets through the IPv4 backbone. The MP-BGP relationships remain the same as they are for VPNv4 traffic, with an additional capability of VPNv6. Where both IPv4 and IPv6 are supported, the same set of MPBGP peering relationships is used.

MPBGP is enhanced to carry IPv6 in a VPN fashion known as VPNv6, which uses a new VPNv6 address family. The VPNv6 address family consists of 8 bytes—a Route Distinguisher followed by a 16-byte IPv6 prefix. This combination forms a unique VPNv6 identifier of 24 bytes. The Route Distinguisher value has a local significance on the router, and the Route Target advertises the membership of the VPN to other provider edge routers.

Figure 3: 6VPE Packet Forwarding



In Figure 3, packet forwarding is explained showing end-to-end operation. When the ingress 6VPE router receives an IPv6 packet, destination lookup is done in the VRF table. This destination prefix is either local to the 6VPE (which is another interface participating in the VPN) or a remote ingress 6VPE router. For the prefix learned through the remote 6VPE router, the ingress router does a lookup in the VPNv6 forwarding table. The VPN-IPv6 route has an associated MPLS label and an associated BGP next_hop label. This MPLS label is imposed on the IPv6 packet. The ingress 6VPE router performs a PUSH action, which is a top label bind by the Label Distribution Protocol (LDP)/IGPv4 to the IPv4 address of the BGP next_hop to reach the egress 6VPE router through the MPLS cloud. This topmost-imposed label corresponds to the Label Switched Path (LSP). So, the bottom label is bound to the IPv6 VPN prefix through BGP and the top label is bound by the LDP/IGP. The IPv6 packet, now with two labels, gets label-switched through the IPv4/MPLS core router (provider routers) using the top label only (referred to as the IGP label). Because only the top label is of significance to the provider core, it is unaware of the IPv6 information in the bottom label.

The egress provider edge router, receives the labeled IPv6 VPN packet and performs a lookup on the second label, a process that uniquely identifies the target VRF and the egress interface. A further Layer 3 lookup is performed in the target VRF, and the IPv6 packet is sent toward the proper customer edge router in IPv6 domain.

In summary, from the control plane perspective the prefixes are signaled across the backbone in the same way as for regular MPLS/VPN prefix advertisements. The top label represents the IGP information that remains the same as for IPv4 MPLS. The bottom label represents the VPN information that the packet belongs to. As described earlier, additionally the MPBGP next_hop is updated to make it IPv6-compliant. The forwarding or data plane function remains the same as it is deployed for the IPv4 MPLS VPN. The packet forwarding of IPv4 on the current MPLS VPN remains intact.

6VPE Design Recommendations and Considerations
The following sections identify general recommendations that should be considered when deploying IPv6 in a service provider network:

Working with Enterprise Implementations
Typically Customer Metropolitan-Area Networks (C-MANs), also known as Campus Networks or Customer LAN (C-LAN) elements, form the enterprise network, whereas the 6VPE and customer edge provide the entry point into network access. IPv6 can be supported partially or fully on an enterprise network. In situations where enterprise-wide IPv6 deployment does not exist, network administrators can elect to tunnel the IPv6 traffic toward the provider’s customer edge or 6VPE. This can be done with 6-to-4 tunneling methods currently [7]. So, if a site router within a C-MAN or C-LAN aggregates all IPv6 traffic and tunnels to a provider-managed customer edge or 6VPE router, then integration as well as migration becomes smooth. Therefore, it is important for the vendor and the customer to work together in determining the best approach.

Dual VRF Membership per Interface
RFC 2547 for IPv4 recommends one VRF per interface. When running dual stack on a 6VPE, multiple VRF configurations on a single physical or logical interface are required (IPv4 and IPv6). Each VRF instance configuration on a dual-stacked interface forms IPv4 and IPv6 address families. Each address family within VRF runs a VRF-aware routing protocol—such as static routing (static IPv6 unicast routing for IPv6), BGP (BGP with IPv6 enhancements for IPv6), OSPF (OSPFv3 for IPv6), or Routing Information Protocol (RIP) (RIPng for IPv6).

MTU Requirements
One important piece of information within the network elements is the capacity of the interface to transfer the size of datagrams. This is known as the Maximum Transmission Unit (MTU). The minimum link MTU for IPv4 packets is 68 bytes, whereas for IPv6 the minimum MTU should be 1280 bytes. While designing and planning for IPv6 support, the network elements should be examined along with interfaces and underlying network technologies to ensure the MTU requirements.

Dealing with Link-Locals
Because link-local scope addresses are defined as uniquely identifying interfaces within a single link, only those may be used on the provider edge-customer edge link.

However, they are not supported for reachability across IPv6 VPN sites and are never advertised with MPBGP to remote provider edges. As outlined in the RFC for IPv6 address assignments, the link locals (FE80::x) should not be advertised outside their local scope. Because the link-local addresses are embedded on the IPv6-enabled interface for certain local tasks, the link-local addresses are not and should not be advertised anywhere outside the local link scope, including the customer edge and 6VPE running IPv6. Globally unique aggregatable IPv6 prefixes are defined as uniquely identifying interfaces anywhere in the network. These addresses are expected for common use within and across IPv6 VPN sites. They are obviously supported by this IPv6 VPN solution for reachability across IPv6 VPN sites and advertised through MPBGP to remote provider edges.

Router Capacity Impact
Dual-stacking also introduces another task, namely hardware analysis to determine the resource capacity, that is, CPU and memory usage. Increased memory consumption may occur because of the dual-stack Routing Information Base (RIB). It also has implications for the Interface Descriptor Block (IDB) and Routing Descriptor Block (RDB) limits of hardware. The IDB limit is the capacity of particular equipment to support a number of physical and logical interfaces, whereas the RDB limit is the number of routing protocols and instances supported on such equipment. Typically these values (limits) are very high, but 6VPE is such an important element of the MPLS network that these facts must be considered. From a business case perspective, scalability, high aggregation, and rapid Return on Investment are expected, hence it is important to consider these factors in the design.

Figure 4: Route Aggregation



Router Memory Impact
The memory challenges can occur also when large numbers of IPv6 prefixes are advertising toward service provider network elements. In that event, the enterprise on the C-LAN or service provider on the customer edge router may elect to perform route aggregation. IPv6 prefixes can be aggregated to their higher-level significant boundary. Figure 4 shows an example of IPv6 prefix aggregation. Moreover, when a packet arrives on a dual-stacked interface (VRF-aware interface), the 6VPE router determines the packet version number by looking into the IP header. The per-packet header lookup is normally performed (it is a basic router function), but the extra work required by the router is to determine the version number. This additional task creates a longer processing cycle.

The Address Family Identifier and its Importance
All the elements referenced as dual-stacked, such as provider edge and customer edge routers, run IPv4 as well as IPv6 addressing and routing protocols. The 6VPE elements can also mix and match VPNv4 and VPNv6 peering sessions with other 6VPE routers or with route reflectors. What does the term “mix and match” mean here? It was an important enhancement to traditional BGP when MPBGP extensions were introduced. The address family within MPBGP is modular to facilitate distinct peering relationships, and is expressed using the Address Family Identifier (AFI). The regular BGP capabilities are exchanged after the peering sessions are turned on. In order for two provider edge routers to exchange labeled IPv6 VPN prefixes, they must use BGP capabilities negotiation to ensure that they both are capable of processing such information. When the service provider network is running VPNv4 peering sessions with other respective elements in the network, it exchanges the VPNv4 AFI capabilities with others. When the VPNv6 peering sessions are turned on, it renegotiates the capabilities and fresh peering sessions are established. The peering sessions established are based on common features if either of the peers does not agree on any of the capabilities.

Figure 5: VPNv4 and VPNv6 AFI



In Figure 5, three provider edge routers out of two need to exchange VPNv6 traffic, but all three provider edge routers need to maintain their existing VPNv4 capabilities. This is possible with the AFI configuration feature, which makes the migration steps very smooth. Service providers can mix and match VPNv4 and VPNv6 provider edge routers as required. Functions of 6VPE can be turned on when and where required. If the customer edge routers are dual-homed to different provider edge routers, the integration of customer IPv4 and IPv6 networks becomes painless. This scenario outlines hybrid environments, but it does not address the IPv4 and IPv6 communication. Consider techniques such as Network Address Translation (NAT) or application layer gateways for the IPv4 and IPv6 communication.

Route Reflectors for MP-IBGP
For advertising VPN membership, provider edge routers peer with VPNv4 route reflectors for scalability, thereby avoiding the need for full-mesh MP iBGP sessions among all provider edge routers. The same concept is supported for VPNv6. The same VPNv4 route reflectors can be upgraded to support VPNv6 address families.

Route reflectors can also make addition or removal of a provider edge router from a network simple and flexible. Alternatively, the BGP confederation option can also be deployed to provide MPBGP peering sessions among provider edge routers.

QoS Considerations
Service providers operating customers’ MPLS VPN networks and also providing Quality of Service (QoS) should account for the new introduction of IPv6 and its impact. QoS and queuing of important application traffic requires distinct policies for IPv4 and IPv6, in turn possibly requiring additional operational tasks where IPv4 and IPv6 networks coexist. Other design considerations should be made to account for each individual network. Both IPv4 and IPv6 have a commonality, which is the 3-bit IP Precedence (or Type-of-Service [ToS]) field within the IP headers. Alternatively, the Differentiated Services (Diff-Serv)-compliant QoS models can also be employed. Irrespective of the technique, QoS is an important factor when lowspeed links are concerned. However, there is no additional advantage of QoS on IPv6 versus IPv4. At some point in the future IPv6 can be different by using the flow label in the IPv6 header. QoS within the MPLS core remains MPLS Experimental Value (MPLS_EXP)-based and is untouched but still is effective with the addition of IPv6.

Device Management
Finally, device management is another important aspect that service providers must consider. Device management in a dual-stacked network can be done through an IPv4 or IPv6 address. Where the IPv6 VPN service is supported over an IPv4 backbone, and where the service provider manages the customer edge, the service provider can elect to use IPv6 for communication between the management tool and the customer edge for such management purposes. The management systems, including Operations-Support-System (OSS) servers, need to be aware of IPv6 and must run proper Simple Network Management Protocol (SNMP) stacks in order to perform IPv6-based management. From the VPN perspective it still remains transparent how the device and services are managed.

Enhancements to the Draft
The current MPLS VPN services that service providers have implemented are based on RFC 2547bis, the Internet Draft required to enhance the Layer 3 VPN approach further to address the IPv6 support. The “BGP-MPLS VPN extension for IPv6 VPN” [1] is the current Draft that addresses the need for IPv6 support over MPLS networks in a VPN environment. Also, to avoid an extra layer of signaling, the Draft addresses the scalable automatic tunneling of VPN-based IPv6 prefixes. The basic functions remain the same as outlined in RFC 2547. Some of the extensions outlined will require additional work in order to be effective in the service provider network.

Figure 6: Dual Mode 6VPE AFI Model



The standard RFC 2547bis introduces “address family” concepts, as well as MPBGP to carry VPN information across the MPLS network. This enables formation of a full mesh between customer sites. The provider edge routers advertise their VPN membership to other provider edge routers through direct iBGP or value(s). As shown in Figure 6, these new address families are introduced to support IPv6 within VPN, IPv6, and VPNv6. If configured for dual stacking, the interface belongs to multiple VRF instances, IPv4 and IPv6. Each instance maintains its own RIB. MPBGP is now capable of handling the VPNv6 address family to advertise the IPv6 prefix across the VPN.

Summary
“Staying abreast of the best” has always been challenging for service providers when it comes to technology deployment or support. Time to market is another challenge. This article provides a view of the service provider challenges. In this new era where explosive use of IPv6 is envisioned, it is extremely important for service providers to have a simplified, automated, fail-proof, and cost-effective network design. The Internet Draft discussed advances the capabilities to achieve this and allows service providers to take a practical approach in supporting IPv6 for customers’ next-generation applications. The Draft brings service providers closer to the IPv4-to-IPv6 transition with a simple, cleaner, cheaper, and scalable solution.

For Further Reading
[1] Jeremy De Clercq, Dirk Ooms, Marco Carugi, Francois Le Faucheur, “BGP-MPLS VPN extension for IPv6 VPN,” draft-ietf-l3vpn-bgp-ipv6.06.txt, February 2005.

[2] Eric Rosen and Yakov Rekhter, “BGP/MPLS VPNs,” draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004. (See also RFC 2547, March 1999, by the same authors.)

[3] Mallik Tatipamula, Patrick Grossetete and Hiroshi Esaki, “IPv6 Integration and Coexistence Strategies for Next-Generation Networks,” IEEE Communications Magazine, Vol. 42, No. 1, January 2004.

[4] Bates, Chandra, Katz, and Rekhter, “Multiprotocol Extensions for BGP4,” RFC 2858, June 2000.

[5] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1995.

[6] Rekhter and Rosen, “Carrying Label Information in BGP4,” RFC 3107, May 2001.

[7] Carpenter, B. E., Moore, K., Fink, R., “Connecting IPv6 Routing Domains Over the IPv4 Internet,” The Internet Protocol Journal, Volume 3, No. 1, March 2000.

TEJAS SUTHAR holds CCIE # 8423. He is working as a Service Architect at TELUS Communications Inc. in Toronto. He focuses on Converged Network designs for customers in various industry sectors. He is very active in IP-related deployments. E-mail: tejas.suthar@gmail.com