Network Address Translators

These have become wide-spread in the Internet since Stevens wrote his book. They generally translate between ``private'' Internet addresses (see RFC 1918 and the note to p. 8) and ``public'' (i.e. non-RFC 1918) addresses, though they don't have to. The following diagram is taken from RFC 2663, a dictionary of Network Address Translation (NAT) terminology.

       \ | /                  .                               /
   +---------------+  WAN     .           +-----------------+/
   |Regional Router|----------------------|Stub Router w/NAT|---
   +---------------+          .           +-----------------+\
                              .                      |        \
                              .                      |  LAN
                              .               ---------------
                        Stub border

The LAN has an RFC 1918 address, which we will call 192.168.1.0. The stub router has an address in this range for its LAN connection (clearly) but a public address on the WAN, say 1.2.3.4. When a host on the LAN (say 192.168.1.1) wishes to browse www.bath.ac.uk (138.38.32.5), its initial TCP SYN packet (see chapter 17) will have some source port number (say 1234) and destination port 80. This packet cannot be sent out on the WAN, since 192.168.1.1 is a private address.

In the simple case, the NAT router changes the IP source address to 1.2.3.4 (updating both the IP header checksum (p. 36) and the TCP checksum, the latter since the IP address is in the pseudo-header -- see section 11.3). The NAT router also remembers that the TCP quad (see p. 255)

$$138.38.32.5\quad 80 \quad 1.2.3.4\quad 1234$$

corresponds to the TCP pseudo-connection

$$138.38.32.5\quad 80 \quad 192.168.1.1\quad 1234.$$

Packets that arrive at 1.2.3.4 (TCP port 1234) are forwarded to 192.168.1.1 port 1234, with the destination address and checksums altered.

If TCP port 1234 on 1.2.3.4 is already in use, then the NAT process has to assign another port number (say 2468), and it then has to remember that

$$138.38.32.5\quad 80 \quad 1.2.3.4\quad 2468$$

corresponds to the TCP pseudo-connection

$$138.38.32.5\quad 80 \quad 192.168.1.1\quad 1234.$$

Packets that arrive at 1.2.3.4 (TCP port 2468) are forwarded to 192.168.1.1 port 1234, with the destination address, port number and checksums altered.

A simplistic NAT as described above will work with many TCP and UDP protocols, but not all. A notorious problem is FTP (chapter 27) since the FTP control connection sends messages containing the IP addresses and port numbers for the data channel. Hence if the NAT router is to support FTP, it most be ``FTP-aware'' -- typically via an Application-Layer Gateway (ALG) that understands the FTP protocol. Contrary to the usual principle that fragmentation and TCP packaging are end-to-end procedures, the NAT will have to assemble fragments, and even TCP segments, to see the complete PORT command.

ICMP is also complicated. To quote RFC 2663:

All ICMP error messages (with the exception of [the] Redirect message type) will need to be modified, when passed through NAT. The ICMP error message types needing NAT modification would include Destination- Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem. NAT should not attempt to modify a Redirect message type.

Changes to ICMP error message will include changes to the original IP packet (or portions thereof) embedded in the payload of the ICMP error message. In order for NAT to be completely transparent to end hosts, the IP address of the IP header embedded in the payload of the ICMP packet must be modified, the checksum field of the same IP header must correspondingly be modified, and the accompanying transport header. The ICMP header checksum must also be modified to reflect changes made to the IP and transport headers in the payload. Furthermore, the normal IP header must also be modified.

RFC 3235 gives guidelines on how to design applications that are NAT-friendly.