NAT first became popular as a way to deal with the IPv4 address shortage and to avoid the difficulty of reserving IP addresses. Use of NAT has proven particularly popular in countries other than the United States, which (for historical reasons) have fewer address-blocks allocated per capita. It has become a standard feature in routers for home and small-office Internet connections, where the price of extra IP addresses would often outweigh the benefits.
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), 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.
Hosts behind a NAT-enabled router do not have true end-to-end connectivity and cannot participate in some Internet protocols. Services that require the initiation of TCP connections from the outside network, or stateless protocols such as those using UDP, can be disrupted. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination. Some protocols can accommodate one instance of NAT between participating hosts ("passive mode" FTP, for example), sometimes with the assistance of an Application Layer Gateway (see below), but fail when both systems are separated from the internet by NAT. Use of NAT also complicates security protocols such as IPsec.
End-to-end connectivity has been a core principle of the Internet, supported for example by the Internet Architecture Board. Some people thus regard NAT as a detriment to the Public Internet. Some internet service providers (ISPs) only provide their customers with "local" IP addresses. Thus, these customers must access services external to the ISP's network through NAT. As a result, some may argue that such companies do not properly provide "Internet" service.
Depending on one's point of view, another drawback of NAT is that it greatly slowed the acceptance of IPv6, relegating it to research networks and limited public use.
In addition to the convenience and low cost of NAT, the lack of full bidirectional connectivity can be regarded in some situations as a "feature", rather than a "limitation". To the extent that NAT depends on a machine on the local network to initiate any connection to hosts on the other side of the router, it prevents malicious activity initiated by outside hosts from reaching those local hosts. This can enhance the reliability of local systems by stopping worms and enhance privacy by discouraging scans. Many NAT-enabled firewalls use this as the core of the protection they provide.
The greatest benefit of NAT is that it is a practical solution to the impending exhaustion of IPv4 address space. Networks that previously required a Class B IP range or a block of Class C network addresses can now be connected to the Internet with as little as a single IP address (many home networks are set up this way). The more common arrangement is having machines that require true bidirectional and unfettered connectivity supplied with a 'real' IP addresses, while having machines that do not provide services to outside users (e.g. a secretary's computer) tucked away behind NAT with only a few IP addresses used to enable Internet access.
Basic NAT vs port number translation
Two kinds of network address translation exist. The type often popularly called simply "NAT" (also sometimes named "Network Address Port Translation" or "NAPT") refers to network address translation involving the mapping of port numbers, allowing multiple machines to share a single IP address. The other, technically simpler, form - also called NAT or "one-to-one NAT" or "basic NAT" or "static NAT" - involves only address translation, not port mapping. This requires an external IP address for each simultaneous connection. Broadband routers often use this feature, sometimes labelled "DMZ host", to allow a designated computer to accept all external connections even when the router itself uses the only available external IP address.
NAT with port-translation comes in two sub-types: source address translation (source NAT), which re-writes the IP address of the computer which initiated the connection; and its counterpart, destination address translation (destination NAT). In practice, both are usually used together in coordination for two-way communication.
Applications affected by NAT
Some higher-layer protocols (such as FTP and SIP) send network layer address information inside application payloads. FTP in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its layer 3 and layer 4 addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address and/or TCP port number makes the information received by the server invalid.
An Application Layer Gateway (ALG) can fix this problem. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs obviously need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG.
Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or ICE or proprietary approaches in a session border controller. NAT traversal is possible in both TCP- and UDP-based applications, but the UDP-based technique is simpler, more widely understood, and more compatible with legacy NATs. In either case, the high level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly-behaved legacy NATs.
Yet another possibility is UPnP (Universal Plug and Play) or Bonjour but this requires the cooperation of the NAT device.
Most traditional client-server protocols (FTP being the main exception), however, do not send layer 3 contact information and therefore do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.
NATs can also cause problems where IPsec encryption is applied and in cases where multiple devices such as SIP phones are located behind a NAT. Phones which encrypt their signalling with IPsec encapsulate the port information within the IPsec packet meaning that NA(P)T devices cannot access and translate the port. In these cases the NA(P)T devices revert to simple NAT operation. This means that all traffic returning to the NAT will be mapped onto one client causing the service to fail. There are a couple of solutions to this problem, one is to use TLS which operates at level 4 in the OSI Reference Model and therefore does not mask the port number, or to Encapsulate the IPsec within UDP - the latter being the solution chosen by TISPAN to achieve secure NAT traversal.
Different types of NAT
Applications that deal with NAT sometimes need to characterize NAT by type. The STUN protocol proposed to characterize Network address translation as Full cone NAT, restricted cone NAT, port restricted cone NAT or symmetric NAT. Note that it is indeed called "cone" and not possibly a type of "clone".
With full cone NAT, also known as one-to-one NAT, all requests from the same internal IP address and port are mapped to the same external IP address and port. An external host can send a packet to the internal host, by sending a packet to the mapped external address.
With restricted cone NAT, all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host can send a packet to the internal host only if the internal host had previously sent a packet to it.
Port restricted cone NAT or symmetric NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet to a particular port on the internal host only if the internal host had previously sent a packet from that port to the external host.
With symmetric NAT all requests from the same internal IP address and port to a specific destination IP address and port are mapped to a unique external source IP address and port. If the same internal host sends a packet with the same source address and port to a different destination, a different mapping is used. Only an external host that receives a packet can send a UDP packet back to the internal host.
This classification is now abandoned, because many NAT implementations oscillate between the various types. For example, many NAT follow a port preservation design. For most communications, they will use the same values as internal and external port numbers. However, if two internal hosts attempt to communicate with the same external hosts using the same port number, the external port number used by the second host will be chosen at random. Such NAT will be sometimes perceived as restricted cone NAT and other times as symmetric NAT.
Other examples of use
- Load Balancing: Destination NAT can redirect connections pointed at some server to randomly selected servers.
- Fail over: Destination NAT can be used to set up a service requiring high availability. If a system involves a critical server accessed through a router, and if the router detects that that server has gone down, it could use destination NAT to transparently re-route a connection to arrive on a backup server.
- Transparent proxying: NAT can redirect HTTP connections targeted at the Internet to a special HTTP proxy which can cache content and filter requests. Some internet service providers use this technique to reduce bandwidth usage without requiring their clients to configure their web browser for proxy support.