Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Internet Layer (OSI Network Layer) Protocols            9  Internet Protocol (IP/IPv4, IPng/IPv6) and IP-Related Protocols (IP NAT, IPSec, Mobile IP)                 9  IP Network Address Translation (NAT) Protocol

IP NAT "Overlapping" / "Twice NAT" Operation 1 IP Security (IPSec) Protocols

In a perfect world, Network Address Translation could be made transparent to the devices using it. We'd like to be able to have a NAT router change IP addresses in request datagrams as they leave the network and change them back in responses that come back and have none of the hosts be any the wiser. Unfortunately, this ain't a perfect world.

It is not possible for NAT to be completely transparent to the devices that use it. There are potential compatibility problems that arise if NAT doesn't perform certain functions that go beyond simply swapping IP addresses and possibly port numbers in the IP header. The main problem is that even though IP addresses are supposedly the domain of the Internet Protocol, they are really used by other protocols as well, both at the network layer and in higher layers. When NAT changes the IP address in an IP datagram, it must often also change addresses in other places to make sure that the addresses in various headers and payloads still match.

These compatibility issues require that even though NAT should theoretically work only at the level of IP at the network layer, in practical terms NAT routers must be “aware” of many more protocols and perform special operations as required. Some are required for all datagrams that are translated, while others only apply to certain datagrams and not others. And even when these techniques are added to NAT routers, some things still may not work properly in a NAT environment.

Most NAT implementations do take these concerns into account. Certainly common applications like FTP are widely supported by NAT routers, or nobody would want to use NAT. That said, there may be some applications that will not work over NAT. The fact that NAT really isn't transparent and must do these extra sorts of “hacks” to other protocol headers and even payloads is a big part of the reason why many people refer to NAT as a “kludge”; elegant solutions don't have so many special cases that need special handling.

Let's take a look at some of the specific issues and requirements.

Changing the IP addresses in the IP header means the IP header checksum must be calculated. Since both UDP or TCP also have checksums, and these checksums are computed over a pseudo header that contains the IP source and destination address as well, they too must be recalculated each time a translation is made.

Since NAT works so intimately with IP headers, and since IP is closely related to its “assistant” protocol ICMP, NAT must also look for certain ICMP messages and make changes to addresses contained within them. Many ICMP messages, such as Destination Unreachable and Parameter Problem contain as data the original IP header of the datagram that led to the ICMP message. Since NAT is translating addresses in IP headers it must watch for these messages and translate addresses in included headers as required.

A number of TCP/IP applications embed IP addresses within the actual application data payload. The most notorious example of this is the TCP/IP File Transfer Protocol (FTP), which actually sends address and port assignments as text information in datagrams between devices during a connection. In order for NAT to support FTP, it must be specifically programmed with algorithms to look for this information and make changes as needed.

The level of complication can go even beyond this. Consider what happens when an FTP message containing these text address or port numbers is fragmented—part of the address to be translated may be in two different IP datagrams, and hard to recognize!

When port-based NAT (PAT) is used, the issues that apply to addresses now apply to ports as well, making even more work for the router to perform.

Take the example of an FTP datagram encoding an IP address that NAT must change. The address being substituted might require more characters than the original; in our first example, 10.0.0.207 (10 ASCII characters) is replaced by 194.54.21.11 (12 ASCII characters). Making this substitution changes the size of the payload! This means that TCP sequence numbers also must be modified.

In these situations, NAT itself is supposed to take care of any additional work that may be required. This is definitely a complication that does not occur without the use of NAT, and is an often-cited example of NAT’s “kludginess”.

When IPSec is used in transport mode, both the Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use an integrity check that is based on the value of the entire payload. When NAT tries to update the TCP or UDP checksum in the IP datagram, this changes the value of data that the receiving device uses in performing the AH or ESP integrity check. The check will fail. Thus, NAT can't be used in IPSec transport mode. It may still work in tunnel mode but there can be complications here as well.

IP NAT "Overlapping" / "Twice NAT" Operation 1 IP Security (IPSec) Protocols