We have been conditioned to consider NAT as the ugly duckling of the Internet Protocol world. Created as a workaround to the shortage of address space way back in the early 1990s, it came into being at a time when virtually every workstation, every printer, every server got a real and routable IP address. Imagine that. Every machine was reachable from every other machine on the Internet. Talk about feeling exposed!
NAT was simple and elegant. It used the surplus number of TCP ports to share a single IP address. Even absent any IETF established standard, it was seen to meet the needs of end users, and spread throughout the Internet.
NAT worked well for web browsing and email, but posed problems for VOIP and for inbound traffic. But the problems with VOIP were overcome through new methods of NAT traversal like STUN and SIP, and the problems for inbound traffic were ameliorated through the use of rendezvous servers and UPnP. In other words, rather than transfer to IPV6, the market invented mechanisms which increased IPV4’s utility and made it preferable to stay with IPv4 rather than undergo the expense and uncertainties associated with IPv6.
As it turns out, NAT has had some very real benefits that elevated it to its current ubiquity, including its automatic intrusion protection, ease of renumbering, load balancing, and, of course, address conservation. Although NAT is not a firewall, per se, by its nature it protects from inbound threats and provides an easily perceived demarcation between private and public networks. In addition, NAT is easily understood by anyone who is understands TCP/IP, and the value of NAT is so obvious that there are cries to include NAT in IPv6, even though address conservation is not an issue.
We have long been accustomed to the dread of multilevel NAT, also known as Carrier Grade NAT (CGN) or NAT444, despite the clear evidence that multilevel NAT actually works. In fact, much of the traffic today passes through several layers of NAT. You are probably behind a NAT device right now, and your packets are traversing that NAT, passing through the public Internet to another NAT device which passes packets to the web server which is displaying this page to you. This is far from unusual. In the past when we wished to contact a specific machine behind a NAT device, we had to get involved in configuring that NAT device to direct certain inbound traffic on specified TCP ports to specific addresses behind the NAT box. Now rendezvous servers have developed to perform that task without the need to configure NAT. Have you used a remote access product like Logmein orGoToMyPC? You can very easily access your machine, even though it is behind a NAT device in your office, from another office behind a different NAT device, without touching either device. Do you play online games with a game console from your home? You are behind NAT, and so are the players you are competing against. Yet you can play or even talk with them without bothering about configuring the NAT devices in either of your homes. The smart folks at Cisco are including CGN in their most advanced routing platforms. Juniper, too. And the ever-inventive market is moving towards a simple new protocol which will allow for more automated control of NAT devices, called NAT-PCP.