The time for IPv4 to IPv6 transition has finally arrived after more than a decade of forewarning. On Feb. 1, 2011, the Internet Assigned Numbers Authority (IANA) allocated the last freely available block of IPv4 addresses. Given the extent to which IPv4 addresses are embedded in networks and applications, IPv4 and IPv6 addresses will coexist for decades.
At the same time, smart phone and tablet use continues to explode, and it is expected that there will be an increase of five billion unique endpoints by 2015. These users and endpoints will all require Internet access and, as a result, a unique IP address.
With broadband deployments achieving global exponential growth and next-generation wireless rollouts on the horizon, service providers are challenged to prepare their networks for the influx of IPv6 addresses. The Internet is rich with IPv6 content and services like Google, which already had shown its support of IPv6 on its search, news, docs, maps, and YouTube.
However, IPv4 won’t just disappear as IPv6 arrives. Upgraded network architectures need to support both IPv4 and IPv6 technologies, the associated transition/translation mechanisms, and scale to accommodate a significant increase in clients and services. Service providers now are charged with the task of upgrading their network infrastructures to handle IPv4 and IPv6 coexistence while at the same time retaining network optimization and customer satisfaction.
Since the biggest transition concern is its impact on customers, service providers question if introducing IPv6 endpoints, forwarding tables, and services will affect connectivity speed, service quality, and network reliability. While network cores are well-equipped to handle both IPv4 and IPv6, broadband access networks are not. The coexistence of IPv4 and IPv6 stresses the underlying network systems, which can introduce latency, degrade network responsiveness, and compromise service-level agreements (SLAs). To proactively address these customer-impacting problems, service providers need a quick and reliable test solution that enables them to predict the effect of the IPv6 transition on their broadband access network.
IPv6 Solutions for Broadband Access
The Internet Protocol (IP) Version 6 (IPv6) is the next generation of the IP protocol with virtually inexhaustible address space that allows improved security, extended routing capabilities, and IP mobility. Since most Internet services still are based on IPv4 and many customers still run operating systems that do not fully support IPv6, an abrupt transition of the legacy IPv4 infrastructure to IPv6 is not practical.
Service providers must be able to support both IPv4 and IPv6 endpoints and services to maintain the quality of service defined in their SLAs. There are three different methods used to achieve this goal across broadband access networks including tunneling (dual-stack lite and IPv6 rapid deployment) and dual-stack.
Method One: Translation
The easiest way to conserve the depleting IPv4 address space is to use translation so that the outward-facing interface uses a public interface while the private network uses IP addresses that are not routed on the Internet. However, the known performance and scalability issues compel most service providers to deploy either tunneling or dual-stack transition mechanisms in broadband access networks.
Method Two: Tunneling
Tunneling mechanisms are used to tunnel IPv6 island traffic over IPv4 networks and vice versa. The two tunneling schemes currently receiving significant industry attention are Dual-Stack Lite (DS-Lite) and IPv6 rapid deployment (6rd).
Dual-Stack Lite
While service providers aim to capitalize on the benefits of quickly embracing IPv6, they also must contain the costs of doing so and ensure uninterrupted IPv4 support. With DS-Lite, broadband service providers handle IPv4 addresses using IP in IP (IPv4-in-IPv6) tunneling and Network Address Translation (NAT). DS-Lite simplifies the IPv4-to-IPv6 transition by decoupling IPv6 deployment in the service provider network from the rest of the Internet (Figure 1).
CGN/AFTR:
- Builds NAT Table (maps IPv4/IPv6)
- Terminates IPv4-in-IPv6 Tunnel
- Encapsulates IPv4 Packet in IPv6 Tunnel
DS-Lite Home Gateway:
- Uses IPv6 Address WAN Interfaces
- Operates DHCPv4 Server on LAN Interfaces
- Encapsulates IPv4 Packet in IPv6 Going to Network
- Decapsulates IPv6 Packet Coming from Network
DS-Lite uses IPv6-only links between the provider and the customer. The DS-Lite home gateway is provisioned with an IPv6 address on its WAN interface. At the LAN-side interface, it operates its own DHCPv4 server, handing out RFC1918 private addresses to home devices. There is no NAT service on the customer premise equipment (CPE) device, such as a home gateway. The NAT service is located on a carrier-grade NAT device (CGN) in the provider’s network, which also is a tunnel terminator for the Pv4-in-IPv6 tunnel.
The IPv4 packet from the home device to an external destination is encapsulated in an IPv6 packet by the DS-Lite home gateway and transported into the provider network. The packet is decapsulated at the CGN, also referred to as an Address Family Translation Router (AFTR), and NAT44 is performed to map the home device’s private IPv4 address to a public IPv4 address. The IPv6 tunnel source address is added to the NAT table, along with an IPv4 source address and port, to disambiguate the customer’s private address and provide the reference for the tunnel endpoint. If a home device needs to access an IPv6 service, it is transported as-is and routed to an Internet server. With DS-Lite technology, the communications between end nodes stay within their address family without requiring protocol family translation.
Service providers may choose this method since there are multiple advantages of DS-Lite over using NAT cascading. Tunneling IPv4 over IPv6 is far simpler than translation so it performs much better than NAT464. Second, the deployment of IPv6 in the service provider network is decoupled and independent of the customers migrating to IPv6. If customer equipment is IPv6-aware, the packets simply follow the IPv6 routing to reach the destination, and no tunneling is performed. Lastly, the increased traffic load is handled by adding more AFTR elements in the service provider network, providing flexibility to adapt to the changing traffic load.
IPv6 Rapid Deployment
Service providers use 6rd to encapsulate IPv6 traffic in IPv4 headers and tunnel home users’ IPv6 traffic through the IPv4 network to IPv6 Internet service to quickly offer end-to-end IPv6 services. This tunnel is terminated by an edge router on the service provider network, and native IPv6 packets then are transmitted to the IPv6-capable Internet. This allows for rapid introduction of IPv6 services in provider networks as they transition from IPv4 to IPv6.
This approach minimizes deployment costs because it only requires upgrades to the routers at the customer edge (CE routers) to support 6rd and additional border routers (BR) that terminate the tunnel. The service provider can operate one or several BRs at its border between its IPv4 infrastructure and the IPv6 Internet depending on the number of IPv6 hosts it has to support and the capacity of a single BR.
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operation as possible. A 6rd domain consists of 6rd CE routers, also referred to as Residential Gateways (RGs) or CPE.
A 6rd CE router functions as a customer edge in a 6rd deployment and is the initiator of the 6rd tunnel. It also consists of one or more 6rd BRs. A 6rd-enabled router is managed by the service provider at the edge of a 6rd domain. The BR terminates the IPv4 tunnel and transmits native IPv6 into the IPv6 network.
The 6rd mechanism relies on an algorithmic mapping between the IPv6 addresses and IPv4 addresses that are assigned for use within the service provider network. An IPv6 prefix, called a 6rd prefix, is selected by the service provider for use by a 6rd domain. There is exactly one 6rd prefix for a given 6rd domain. A service provider may deploy 6rd with a single 6rd domain or multiple 6rd domains. A 6rd CE-calculated IPv6 prefix, called the 6rd delegated prefix, is used within the customer site. The 6rd delegated prefix is achieved by combining the 6rd prefix and CE IPv4 address.
The address mapping supports automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd. The 6rd CE either includes the 6rd delegated prefix in its router advertisement out of its LAN-side interface so each home device can auto-configure its IPv6 address or runs a DHCPv6 server to assign IPv6 addresses from a 6rd-delegated prefix to home devices. The IPv6 packet is encapsulated inside IPv4 by a 6rd CE and follows the IPv4 routing topology within the service provider network among CEs and BRs.
Method Three: Dual-Stack PPP
Many service providers plan to deploy dual-stack networks as a long-term strategy, supporting a mixture of IPv4 and IPv6 applications for customers that require both protocols (Figure 2). Dual-stack-capable devices support both IPv4 and IPv6 from the network layer to the applications. Applications choose to use either IPv4 or IPv6 based on the type of IP traffic and particular requirements of the communications.
Dual-stack deployments are more costly and time-intensive to deploy than tunneling technologies since, at a minimum, all devices in the network require a software upgrade to support both IPv4 and IPv6 protocol stacks and forwarding tables. One important dual-stack technology for DSL networks is dual-stack PPP.
Dual-stack PPP resolves IPv4/IPv6 compatibility issues and facilitates transition to IPv6 by enabling IPv6/IPv4 nodes to send and receive both IPv4 and IPv6 packets. Each individual PPP session results in getting both an IPv4 address and an IPv6 prefix that are used to assign addresses to IP devices at the customer site.
The CPE supports formation of IPv4CP and IPv6CP over the same logical PPP LCP session and allows the end hosts to get IPv6 addresses. Using dual-stack PPP, the user’s CE device can support IPv4 and IPv6 connectivity over a single PPP link while keeping IPv6 and IPv4 connectivity independent from each other.
Dual-stack PPP over L2TP is a specialized case of dual-stack PPP in which the L2TP access concentrator (LAC) and L2TP network server (LNS) tunnel dual-stack PPP sessions. The result for the end user is still an IPv6 address, but dual-stack PPP over L2TP replicates PPP over an L2TP network.
Dual-stack PPP supports the use of DHCPv6 to get broadband subscribers their IPv6 addressing and other networking configuration information directly from the provider edge (PE).
Test Requirements
Testing IPv6 requires emulating the full range of protocols used in today’s IPv4, IPv6, and transitional dual-stack networks as well as fully stressing the data plane and associated tunneling/translation implementations of each device.
It is important to measure the functionality and performance of tunneling mechanisms on network equipment prior to deployment of DS-Lite and 6rd. To offer customers a seamless IPv6 transition, service providers must ensure services can be delivered with requisite quality guarantees. Network design and configuration require protocol and traffic stress-testing to identify the scalability limits of each device.
It is equally important to validate interoperability of the different network devices, especially given the compatibility risks between IPv4 and IPv6 devices. Test equipment plays a critical role in this validation because it enables reliable, repeatable measurements across network devices.
Testing Tunneling
Test equipment is used to emulate the customer premises and home devices as well as the Internet services surrounding each broadband network DUT. This allows service providers to test network equipment under real-world scenarios without the time and expense of building extensive test beds of real equipment.
As shown in Table 1 and Table 2, test equipment can validate key measurements for device functionality, forwarding performance, and application performance, allowing comparative analysis between different network hardware and tunneling implementations; that is, DS-Lite vs. 6rd.
Testing Dual-Stack PPP
For dual-stack network deployments, supporting and scaling both IPv6 and IPv4 versions of each protocol can be process-intensive for infrastructure equipment. It is imperative to verify that the DUT can successfully complete the protocol negotiations, set up sessions at a high rate, and scale clients and traffic.
Test equipment is used to stress dual-stack PPP implementations by emulating DHCP clients, network servers, and access controllers.
Test equipment is used to emulate clients and servers surrounding the dual-stack DUT. Test equipment must simulate different clients’ types, emulate both IPv4 and IPv6 protocol stacks, generate both IPv4 and IPv6 traffic, and test a variety of device types such as BNGs, BRAS, LAC, or LNS.
The Final Migration
With fierce industry competitiveness over customer retention, service providers need assurance of a seamless IPv6 transition—at least from the customer perspective. As IPv4 addresses continue to deplete, IPv6 applications and endpoints will soon become ubiquitous across networks from end to end. As this happens, it’s imperative for service providers to deploy access-network upgrades to support IPv6 and the dual-stack technologies required for IPv6 services. To ensure this evolution is transparent to subscribers, service providers and network equipment vendors must demonstrate that the network infrastructure equipment is ready for IPv4/IPv6 coexistence.
Real-world and worst-case predeployment testing will play a critical role in mitigating any risk to service reliability, scalability, and quality. Comparative metrics between network equipment also will enable service providers to maximize their investment in new and upgraded infrastructure and best optimize network configurations.
About the Author
Michael Haugh is the senior market development manager at Ixia. Previously, he held positions at IBM, AT&T, and Spirent Communications. Haugh has spoken at several industry events including CEWC and the MPLS World Congress, conducted technical seminars throughout the world, and recently was a guest speaker at Light Reading’s recent MPLS-TP webinar. He also represents Ixia within the Metro Ethernet Forum and is on the IEEE-ISTO Committee of Experts for IEEE 1588. [email protected]