http://www.circleid.com/posts/thoughts_on_ipv6_day/


Brett, 

Below are a number of URLs to documents describing the issues that NAT creates, or how it damages the end-to-end model of the Internet and why that damage is worth avoiding. 

The first one is the most important - it describes why end-to-end is the best way to implement network based services, and why it is the model that has been followed during the design of the Internet. 

END-TO-END ARGUMENTS IN SYSTEM DESIGN 
http://www.reed.com/Papers/EndtoEnd.html

The old telephone network was the opposite of the “end-to-end” architecture, as services were implemented in the network, rather than at the edges. There was a reason for that, now that reason has gone. Building services within the network increases the costs of the network, with one of the major ones being the deployment of new, network based services. 

The end-to-end argument can be summarised as “dumb network, smart hosts”. This paper describes why the Internet architecture ie. end-to-end is better than the “smart network, dumb hosts” model. 

Rise of the Stupid Network 
http://www.hyperorg.com/misc/stupidnet.html

NAT builds both state and application understanding within the network. It moves away from the “dumb network, smart hosts” model. This naturally increases the costs of the network, which the users of that network ultimately end up having to bare. It is not the cheapest or optimal solution to the problem. 

There are a number of documents which either wholy or partly address the implications of NAT. They aren’t necessarily only providing theoretical argments against it, they also provide practical examples of where NAT creates costs that would be best avoided : 

Architectural Implications of NAT 
http://www.ietf.org/rfc/rfc2993.txt

Why are NATs so popular? 
http://www.potaroo.net/papers/isoc/2003-09/nats.html

Things that NATs break 
http://www.cs.utk.edu/~moore/opinions/what-nats-break.html

Anatomy 
http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html

IP Network Address Translator (NAT) Terminology and Considerations 
http://www.ietf.org/rfc/rfc2663.txt

Traditional IP Network Address Translator (Traditional NAT) 
http://www.ietf.org/rfc/rfc3022.txt

NAT also fails the simplicity goal - in addition to modifying the destination or source IP address in each IP packet, it also has to modify the TCP checksum (as the TCP checksum covers a pseudo header which includes the IP addressing information carried in the IP packet header). Also, for protocols such as FTP, which carry IP addresses in text format, the NAT box may have to offset TCP sequence numbers if it has to increase the length of the IP address within the payload eg “10.1.1.1” being expanded to “192.88.20.15” increases the number of characters in the payload, which requires the TCP sequence numbers in the TCP header to be offset / reset as the packet traverses the NAT box. This problem gets real ugly when the “10.1.1.1” is split across two TCP segments, which TCP is quite freely permitted to do. All this is assuming that the NAT box understands the application protocol in the first place. 

More broadly, NAT is really deployed to directly fix “duplicated” or “overlapping” address spaces. Security is not really the reason - a firewall deployed with public address space is as secure. A couple of good links on why duplicated address spaces are worth avoiding. Note that the second is referring to IPv6 “site local” addresses, which are the IPv6 “version” of RFC1918. The same arguments apply to IPv4/RFC1918. I’ve personally been burnt by the VPN issues identified. 

Network 10 Considered Harmful (Some Practices Shouldn’t be Codified) 
http://www.ietf.org/rfc/rfc1627.txt

Deprecating Site Local Addresses 
http://www.ietf.org/rfc/rfc3879.txt

VoIP technology has been around for a long time. Maybe it hasn’t become the next “killer app” because of NAT ? If VoIP could have been deployed just as easily as web browsers were (by end-users downloading it onto their edge-devices, and not having to upgrade their “router” ie. router + NAT box), we may have had cheaper phone calls for the last few years. 

(and yes, I’m the Mark Smith you probably think I am) 
  By Mark Smith | Nov 19, 2004, 03:08 am PST | Link 

I’ve also written about some of my bad experiences with NAT as a comment to the following article, also on this site :
http://www.circleid.com/posts/ip_or_nat_ip_mostly_ip/