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 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.
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).
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.
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.
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.
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
Ivan Pepelnjak is chief technology advisor at NIL Data Communications
This article originally appeared on SearchTelecom.com
MORE ARTICLES ON IP ADDRESS, IPV4, IPV6, NAT44, NAT66