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.

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.

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.

Applications That Embed IP Addresses

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!

Additional Issues With Port Translation

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.

Cascading Impact Of Changes To Address Or Port Numbers

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.

Problems With IPSec

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.

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!