As we move to IPv6, will we look back on NAT as a major reason for the Internet’s growth, or a stop-gap measure that became an impediment to progress?

The debates are raging over whether or not we should migrate to IPv6. The strongest argument is the enormous address space that will allow for everyone and everything to have a unique public address, many addresses actually. It is often said that the shortage of public IPv4 addresses has limited our capabilities because it led to the pervasive use of private addressing, Network Address Translation (NAT) and Port Address Translation (PAT). Though these technologies remain critical, they are often regarded as stop-gap measures, and they sometimes create problems. In some circles, NAT has acquired a very bad name. But is that a fair perspective of the technology? Let’s review the positives and negatives.

Note: In this discussion we are speaking of dynamic many-to-1 NAT/PAT. 1-to-1 static NAT is not relevant here because it is not deployed to save address space. For simplicity, we will refer to dynamic NAT/PAT as NAT.

The Downsides

NAT indeed has its issues. First of all, it is yet another bit of configuration that complicates your network. Granted, NAT has been around a long time and is fairly easy to implement. But a network configuration would be simpler without it.

Secondly, NAT can be processor intensive. The router or firewall performing NAT has its memory and processing limits. Typically you would rather it use these resources for its primary functions such as routing packets, running routing protocols or performing stateful packet inspection. A router or firewall performing NAT can fail if the NAT tables grow too large. Even if you do a good job of calculating the maximum NAT load that your user community will normally generate, you can’t account for DOS attacks or viruses on PCs that generate an abnormal amount of sessions through the NAT gateway.

I have personally witnessed a broadband Internet access service fail and its subscribers experience outages when NAT routers became overloaded and crashed. The customer backlash that occurred triggered a change in the architecture to public addressing, eliminating NAT.

Third, NAT inherently reduces network resiliency and increases the chance that a user’s session may be interrupted. Despite the recent availability of stateless NAT, most NAT deployments are stateful. Traffic that goes through the NAT gateway must have its return traffic pass through the same gateway. Routing and failover must be designed to accommodate this traffic symmetry requirement. If the NAT gateway fails (for any reason, not just NAT-related reasons), it does not matter if there is enough network redundancy to provide an alternate path. The translations for existing sessions would be lost and user sessions interrupted.

Fourth, security breaches in a NAT environment may be harder to trace and mitigate. Many security engineers prefer using private IP addressing with NAT at the Internet gateway because it creates a security boundary; however, the downside is that it can be difficult to trace the origin of an attack when multiple users are mapped to a single IP address. Furthermore, when an attack is occurring the Operations staff may be under pressure to restore service as quickly as possible and may just clear the NAT table or even reboot the NAT device. This act unfortunately clears out some of the vital forensic data needed to trace the attack.

Fifth, NAT is somewhat of a stop-gap measure deployed when the architects would otherwise rather not. In my opinion, an Internet access service that uses NAT for the express purpose of conserving address space, as noble as that may be, or because the ISP could not acquire enough public address space, is in a sense an inferior product built on an unfortunate compromise. I am aware that the majority of home broadband services use private addressing with a NAT gateway typically at the ISP’s POP, and to the average person the whole process is transparent. But such deployments are still built on an engineering compromise. If public addresses were plentiful, broadband services would use them.

Lastly, NAT has problems with applications that use the original IP addresses within the application itself. Session Initiation Protocol (SIP) and Simple Network Management Protocol (SNMP) are examples. The original IP address is embedded in the application datagram, after which the network address gets translated. The end system sees a mismatch between the new (translated) network address and the original address used in the application. This can cause the application to fail or at least cause confusion. Sure, there are always workarounds such as Application Layer Gateway (ALG) functionality built into NAT. But, again, you are compromising your architecture and complicating things.

It is also worth noting that some Internet subscribers are behind multiple NAT gateways. In such a case, all aforementioned issues are multiplied, and often ALG workarounds do not work.

So there are some of the issues. I probably have not captured them all. At this point even someone who is anti-NAT may be saying, “wow, where’s the love?”

The Upsides

Now for NAT’s defense.

NAT should be regarded as one of the best networking technologies ever created. Yes, one of the best ever. Despite its issues, it is fair to say that without NAT the Internet would be nowhere near as pervasive as it is today. Either that, or that IPv4 addresses would truly have been depleted around 1998 and we would be knee-deep in IPv6 by now.

NAT allows for enterprises with hundreds or thousands of users to reach the Internet. Most enterprises cannot acquire enough public addresses from their ISP (or RIR) to cover all internal users. With just a small block of public addresses (or even just one address) assigned from its ISP, an enterprise with a privately-addressed network can provide Internet access.

NAT allowed for the birth of many ISPs that could provide Internet access without enough public addresses to fully cover its subscriber base. Without NAT, an ISP may not have been able to deploy its service at all, or at least not grow it as quickly.

NAT also allowed for millions of residential users to reach the Internet for the first time. Many broadband subscribers are still using private IP addresses.

Overall, NAT allowed for the Internet to grow in leaps and bounds. While it was intended to be a short-term stop-gap measure, its lifetime continues. It may be fair to say that this is unfortunate because it allowed for IPv6 deployment to be deferred and, as a result, IPv6 did not benefit from the build-it-and-they-will-come mentality and funding of the dot com boom. Otherwise IPv6 may be prevalent today. But so many other developments were occurring, it may have been too much to accommodate IPv6 in the late 90’s as well.

Conclusions

I believe that it will be unfair to look back on NAT in any less than favorable manner. It has its issues and its time has come for retirement. But make no mistake; NAT was (and still is) one of the most important networking technologies we’ve seen. The Internet would not be where it is today without it.

Epilogue

As IPv6 takes hold, NAT will run its course and recede into memory. But don’t breathe a sigh of relief just yet. The transition to IPv6 and the temporary (indefinite?) coexistence with IPv4 will require the use of translation-based transition mechanisms. These translation mechanisms will be a part of our networks for the better part of the next decade. Old habits die hard.