Feature Article

IPv6: A Necessity in a Global Economy

This article originally appeared in the August issue of INTERNET TELEPHONY

Although it’s been talked about for nearly a decade, the buzz about IPv6 is heating up, especially after the success of World IPv6 Day on June 8. Everyone who’s paying attention knows that IPv4 addresses will soon be exhausted, so the adoption of IPv6 is inevitable.

Some U.S. organizations have not seen the urgency to support IPv6 because they say they still own plenty of unallocated IPv4 addresses – maybe enough to last them another two or three years. Unfortunately, that fact is quickly becoming irrelevant as the rest of the world around them has already begun transitioning to IPv6. Beginning in Asia and moving quickly throughout the Middle East and Europe, organizations are already adopting IPv6 for one simple reason: They don’t have a choice; they can’t get IPv4 addresses. And because the world today is so highly interconnected, this has business implications for everyone. Unless organizations that currently exist on the IPv4 Internet provide IPv6 connectivity for their public-facing web applications and services, new IPv6 users will be cut off from these resources.

No one understands this better than mobile carriers and Internet service providers. Both will soon have countless new IPv6 customers who want and expect the same Internet access and mobile services they’ve always enjoyed on the IPv4 Internet. The market has reached a point where supporting IPv6 is not an option for service providers. They, too, are running out of IPv4 addresses, and many of their upstream ISPs will only be able to provide IPv6 addressing for them in the future. If one provider can’t supply enough addresses to meet customer demand, customers will go to a provider that can, even if it means converting to IPv6. Service providers can’t risk losing existing customers to competitors, and they can only expand their subscriber base and services by supporting IPv6.

Faced with these market changes, service providers are struggling to find the most efficient and cost effective way to serve both IPv4 and IPv6 customers. They must provide connectivity to and between networks so that, for example, IPv6-only clients can access the IPv4 Internet. Once they can provide reliable IPv6 connectivity, they face the challenge of transitioning their internal networks to IPv6 without disruption.

Service providers can’t afford to make massive changes in their subscriber networks all at once, and downtime is not an option, so a gradual migration strategy is essential. They need solutions that make it possible for them to begin supporting IPv6 users without converting their internal infrastructures at the same time. Fortunately, there are options that enable service providers to gradually implement IPv6.

Tunneling is a mechanism for getting traffic that uses one protocol across a network that uses another protocol. DS-Lite and 6rd are two examples of tunneling methods used for handling both IPv4 and IPv6 traffic.

DS-Lite enables IPv4 traffic to travel through an IPv6 backbone network. For example, suppose an ISP’s customer premises equipment, such as a cable modem in a residence, supports IPv6 but the client devices that connect to it are IPv4 only. When a client requests an address for a web site that resides only on the IPv4 network, DS-Lite establishes an IPv4 tunnel across the provider’s IPv6 network. By packaging, or encapsulating, the IPv4 address inside of an IPv6 packet, the client can connect to the IPv4-only website via the ISP’s IPv6 network. Before the packet leaves the IPv6 network, however, the ISP’s carrier grade NAT (CGN) must translate the IPv6 address back to the original IPv4 address so it can route the packet to its final destination on the IPv4 Internet. DS-Lite has its place in certain scenarios like the one just described, but ultimately it is only a stop-gap solution. Because it still relies entirely on the IPv4 network to transport packets, DS-Lite doesn’t help a service provider progress toward the end game of establishing a fully IPv6 infrastructure.

IPv6 rapid deployment, or 6rd, is another tunneling mechanism that is essentially the inverse of DS-Lite except that it tunnels IPv6 traffic over existing IPv4 networks. An important distinction from DS-Lite is that 6rd operates entirely within the end user’s ISP network. As service providers begin implementing the preferred dual stack infrastructure, the use of 6rd is expected to fade relatively quickly.

With a true dual stack (not to be confused with DS-Lite) solution, both IPv4 and IPv6 protocol stacks are fully supported by the client device and the provider network. Dual stack is somewhat comparable to a person who is bilingual in English and Spanish; he or she can answer a question in either language depending on the language in which a question is asked.

In a dual stack environment, all participants in the communication exchange can speak either IPv4 or IPv6. For example, if a client requests an IPv6 address for www.example.com and it exists, the client receives the IPv6 address and connects to that site across the service provider’s IPv6 backbone network. If www.example.com exists only on the IPv4 Internet, the client receives the IPv4 address for that site and connects to it across the IPv4 network. Dual stack, then, is a mechanism that enables both IPv4 and IPv6 traffic and determines which protocol to use based on the request the client makes.

Using dual stack with NAT64 is an appropriate solution for service providers’ own services and offerings such as customer web portals, and mobile, video, and web content that they offer to their customers. For instance, if a video service provider wanted to convert its video-on demand infrastructure to IPv6, it could use an application delivery controller close to its VoD servers to handle NAT64. Then, when an IPv4-only set-top box requests a video on demand, for example, the IPv4 request goes to the ADC (News - Alert), which translates the address to IPv6 and forwards the request to the cable company’s network. When the movie starts streaming in IPv6, it comes back through the ADC device, which translated the IPv6 address back to IPv4 so the video can be delivered to the end user’s IPv4-only set-top box. This solution enables service providers to begin transitioning their own internal infrastructures to IPv6 while still supporting IPv4 client devices. It also gives cable companies a way to avoid the time and expense of upgrading the firmware in set-top boxes and other CPE to make them IPv6-capable.

For traffic that passes through a service provider’s network to a destination on either the IPv4 or IPv6 Internet, a combination of dual stack with both NAT64 and DNS64 is the best solution. DNS64 provides name resolution for IPv6-only clients when they request a site that’s only available on the IPv4 Internet. From the DNS64 server, the client receives a “synthesized” IPv6 address, which includes a pointer to a NAT64 server. The NAT64 server then translates the synthesized IPv6 address to an IPv4 address, connects the client, and then keeps track of both addresses so that the session between the IPv6 client and the IPv4 destination can continue.

For a service provider whose ultimate goal is to transition to IPv6 (while still supporting IPv4 as its prominence fades), a dual stack NAT64/DNS64 solution will help make that transition as seamless as possible. Unless they have a compelling reason to do so, providers that have not begun yet to implement IPv6 migration strategies are probably better off avoiding tunneling at this point in the game. Tunneling prolongs reliance on the IPv4 network and only delays the inevitable. With a dual stack-capable network and NAT64/DNS64 deployed where necessary, service providers aren’t implementing interim throw away solutions; they’re beginning to lay a solid foundation for a full transition to IPv6. If they can work with vendors whose solutions are already natively IPv6, so much the better.

Sean Duggan is director of product management at F5 Networks (News - Alert) (www.f5.com).