Tip

IPv4 to IPv6 translation: Comparing network-ready routing solutions

Continued from: IPv4 address exhaustion: Making the IPv6 transition work

With no usable mechanism in hand to address the IPv4 to IPv6

    Requires Free Membership to View

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 solutions try to avoid migration to IPv6 completely. These include Large Scale NAT (LSN); NAT44, which translates an IPv4 address to another IPv4 address; and NAT444.
  • 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.

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

LSN Availability: Many midsized mobile operators use existing enterprise firewall devices to build high-availability LSN solutions. Cisco recently launched CGSE -- a blade for the CRS series of routers that performs NAT44 operations at speeds exceeding 10 gigabits.

IPv4 to IPv6 translation solutions: NAT444

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.

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

DS-Lite availability: The DS-Lite technology is favored by Comcast, which has already started field trials of various IPv6 solutions. Comcast needs to deploy IPv6 in its access network anyway to manage DOCSIS 2.0/3.0 cable modems The AFTR solution by A10 Networks was tested by Comcast. ISC has developed an open-source AFTR solution in concert with Comcast.

IPv4 to IPv6 translation solutions: The A+P proposal

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.

Back to the beginning: IPv4 address exhaustion: Making the IPv6 transition work

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.


This was first published in July 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.