Network address translation

In computer networking, network address translation (NAT) is the process of modifying network address information in datagram packet headers while in transit across a traffic routing device for the purpose of remapping a given address space into another. Most often today, NAT is used in conjunction with network masquerading (or IP masquerading) which is a technique that hides an entire address space, usually consisting of private network addresses (RFC 1918), behind a single IP address in another, often public address space. This mechanism is implemented in a routing device that uses stateful translation tables to map the "hidden" addresses into a single address and then rewrites the outgoing Internet Protocol (IP) packets on exit so that they appear to originate from the router. In the reverse communications path, responses are mapped back to the originating IP address using the rules ("state") stored in the translation tables.

The translation table rules established in this fashion are flushed after a short period without new traffic refreshing their state. As described, the method enables communication through the router only when the conversation originates in the masqueraded network, since this establishes the translation tables. For example, a web browser in the masqueraded network can browse a website outside, but a web browser outside could not browse a web site in the masqueraded network.

However, most NAT devices today allow the network administrator to configure translation table entries for permanent use. This feature is often referred to as "static NAT" or port forwarding and allows traffic originating in the 'outside' network to reach designated hosts in the masqueraded network. Because of the popularity of this technique (see below), the term NAT has become virtually synonymous with the method of IP masquerading. Network address translation has serious consequences (Drawbacks, Benefits) on the quality of Internet connectivity and requires careful attention to the details of its implementation.

As a result, many methods have been devised to alleviate the issues encountered. See article on NAT traversal. n the mid-1990s NAT became a popular tool for alleviating the IPv4 address exhaustion. It has become a standard, indispensable feature in routers for home and small-office Internet connections. Most systems using NAT do so in order to enable multiple hosts on a private network to access the Internet using a single public IP address (see gateway).

However, NAT breaks the originally envisioned model of IP end-to-end connectivity across the Internet, introduces complications in communication between hosts, and affects performance. NAT obscures an internal network's structure: all traffic appears to outside parties as if it originated from the gateway machine. Network address translation involves re-writing the source and/or destination IP addresses and usually also the TCP/UDP port numbers of IP packets as they pass through the NAT. Checksums (both IP and TCP/UDP) must also be rewritten to take account of the changes. In a typical configuration, a local network uses one of the designated "private" IP address subnets (the RFC 1918).

Private Network Addresses are 192.168.x.x, 172.16.x.x through 172.31.x.x, and 10.x.x.x (or using CIDR notation, 192.168/16, 172.16/12, and 10/8), and a router on that network has a private address (such as 192.168.0.1) in that address space. The router is also connected to the Internet with a single "public" address (known as "overloaded" NAT) or multiple "public" addresses assigned by an ISP. As traffic passes from the local network to the Internet, the source address in each packet is translated on the fly from the private addresses to the public address(es).

The router tracks basic data about each active connection (particularly the destination address and port). When a reply returns to the router, it uses the connection tracking data it stored during the outbound phase to determine where on the internal network to forward the reply; the TCP or UDP client port numbers are used to demultiplex the packets in the case of overloaded NAT, or IP address and port number when multiple public addresses are available, on packet return. To a system on the Internet, the router itself appears to be the source/destination for this traffic.

There are two levels of network address translation. Basic NAT. This involves IP address translation only, not port mapping. PAT (Port Address Translation). Also called simply "NAT" or "Network Address Port Translation, NAPT".

This involves the translation of both IP addresses and port numbers. All internet packets have a source IP address and a destination IP address. Both or either of the source and destination addresses may be translated. Some internet packets do not have port numbers. For example, ICMP packets have no port numbers.

However, the vast bulk of internet traffic is TCP and UDP packets, which do have port numbers. Packets which do have port numbers have both a source port number and a destination port number. Both or either of the source and destination ports may be translated.

NAT which involves translation of the source IP address and/or source port is called source NAT or SNAT. This re-writes the IP address and/or port number of the computer which originated the packet. NAT which involves translation of the destination IP address and/or destination port number is called destination NAT or DNAT. This re-writes the IP address and/or port number corresponding to the destination computer. SNAT and DNAT may be applied simultaneously to internet packets.

NOTE: 'PAT', as it is referred to here, is referred to by Cisco as NAT 'overloading', as described in this Howstuffworks article, provided to "Pure NAT", operating on IP alone, may or may not correctly parse protocols that are totally concerned with IP information, such as ICMP, depending on whether the payload is interpreted by a host on the "inside" or "outside" of translation. As soon as the protocol stack is climbed, even with such basic protocols as TCP and UDP, the protocols will break unless NAT takes action beyond the network layer. IP has a checksum in each packet header, which provides error detection only for the header. IP datagrams may become fragmented and it is necessary for a NAT to reassemble these fragments to allow correct recalculation of higher level checksums and correct tracking of which packets belong to which connection.

The major transport layer protocols, TCP and UDP, have a checksum that covers all the data they carry, as well as the TCP/UDP header, plus a "pseudo-header" that contains the source and destination IP addresses of the packet carrying the TCP/UDP header. For an originating NAT to successfully pass TCP or UDP, it must recompute the TCP/UDP header checksum based on the translated IP addresses, not the original ones, and put that checksum into the TCP/UDP header of the first packet of the fragmented set of packets. The receiving NAT must recompute the IP checksum on every packet it passes to the destination host, and also recognize and recompute the TCP/UDP header using the retranslated addresses and pseudo-header.

This is not a completely solved problem. One solution is for the receiving NAT to reassemble the entire segment and then recompute a checksum calculated across all packets. Originating host may perform Maximum transmission unit (MTU) path discovery (RFC 1191) to determine the packet size that can be transmitted without fragmentation, and then set the "don't fragment" bit in the appropriate packet header field