What's Wrong with NAT

What's wrong with NAT?

NAT is often proposed as a supposedly-viable alternative to IPv6 deployment. NAT was an attempt to mitigate IPv4 address depletion, to give us time to migrate to IPv6, but not to replace IPv6. As the number of devices connected to the Internet grows, the Internet needs more addresses. IPv6 generally removes the need for any NAT at all, whereas more NAT breaks more applications. Still, what's wrong with NAT?

1. NAT is not security.
   
   NAT is life-support for IPv4 that's running out of available address space, first described in RFC 1631. Tackling the common myth first, NAT has nothing to do with security. NAT adds obscurity and complexity, but not security.


2. NAT breaks a basic Internet assumption.
   
   Quoting Wikipedia,
   

   The end-to-end principle is a classic design principle of computer networking, first explicitly articulated in a 1981 conference paper by Saltzer, Reed, and Clark.
   
   The end-to-end principle states that application-specific functions ought to reside in the end hosts of a network rather than in intermediary nodes – provided they can be implemented "completely and correctly" in the end hosts. Going back to Baran's work on obtaining reliability from unreliable parts in the early 1960s, the basic intuition behind the original principle is that the payoffs from adding functions to the network quickly diminish, especially in those cases where the end hosts will have to re-implement functions for reasons of "completeness and correctness" anyway (regardless of the efforts of the network).

   
   The enduring power of the end-to-end argument is that many applications implicitly assume it of the underlying network connection, leading to the next point.


3. NAT breaks many aspects of Internet connectivity.
   
   Since NAT changes the address in packet headers, it breaks any application that relies on packet headers to have the correct address. But that's not all that NAT breaks! There's a list of what NAT breaks. If that list isn't daunting enough, adding another layer of NAT with Large Scale NAT breaks even more (as mentioned before).


4. NAT makes network troubleshooting far more difficult!
   
   As if breaking applications wasn't bad enough, NAT makes troubleshooting painful. As mentioned in the first point, NAT adds obscurity (changing addresses and ports) and complexity (tracking down those changes).
   
   At work, I use the phrase "you might as well be doubly NAT'd" to indicate a particularly difficult problem (while making my co-workers laugh). My typically mild-mannered boss raised his voice (!!!) to nix a plan that used NAT. Those of us in Networking don't like NAT; my colleagues in Security don't respect it either. In large enterprise environments like our load balancer, we need a range of addresses so we don't encounter ephemeral port exhaustion (more about it). The only way to troubleshoot any problems there is to have full access to the logs. Not all of our clients have access to the logs (nor should they!), so that means all troubleshooting must be done by someone with clearance, even though many clients would be able to figure it out for themselves.
   
   At home, NAT uses a single public IPv4 address so you can always determine the (single) Internet-facing IP address. However, home users rarely have access to the NAT mapping table or to any logs on any intermediate device, forcing troubleshooting at home to require more luck than skill.

It's not "what's wrong with NAT?" but "why would you use NAT?" You use NAT when you have an unfortunate requirement for IPv4 and you don't have enough addresses. You use NAT because you have no choice but to use it despite its drawbacks, and despite what it breaks.