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
IPaddress 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.

Overview In 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.
Basic NAT and PAT
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
Howstuffworks by Cisco: http://computer.howstuffworks.com/nat3.htm

Types of NAT
Network address translation is implemented in a variety of schemes of translating
addresses and port numbers, each affecting application communication protocols
differently. In some application protocols that use IP address information, the
application running on a node in the masqueraded network needs to determine the
external address of the NAT, i.e., the address that its communication peers detect,
and, furthermore, often needs to examine and categorize the type of mapping in use.
For this purpose, the Simple traversal of UDP over NATs (STUN) protocol was
developed (RFC 3489). It classified NAT implementation as full cone NAT, (address)
restricted cone NAT, port restricted cone NAT or symmetric NAT[1] and proposed a
methodology for testing a device accordingly. However, these procedures have
since been deprecated from standards status, as the methods have proven faulty and
inadequate to correctly assess many devices. New methods have been standardized in
RFC 5389 (2008) and the STUN acronym now represents the new title of the
specification: Session Traversal Utilities for NAT.
This terminology has been the source of much confusion, as it has proven inadequate
at describing real-life NAT behavior.[2] Many NAT implementations combine these
types, and it is therefore better to refer to specific individual NAT behaviors
instead of using the Cone/Symmetric terminology. Especially, most NAT translators
combine symmetric NAT for outgoing connections with static port mapping, where
incoming packets to the external address and port are redirected to a specific
internal address and port. Some products can redirect packets to several internal
hosts, e.g. to divide the load between a few servers. However, this introduces
problems with more sophisticated communications that have many interconnected
packets, and thus is rarely used.
Many NAT implementations follow the port preservation design. For most
communications, they use the same values as internal and external port numbers.
However, if two internal hosts attempt to communicate with the same external host
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 (address) restricted
cone NAT and other times as symmetric NAT.
Dynamic network address translation
Dynamic NAT, just like static NAT, is not common in smaller networks but is found
within larger corporations with complex networks. The way dynamic NAT differs from
static NAT is that where static NAT provides a one-to-one internal to public static
IP address mapping, dynamic NAT doesn't make the mapping to the public IP address
static and usually uses a group of available public IP addresses.

Applications affected by NAT

Some Application Layer protocols (such as FTP and SIP) send explicit network
addresses within their application data. 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 network layer and transport layer
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. The Session Initiation Protocol (SIP) controls Voice over IP
(VoIP) communications and suffers the same problem. SIP may use multiple ports to
set up a connection and transmit voice stream via RTP. IP addresses and port
numbers are encoded in the payload data and must be known prior to the traversal of
NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and
communications may fail.
Application Layer Gateway (ALG) software or hardware may correct these problems. 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.
Other possibilities are UPnP (Universal Plug and Play) or Bonjour (NAT-PMP), but
these require 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 signaling 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.
The DNS protocol vulnerability announced by Dan Kaminsky on 2008 July 8 is
indirectly affected by NAT port mapping. To avoid DNS server cache poisoning, it is
highly desirable to not translate UDP source port numbers of outgoing DNS requests
from any DNS server which is behind a firewall which implements NAT. The
recommended work-around for the DNS vulnerability is to make all caching DNS
servers use randomized UDP source ports. If the NAT function de-randomizes the UDP
source ports, the DNS server will be made vulnerable.
Drawbacks

Hosts behind NAT-enabled routers do not have 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-level gateway (see
below), but fail when both systems are separated from the Internet by NAT. Use of
NAT also complicates tunneling protocols such as IPsec because NAT modifies values
in the headers which interfere with the integrity checks done by IPsec and other
tunneling protocols.
End-to-end connectivity has been a core principle of the Internet, supported for
example by the Internet Architecture Board. Current Internet architectural
documents observe that NAT is a violation of the End-to-End Principle, but that NAT
does have a valid role in careful design.[3] There is considerably more concern
with the use of IPv6 NAT, and many IPv6 architects believe IPv6 was intended to
remove the need for NAT.[4]
Because of the short-lived nature of the stateful translation tables in NAT
routers, devices on the internal network lose IP connectivity typically within a
very short period of time unless they implement NAT keep-alive mechanisms by
frequently accessing outside hosts. This dramatically shortens the power reserves
on battery-operated hand-held devices and has thwarted more widespread deployment
of such IP-native Internet-enabled devices.
Some Internet service providers (ISPs) provide their customers only with "local" IP
addresses.[citation needed]Thus, these customers must access services external to
the ISP's network through NAT. As a result, the customers cannot achieve true end-
to-end connectivity, in violation of the core principles of the Internet as laid
out by the Internet Architecture Board.
Benefits
The primary benefit of IP-masquerading NAT is that it has been a practical solution
to the impending exhaustion of IPv4 address space. Even large networks can be
connected to the Internet with as little as a single IP address. The more common
arrangement is having machines that require end-to-end connectivity supplied with a
routable IP address, while having machines that do not provide services to outside
users behind NAT with only a few IP addresses used to enable Internet access.
Some[5] have also called this exact benefit a major drawback, since it delays the
need for the implementation of IPv6, quote:
"... it is possible that its [NAT] widespread use will significantly delay the need
to deploy IPv6. ... It is probably safe to say that networks would be better off
without NAT, ..."
Examples of NAT software
� IPFilter
� PF (firewall): The OpenBSD Packet Filter.
� Iptables masquerading
� Internet Connection Sharing (ICS)
� WinGate
� Allied Telesis