NAT - In Depth

Intro

Sometimes, something that can seem like a good idea at the time can have unforeseen consequences. Network Address Translation (NAT) is a perfect example.

A NAT device can translate a single "real" or public IP address into a very large number of private addresses, so a large number of computers can share that single public address. The immediate benefit of NAT is that it allows a single internet connection with a single IP address to be shared.

However, there's a hidden cost: NAT breaks protocols that require incoming connections and protocols that carry IP addresses in them.

An example of this is VoIP: a VoIP application on a computer (a "softphone") or VoIP phone registers with a SIP server, and then the SIP server tells the application or phone when there's an incoming call.The packes that carry the actual conversation are then exchanged directly between the calling parties with no involvement from the server.

But in order to connect, the server must be able to tell each end where to send the VoIP packets. This must be a real, public address, and not the private address the VoIP application thinks it has. And each end must be able to receive those incoming packets, which don't match a prior outgoing session in the NAT.

There are of course ways to make this work, but they require the NAT to be aware of the applications and/or the applications to be aware of the NAT. NAT devices usually have "application layer gateways" (ALGs) for popular protocols that don't normally work through NAT. For instance, a SIP ALG will monitor the traffic between the VoIP application and the SIP server and rewrite the private addresses that it sees there into the NAT's public address and make sure the incoming packets from the remote VoIP application are delivered correctly. Alternatively, the application can use protocols such as the uPnP Internet Gateway protocol or the NAT Port Mapping Protocol (NAT-PMP) to contact the NAT device to obtain the public address and ask the NAT to forward certain incoming packets.

One of the promises of IPv6 is that the almost infinite number of addresses and the better (but not perfect) renumbering makes NAT unnecessary so it will once again be possible to deploy new applications without cumbersome workarounds or random failures that the widespread use of NAT imposes in today's IPv4. The Internet Engineering Task Force (IETF) has traditionally been highly critical of NAT, but despite that, it developed a technique called Network Address Translation - Protocol Translation (NAT-PT, RFC 2766) as a means for hosts that run IPv6 to communicate with hosts that run IPv4. So far, the usual way to deploy IPv6 has been to run IPv4 and IPv6 side-by-side. This is a very useful mechanism for servers that need to be able to talk to both IPv4 and IPv6 clients, but for end-user PCs it makes less sense, as these "dual stack" machines continue to use up the same amount of IPv4 resources as their IPv4-only counterparts. Unfortunately, running IPv6-only would mean only seeing the part of the internet that's IPv6-enabled, which currently is a very small part. This is where NAT-PT comes in: it translates IPv6 packets to IPv4 packets so IPv6-only hosts can still talk to the IPv4-only internet. However, in July of this year RFC 4966 was published which says:

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. The objections to NAT-PT include all the problems caused by NAT, but they're even worse, because ALGs can't simply rewrite addresses since IPv4 addresses and IPv6 addresses have different sizes. IPv6 hosts that use NAT-PT must have their DNS requests passed through an ALG that translates IPv4 addresses into special IPv6 addresses that are routed to the NAT-PT device that performs the translation.

It would of course be rather unpleasant if these specially-crafted DNS replies escape into the wild, where they would confuse IPv6 hosts that don't use the NAT-PT device in question, and dual stack hosts in particular. There are many other issues, such as timeouts, keepalives, incompatibility with DNSSEC and issues with authentication and encryption.

In addition to the list of practical issues, there's also the more fundamental question: do we want the IPv6 internet to inherit the same restrictions that are present in today's IPv4 internet? IPv6 was developed before NAT was in general use, and so far, the assumption has always been that NAT in IPv6 is unnecessary and undesirable. But the use of NAT-PT would pretty much import the IPv4 NAT issues into the IPv6 world. On the other hand, some people argue that the lack of NAT makes it harder to transition to IPv6 because NAT is an integral part of the way that networks are deployed. Taking away this tool would make network operators less willing to deploy the new protocol. However, this could just be "IPv4 thinking". For better or worse, IPv6 is different from IPv4, both as a natural result of the longer addresses and because the IETF used the opportunity to redesign IP to make some improvements unrelated to the address length. Unless ISPs decide to give IPv6 users only a single address like with IPv4, there is won't be any need to use NAT for the majority of all consumers. This implies that it's not a given that the ALGs and other workarounds that make NAT tolerable will be available in IPv6, even if some enterprise users want to stick to NAT when moving to IPv6.