IPv4 to IPv6 translation: Comparing network-ready routing solutions

IPv4 to IPv6 translation has been a problem for more than a decade, and several solutions that attempt to solve IPv4 address exhaustion are network ready, according to IP expert Ivan Pepelnjak, who gives his recommendations.

With no usable mechanism in hand to address the IPv4 to IPv6 translation issue after a decade of trying, the time was ripe for new proposals to solve the IP addressing issue. As always, we got more than we asked for.

Some try to implement dual stack and optimize IPv4 address utilization at the same time (DS-Lite and A+P).

In the end, only NAT64 goes all the way and addresses the problem by giving IPv6-only clients access to IPv4-only servers.

Here's a brief analysis of the most popular solutions.

IPv4 to IPv6 translation solutions: Large Scale NAT (NAT44)

Landline residential Internet users have always received a unique public IPv4 address after being connected to the Internet. Mobile operators were frequently using private IP address space and Network Address Translation (NAT) as they initially designed their networks as closed gardens using IP only to access Wireless Application Protocol (WAP) 1.0 content. LSN (see diagram below) addresses the IPv4 address shortage by rolling out large-scale private-IPv4-to-public-IPv4 NAT (thus the NAT44 acronym) to most residential users.

Mobile users usually get one IP address (public or private) per device (mobile phone or tablet/laptop with 3G adapter). Landline users also get one public IP address, but frequently use CPE devices with NAT to connect their home networks to the Internet (NAT in a CPE device allows them to hide their whole network behind a single public IP address). Combining the existing NAT in CPE devices with LSN results in dual NAT within the IPv4 address space (NAT444).

Click the image above to view the graphic in its full size.

A single NAT operation is bad enough if you're trying to set up a peer-to-peer (P2P) session (which could be anything from a Skype call to file sharing) or configure a public server on your home network. NAT444 makes these operations even more complex, so it's fervently hated by everyone but the carriers planning to use it.

NAT444 availability: See LSN

IPv4 to IPv6 translation solutions: DS-Lite

The DS-Lite (see graph below) proposal removes the NAT in CPE, turning CPE into an IP-aware bridge (Basic Broadband Building Block, or B4) that forwards IP packets with private IPv4 addresses to the central LSN device (Address Family Translation Router, or AFTR). IPv6 is used as the transport mechanism between B4 and AFTR and for the native IPv6 connectivity. NAT is performed on the AFTR box, making it almost impossible to deploy a publicly reachable server behind B4.

All NAT solutions rely on a simple fact: More than 65,000 TCP and UDP sessions can be created from a single IP address, but a typical IP host rarely uses more than a few hundred of them. Traditional NAT devices dynamically allocate TCP and UDP port numbers belonging to the same pool of public IP addresses for outgoing TCP or UDP sessions coming from numerous private IP addresses. The A+P proposal changes the rules and assigns static ranges of TCP/UDP ports to residential Internet users. As in today's Internet, the CPE device performs the NAT function, giving the power users more control over NAT and TCP/UDP port allocation. Similar to DS-Lite, IPv6 is used as the transport between CPE devices and AFTR.

Click the image above to view the graphic in its full size.

A+P availability: A+P has no running implementation at this moment.

NAT64: The only workable IPv4 to IPv6 translation solution

This is the only solution encouraging unconditional migration to IPv6 (all the others can prolong the IPv4 pains indefinitely or even avoid end-user migration to IPv6). NAT64 takes the good parts of NAT-PT and enables IPv6-only clients to access IPv4-only servers. It also solves several glitches of NAT-PT and makes the NAT functionality more predictable and aligned with the modern understanding of NAT requirements as specified by the BEHAVE IETF working group.

Click the image above to view the graphic in its full size.

NAT64 availability: At the moment, there is no publicly-available production-grade NAT64 solution. Viagenie has produced a proof-of-concept open-source code and Cisco and Ericsson are supposedly field-testing their solutions.

Which IPv4 to IPv6 translation solution is best?

Theoretically, NAT64 should be the preferred solution because it forces IPv6 deployment on the new clients and thus nudges the carriers and CPE equipment manufacturers in the right direction. Unfortunately, most of the DSL or mobile carriers that cannot force the CPE equipment vendors to manufacture custom-designed boxes will probably have to opt for one of the other solutions. This is primarily because of the lack of IPv6 support on low-cost DSL and mobile devices (IPv6 is an integral part of the cable industry's DOCSIS 3.0 and DOCSIS 2.0 + IPv6 standards).

With DS-Lite currently available only on a very specific subset of CPE devices and A+P not having even a proof-of-concept code, sadly LSN (either in NAT44 or NAT444 environment) seems to be the only viable option for the moment.

About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy