There seems to be a heated debate on this site [for example, here and here] about NAT (network-address translation).
What came as a surprise to me is that a lot of the arguments seem to reside in ideological point of views which obscure the real issues at hand—IP addressing, IP security—and have little to do with NAT’s actual merits or drawbacks.
NAT is not all good
- NAT breaks some protocols, those that have not been designed with NAT in mind. This can require tweaks in NAT implementations to support specific protocols. This is bad because it doesn’t scale well (there are too many protocols in the world to cope with) and obviously you can’t cope with protocols that haven’t been invented yet.
- Security-wise, NAT security is not much better than good IP filtering, and it’s much more limited in its versatility.
- If you want to be a server to the outside world, you need some sort of explicit configuration allowing inbound connections. It’s not always easy, it can’t even always be done, depending on the protocol you want to serve and your equipment.
- Finally, NAT breaks end-to-end connectivity. This is just a fancier and shorter way of saying some of the above. Breaking end-to-end connectivity is not pure evil, but it should always be done with great care about the implications.
NAT is not all bad
- NAT is easy to implement: most entry-level NAT routers are just plug-and-play. It’s much easier than configuring equivalent security with IP filtering.
- In case of a network problem, NAT is easy to diagnose in most cases: if your computer has an address in 192.168.x.x or equivalent and you can still access the Internet, you know you are NATed somewhere. It’s much easier than diagnosing
broken IP filtering.
- NAT saves addresses. Why require 4 or more globally-routable IP addresses from your provider if you only need one of these to be visible from the outside world and you will filter out the others anyway? It’s not only a problem of global address pool exhaustion: it also simplifies address handling both on the provider’s side and the user’s side, thus saving costs. In general this shows up on the monthly bill. For example subnet routing on ADSL connections is at a premium.
- NAT is not the only culprit in preventing servers run by end users. This responsiblity is shared with dynamic IP addressing.
What we should really care about
NAT is really just a tool. It’s not a plot by conglomerates to kill peer-to-peer networking, but it’s not the panacea either.
The important thing is that users should have a choice, and not only regarding whether or not to use NAT.
So the things we really should insist on are:
- encourage connectivity providers to not force NAT on their users. Most of them don’t, anyway. Let’s hope it stays that way: the choice should be the user’s, not the provider’s.
- encourage connectivity providers to provide static IP addresses to users who require these, as an option. There’s a small market for that and we shouldn’t let it shrink, or providers might drop this option from their connectivity packages. This means educating users on the real advantages of static IP addresses—for example, it’s almost required if you want to run your own DNS server.
- encourage connectivity providers to provide IP subnet routing to users, as an option. Same argument as above.
- encourage connectivity providers to not force IP security on their users, again leaving the final choice to the user: you can filter out something you don’t want, but you can’t unfilter something your provider filtered out without your consent. This means encouraging users to handle their security themselves. This in turn means using NAT where it’s easier, using IP filtering where it applies—perhaps by designing network gear that makes IP filtering as easy to configure as NAT currently is.
Most of these points are not new and existed from day one of dialup connectivity, well before NAT was even an idea.
I think that’s a better way of stating the real problems masked behind (pun not intended) NAT, and a clearer way of expressing what objectives really matter for the future: preserving users choice of a real (open, end-to-end) Internet connectivity where they want it, and allowing them to serve content as they see fit.
Nice one, Pierre. Thanks!
The article makes it seem as though users have a mutually exclusive choice—IP filtering or NAT.
Most networks implement both techniques. There’s no way with IPv4 to have as many services on the Internet as there are today w/o NAT—there simply aren?t enough IP addresses.
The article states that NAT breaks certain protocols and destroys end-to-end communication. If the NAT device you’re using is up to par, this should never occur. I’d enjoy some examples of common protocols that break as a consequence of NAT.
I’ve become very anti-NAT over the years, due to both bad personal experiences with it, personal observations and through reading documents written by others that point out it’s flaws.
Before listing them, firstly I’d like to point out that the pro-NAT argument usually is always made with an unstated assumption of single point of connectivity residential Internet access. Once you change that assumption, in any way, the perceived advantages of NAT rapidly disappear.
My personal experiences :
* A 10 000 user network lost Internet access, as the power supply in the single NAT box failed. I’d acknowledge that this isn’t directly a NAT caused problem - redundant Internet connections should have been installed. However, using NAT causes state to be embedded in the network. If redundant NAT boxes were set up, then, to maintain connectivity over a NAT box failure, NAT state information has to be synchronised between the pair of NAT boxes. This may be possible over a proprietory NAT synchronisation protocol, however, the issue then becomes geographical redundancy. Redundant Internet connections shouldn’t be in the same building, if possible. Typically these NAT synchronisation protocols only operate over special cables, that force the redundant NAT boxes to be in the order of 1s or 10s of meters apart. So much for geographical redundancy. Routers, performing stock standard IP routing, and no NAT, would more simply and easily achieve the reasonable levels of redundancy required, including geographical.
* I spent six weeks working on NAT / IPsec VPN solutions, which were very complicated, due to both the number of types of NAT available,and the VPN-NAT/Internet, VPN/Internet-NAT, VPN-NAT/Internet-NAT combinations the customers may have wanted. At the time, I was working for the worlds largest ISP, who is likely to have the largest amount of public address space available. NAT shouldn’t have been necessary for any of their customers.
* The first NAT installation I worked on (before I’d wised up) was back in 1995. The firewall performing NAT didn’t support NATting of NetBIOS, so the customer couldn’t access their internal NetBIOS network over the Internet (remember, this was the early days of the Internet, security wasn’t as much of an issue, IPsec / VPNs weren’t really available).
A few other useful documents that describe the problems with NAT, and why it really should be avoided :
RFC 2993 - Architectural Implications of NAT
Things that NATs break
The Middleware Dilemma
Why are NATs so popular?
Speak Freely - End of Life Announcement
The Digital Imprimatur
I’d encourage those who think NAT is OK to have a read, as I’m looking for converts. If I get enough, I might even have some anti-NAT badges made up, that people can wear on their lapel (or should it be t-shirt) :-)
I believe that certain security requirements should be required of users, and be forced upon them, to prevent the major forms of abuse that is otherwise hard or impossible to mitigate. The most prevalent form right now is viral infections or faulty software operating as open proxies that allows spammers to use machines without the owner even knowing, resulting in a huge ongoing waste of bandwidth which in a few cases even deprives other users of their ability to use the internet.
My suggestion is that providers should block outgoing connections to port 25 destinations, other than their own designated mail servers, by default, unless the customer specifically indicates they will be operating a mail server. That won’t eliminate all problems, as even mail servers can be misconfigured by people whose knowledge of email isn’t much beyond knowing to ask for SMTP to be allowed. But at least it would stop abuses eminating from the vast majority of people who have no idea what SMTP is, or what viruses are, or even what an operating system is.