Network address translation
The 1994 RFC 1631 describes NAT as a "short-term solution" to the two most compelling problems facing the Internet Protocol at that time: IP address depletion and scaling in routing.
Because of the popularity of this technique to conserve IPv4 address space, the term NAT became virtually synonymous with IP masquerading.
The simplest type of NAT provides a one-to-one translation of IP addresses (RFC 1631).
For these protocols, the port numbers are changed so that the combination of IP address (within the IP header) and port number (within the Transport Layer header) on the returned packet can be unambiguously mapped to the corresponding private network destination.
Furthermore, it may be necessary to examine and categorize the type of mapping in use, for example when it is desired to set up a direct communication path between two clients both of which are behind separate NAT gateways.
RFC 5389 standardized new methods in 2008 and the acronym STUN since represents the new title of the specification: Session Traversal Utilities for NAT.
Other classifications of NAT behavior mentioned in the RFC include whether they preserve ports, when and how mappings are refreshed, whether external mappings can be used by internal hosts (i.e., its hairpinning behavior), and the level of determinism NATs exhibit when applying all these rules.
Both IP address and port number must be correctly known by all hosts wishing to successfully communicate.
A NAT device is similar to a phone system at an office that has one public telephone number and multiple extensions.
PAT uses unique source port numbers on the inside global IP address to distinguish between translations.
Thus avoiding the NAT444 and statefulness problems of carrier-grade NAT, and also provides a transition mechanism for the deployment of native IPv6 at the same time with very little added complexity.
Services that require the initiation of TCP connections from the outside network, or that use 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.
[18] An implementation that only tracks ports can be quickly depleted by internal applications that use multiple simultaneous connections such as an HTTP request for a web page with many embedded objects.
Basic protocols as TCP and UDP cannot function properly unless NAT takes action beyond the network layer.
This is only a one-way solution, because the responding host can send packets of any size, which may be fragmented before reaching the NAT.
DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address.
The meaning of the term SNAT varies by vendor:[19][20][21] Secure network address translation (SNAT) is part of Microsoft's Internet Security and Acceleration Server and is an extension to the NAT driver built into Microsoft Windows Server.
Thus, two-way communication is possible between hosts inside the LAN network via the public IP address.
Use of unique local addresses in combination with network prefix translation can achieve results similar to NAT.
It is not uncommon to be handed a /64 prefix – the smallest recommended subnet – for an entire home network, requiring a variety of techniques to be used to manually subdivide the range for all devices to remain reachable.
[30] Even actual IPv6-to-IPv6 NAT, NAT66, can turn out useful at times: the APNIC blog outlines a case where the author was only provided a single address (/128).
IP addresses and port numbers are encoded in the payload data and must be known before the traversal of NATs.
An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation.
For example, on many Linux systems, there are kernel modules called connection trackers that serve to implement ALGs.
Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or Interactive Connectivity Establishment (ICE), or proprietary approaches in a session border controller.
Most client–server protocols (FTP being the main exception[f]), however, do not send layer 3 contact information and do not require any special treatment by NATs.
In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.
Interactive Connectivity Establishment (ICE) is a NAT traversal technique that does not rely on ALG support.
The DNS protocol vulnerability announced by Dan Kaminsky on July 8, 2008,[33] is indirectly affected by NAT port mapping.
