Network address translation

Network address translation is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was initially used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced but could not route the network's address space. It is a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.
As network address translation modifies the IP address information in packets, NAT implementations may vary in their specific behavior in various addressing cases and their effect on network traffic. Vendors of equipment containing NAT implementations do not commonly document the specifics of NAT behavior.

History

version 4 uses 32-bit addresses, capable of uniquely addressing about 4.3 billion devices on the network. By 1992, it became evident that that would not be enough. The 1994 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. By 2004, NAT had become widespread.
The technique also became known as IP masquerading. which suggests a technique that hides an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another, usually public address space. Because of the popularity of this technique to conserve IPv4 address space, the term NAT became virtually synonymous with IP masquerading.
In 1996, port-address translation was introduced, which expanded the translation of addresses to include port numbers.

Basic NAT

The simplest type of NAT provides a one-to-one translation of IP addresses. refers to this type of NAT as basic NAT, also called a one-to-one NAT. In this type of NAT, only the IP addresses, IP header checksum, and any higher-level checksums that include the IP address are changed. Basic NAT can be used to interconnect two IP networks with incompatible addresses.

One-to-many NAT

Most network address translators map multiple private hosts to one publicly exposed IP address.
In a typical configuration, a local network uses one of the designated private IP address subnets. The network has a router having network interfaces on both the private and the public networks. The public address is typically assigned by an Internet service provider. As traffic passes from the private network to the Internet, NAT translates the source address in each packet from a private address to the router's public address. The NAT facility tracks each active connection. When the router receives inbound traffic from the Internet, it uses the connection tracking data obtained during the outbound phase to determine to which private address it should forward the reply.
Packets passing from the private network to the public network will have their source address modified, while packets passing from the public network back to the private network will have their destination address modified. To avoid ambiguity in how replies are translated, further modifications to the packets are required. The vast bulk of Internet traffic uses Transmission Control Protocol or User Datagram Protocol. For these protocols, the port numbers are changed so that the combination of IP address and port number on the returned packet can be unambiguously mapped to the corresponding private network destination. RFC 2663 uses the term network address and port translation for this type of NAT. Other names include port address translation, IP masquerading, NAT overload, and many-to-one NAT. This is the most common type of NAT and has become synonymous with the term NAT in common usage.
This method allows communication through the router only when the conversation originates in the private network, since the initial originating transmission establishes the required information in the translation tables. Thus, a web browser within the private network is able to browse websites that are outside the network, whereas web browsers outside the network are unable to browse a website hosted within. Protocols not based on TCP and UDP require other translation techniques.
The primary benefit of one-to-many NAT is mitigation of IPv4 address exhaustion by allowing entire networks to be connected to the Internet using a single public IP address.

Methods of translation

Network address and port translation may be implemented in several ways. Some applications that use IP address information may need to determine the external address of a network address translator. This is the address that its communication peers in the external network detect. 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.
For this purpose, RFC 3489 specified the protocol Simple Traversal of UDP over NATs in 2003. It classified NAT implementations as full-cone NAT, restricted-cone NAT, port-restricted cone NAT or symmetric NAT, and proposed a methodology for testing a device accordingly. However, these procedures have since been deprecated from standards status, as the methods are inadequate to correctly assess many devices. RFC 5389 standardized new methods in 2008 and the acronym STUN since represents the new title of the specification: Session Traversal Utilities for NAT.

Endpoint-Independent NAT, Full Cone NAT, 1:1/''one-to-one NAT, or NAT 1 Once an internal address is mapped to an external address, any packets from iAddr:iPort are sent through eAddr:ePort. Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.	Image:Full Cone NAT.svg\|right\|400px
Address-Dependent NAT, Restricted Cone NAT, or NAT 2 Once an internal address is mapped to an external address, any packets from iAddr:iPort are sent through eAddr:ePort. An external host can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:any. Any means the port number doesn't matter.	Image:Restricted Cone NAT.svg\|right\|400px
Address- and Port-Dependent NAT, Port Restricted Cone NAT, or NAT 3 Once an internal address is mapped to an external address, any packets from iAddr:iPort are sent through eAddr:ePort. An external host can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:hPort. It is similar to an address restricted cone NAT, but the restriction includes port numbers.	Image:Port Restricted Cone NAT.svg\|right\|400px
Address- and Port-Dependent NAT, Symmetric NAT, or NAT 4 The combination of one internal IP address and a destination IP address and port is mapped to a single unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back.	Image:Symmetric NAT.svg\|right\|400px

As many NAT implementations combine multiple types, it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. For the first bullet in each row of the above table, the RFC would characterize Full-Cone, Restricted-Cone, and Port-Restricted-Cone NATs as having an Endpoint-Independent Mapping, whereas it would characterize a Symmetric NAT as having an Address- and Port-Dependent Mapping. For the second bullet in each row of the above table, RFC 4787 would also label Full-Cone NAT as having an Endpoint-Independent Filtering, Restricted-Cone NAT as having an Address-Dependent Filtering, Port-Restricted Cone NAT as having an Address- and Port-Dependent Filtering, and Symmetric NAT as having either an Address-Dependent Filtering or Address- and Port-Dependent Filtering. 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, and the level of determinism NATs exhibit when applying all these rules. Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping'', where incoming packets addressed to the external address and port are redirected to a specific internal address and port.

NAT mapping vs NAT filtering

RFC 4787 distinguishes between NAT mapping and NAT filtering.
Section 4.1 of the RFC covers NAT mapping and specifies the translation of an external IP address and port number into an internal IP address and port number. It defines endpoint-independent mapping, address-dependent mapping and address- and port-dependent mapping, explains that these three possible choices do not relate to the security of the NAT as security is determined by the filtering behavior and then specifies "A NAT MUST have an 'Endpoint-Independent Mapping' behavior."
Section 5 of the RFC covers NAT filtering and describes the criteria used by the NAT to filter packets originating from specific external endpoints. The options are endpoint-independent filtering, address-dependent filtering and address- and port-dependent filtering. Endpoint-independent filtering is recommended where maximum application transparency is required while address-dependent filtering is recommended where more stringent filtering behavior is most important.
Some NAT devices are not compliant with RFC 4787 as they treat NAT mapping and filtering in the same way, so that their configuration option for changing the NAT filtering method also changes the NAT mapping method.