Network address translation
53036
224604855
2008-07-09T16:53:18Z
Kbrose
3938795
[[WP:UNDO|Undid]] revision 224597248 by [[Special:Contributions/60.243.159.205|60.243.159.205]] ([[User talk:60.243.159.205|talk]])
In [[computer network]]ing, '''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 [[router|routing device]] that uses [[Stateful firewall|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 only allows transit traffic through the router when it is originating in the masqueraded network, since this establishes the translation tables. However, most NAT devices today allow the network administrator to configure translation tables entries for permanent use. This feature is often referred to as "static NAT" 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 (see below, 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-1990's NAT became a popular tool for alleviating the [[IP address starvation|IPv4 address shortage]]. NAT has proven particularly popular in countries that (for historical reasons) had fewer address space blocks allocated per capita.{{Fact|date=June 2008}} than, for example, the [[United States]]. It has become a standard, indispensable feature in [[router]]s for home and small-office Internet connections.
Most systems using NAT do so in order to enable multiple [[host (network)|host]]s on a [[private network]] to access the [[Internet]] using a single public IP address (see [[gateway (telecommunications)|gateway]]). However, NAT breaks the originally envisioned model of IP [[end-to-end connectivity]] across the Internet and introduces complications in communication between hosts and has performance impacts.
NAT obscures an internal network's structure: all traffic appears to outside parties as if it originates from the gateway machine.
It has been argued that the wide adoption of [[IPv6]] would make NAT unnecessary, as NAT is a method of handling the shortage of the IPv4 address space.
Network address translation involves re-writing the source and/or destination [[IP address]]es and usually also the [[Transmission Control Protocol|TCP]]/[[User Datagram Protocol|UDP]] port numbers of [[Internet Protocol|IP]] [[Packet (information technology)|packet]]s 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 network|"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 [[Classless Inter-Domain Routing|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 [[internet service provider|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 [[Transmission Control Protocol|TCP]] or [[User Datagram Protocol|UDP]] client [[TCP and UDP port|port]] numbers are used to [[multiplexing|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.
=== Drawbacks ===
Hosts behind NAT-enabled routers do not have [[end-to-end connectivity]] and cannot participate in some [[Internet protocol]]s. Services that require the initiation of [[Transmission Control Protocol|TCP]] connections from the outside network, or stateless protocols such as those using [[User Datagram Protocol|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" [[File Transfer Protocol|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 [[tunneling protocol]]s 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.<ref>[http://www.ietf.org/rfc/rfc3439.txt Some Internet Architectural Guidelines and Philosophy],RFC 3439, R. Bush & D. Meyer,December 2002</ref> 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.<ref>[http://tools.ietf.org/rfc/rfc4864.txt Local Network Protection for IPv6],RFC 4864, G. Van de Velde ''et al.'',May 2007</ref>
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 [[Keepalive|keep-alive]] mechanisms by frequently accessing outside hosts. This dramatically shortens the power reserves on battery-operated hand-held devices and has thwarted more wide-spread deployment of such IP-native Internet-enabled devices.
Some [[Internet service provider]]s (ISPs) only provide their customers with "local" IP addresses. {{Fact|date=March 2008}}Thus, these customers must access services external to the ISP's network through NAT. As a result, it may be argued{{Fact|date=March 2008}} that such companies do not properly provide "Internet" service.
=== Benefits ===
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. However, the same benefit can be achieved with a firewall implementation on the routing device. As the growing number of security incidents have shown, NAT does not enhance the reliability of local systems by stopping [[computer worm|worm]]s or computer viruses, nor has it been shown to enhance privacy by discouraging scans of the internet address space. Despite this, many NAT-enabled [[firewall (networking)|firewall]]s use this as the core of the protection they provide.
The greatest benefit of IP-masquerading NAT is that it has been a practical solution to the impending exhaustion of IPv4 address space. Networks that previously required a Class B [[Classful network|IP range]] or a block of Class C network addresses can be connected to the Internet with as little as a single dynamic or static IP address. The more common arrangement is having machines that require true bidirectional and unfettered connectivity supplied with a routable IP address, while having machines that do not provide services to outside users tucked away behind NAT with only a few IP addresses used to enable Internet access.
== Basic NAT and PAT ==
Two kinds of network address translation exist:
* '''[[Port address translation|PAT]] (Port Address Translation)''' - The type popularly, called simply "NAT" (also sometimes named "[[port address translation|Network Address Port Translation, NAPT]]") refers to network address translation involving the mapping of port numbers, allowing multiple machines to share a single IP address.
* '''Basic NAT''' - The other, technically simpler, forms—"one-to-one NAT", "basic NAT", "static NAT" and "pooled NAT"—involve 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.
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
== Basic NAT versus PAT ==
In basic NAT, generally only the IP addresses are modified: There is a 1:1 correspondence between publicly exposed IP addresses and privately held IP addresses. In PAT, both the sender's private IP and port number are modified; the PAT device chooses the port numbers that will be seen by hosts on the public network.
In NAT, incoming packets are routed to their destination IP address on the private network by reference to the incoming source IP address given by the host on the public network. In PAT, there is generally only one publicly exposed IP address and incoming packets from the public network are routed to their destinations on the private network by reference to a table held within the PAT device that keeps track of public and private port pairs. This is often called [[connection tracking]].
== NAT and TCP/UDP ==
"Pure NAT", operating on IP alone, may or may not correctly pass protocols that are totally concerned with IP information, such as [[Internet Control Message Protocol| 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 such [[Transmission Control Protocol| TCP]] and [[User Datagram Protocol| 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.
It may be wise for the originating host to do MTU Path Discovery (RFC 1191) to determine what MTU will go to the end without fragmentation, and then set the "don't fragment" bit in the appropriate packets. There is no totally general solution to this problem, which is why one of the goals of IPv6 is to avoid NAT.
== Applications affected by NAT ==
Some higher-layer protocols (such as [[File Transfer Protocol|FTP]] and [[Session Initiation Protocol|SIP]]) send [[network layer]] address information inside [[Application layer|application]] payloads. [[File Transfer Protocol|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 [[OSI model#Layer 3: Network layer|network layer]] and [[OSI model#Layer 4: Transport layer|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.
An [[Application Layer Gateway]] ([[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 [[Interactive Connectivity Establishment|ICE]] or proprietary approaches in a [[Session Border Controller|session border controller]]. NAT traversal is possible in both TCP- and UDP-based applications, but [[UDP hole punching|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 [[Universal Plug and Play|UPnP]] (Universal Plug and Play) or [[Bonjour (software)|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 [[Session Initiation Protocol|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 [[Transport Layer Security|TLS]] which operates at level 4 in the [[ISO/OSI Reference Model|OSI Reference Model]] and therefore does not mask the port number, or to Encapsulate the IPsec within [[User Datagram Protocol|UDP]] - the latter being the solution chosen by [[TISPAN]] to achieve secure NAT traversal.
== Different types of NAT ==
{{Misleading|section}}
Network address translation is implemented in a variety of schemes of translating addresses and port numbers, each effecting the impact on application communication protocols differently. Some applications that use IP address information in their application protocols need to determine the external address which is used for masquerading, and, furthermore, often need to examine and categories the type of mapping used in a given NAT device.
For this purpose, the [[Simple traversal of UDP over NATs]] (STUN) protocol
was developed. It classified NAT implementation as '''Full cone NAT''', '''restricted cone NAT''', '''port restricted cone NAT''' or '''symmetric NAT'''.<ref>[[STUN]]</ref><ref>[http://list.sipfoundry.org/archive/ietf-behave/pdf00000.pdf NAT Types] (PDF).</ref> 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 are being developed (cf. [http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15 Session Traversal Utilities for (NAT) (STUN)])
{| class="wikitable"
|-
| '''Full cone NAT''', also known as one-to-one NAT
* Once an internal address (iAddr:port1) is mapped to an external address (eAddr:port2), any packets from iAddr:port1 will be sent through eAddr:port2. Any external host can send packets to iAddr:port1 by sending packets to eAddr:port2.
| [[Image:Full Cone NAT.svg|right|400px]]
|-
| '''Address-Restricted cone NAT'''
* Once an internal address (iAddr:port1) is mapped to an external address (eAddr:port2), any packets from iAddr:port1 will be sent through eAddr:port2. An external host (hostAddr:any) can send packets to iAddr:port1 by sending packets to eAddr:port2 only if iAddr:port1 had previously sent a packet to hostAddr:any. "any" means the port number doesn't matter.
| [[Image:Restricted Cone NAT.svg|right|400px]]
|-
| '''Port-Restricted cone NAT'''
Like a '''restricted cone NAT''', but the restriction includes port numbers.
* Once an internal address (iAddr:port1) is mapped to an external address (eAddr:port2), any packets from iAddr:port1 will be sent through eAddr:port2. An external host (hostAddr:port3) can send packets to iAddr:port1 by sending packets to eAddr:port2 only if iAddr:port1 had previously sent a packet to hostAddr:port3.
| [[Image:Port Restricted Cone NAT.svg|right|400px]]
|-
| '''Symmetric NAT'''
* Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a 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]]
|-
|}
This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior.<ref>
{{cite paper
| author = Francois Audet, Cullen Jennings
| title = RFC 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
| publisher = [[IETF]]
| date = January 2007
| url = http://www.ietf.org/rfc/rfc4787.txt
| format = text
| accessdate = 2007-08-29
}}</ref>
Many NAT implementations combine the specified types, and it is therefore better to refer to specific individual [[NAT behavior]]s instead of using the Cone/Symmetric terminology. Especially, most NAT translators combine ''symmetric NAT'' for outgoing connections with a ''static port mapping'' capability. The latter means that all incoming packets to the specific external address and port can be 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 having many interconnected packets and thus is rarely used.
Many NAT implementations follow the '''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 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 '''restricted cone NAT''' and other times as '''symmetric NAT'''.
== See also ==
{{MultiCol}}
* [[Port address translation]] (PAT, can be used in conjunction with NAT)
* [[Firewall (networking)]]
* [[Proxy server]]
* [[Middlebox]]
* [[Routing]]
* [[Gateway (telecommunications)]] <!-- I think more information should be included in this article about gateways and subnets -->
* [[Subnetwork|Subnet]]
* [[IPv6]]
* [[UDP hole punching]]
{{ColBreak}}
* [[AYIYA]] (IPv6 over IPv4 UDP thus working IPv6 tunneling over most NATs)
* [[IPv4 address exhaustion]]
* [[Private IP address]]
* [[Internet Connection Sharing]]
* [[Port forwarding]]
* [[STUN]]: Simple Traversal of UDP over NATs
* [[Teredo tunneling]]: NAT traversal using IPv6
* [[Internet Gateway Device Protocol|Internet Gateway Device (IGD) Protocol]]: UPnP NAT-traversal method
* [[NAT-PT]]
</div>
{{EndMultiCol}}
=== Popular NAT software ===
* [[IPFilter]]
* [[PF (firewall)]]: The OpenBSD Packet Filter.
* [[Netfilter/iptables|Iptables]] masquerading
* [[Berkeley Software Distribution]]
* [[Internet Connection Sharing]] (ICS)
* [[WinGate (computing)|WinGate]]
* [[Cisco IOS]]
== References ==
{{reflist}}
== External links ==
* [http://teledict.blogspot.com/2007/11/introduction-to-nat-network-address.html TeleDict: Introduction to NAT ]
* [http://nutss.net/pub/imc05-tcpnat/ Characterization of different TCP NATs] – Paper discussing the different types of NAT
* [http://www.uct.cl/biblioteca/tesis-on-line/heinz-herlitz/tesis.pdf P2P & NAT connections] (In Spanish [[PDF]])
* [http://forum.emule-project.net/index.php?showtopic=130035 Test the NAT type of your router]A small tool by the [[eMule]] developers to detect the nat type of your router.
* [http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html Anatomy: A Look Inside Network Address Translators – Volume 7, Issue 3, September 2004]
* [http://computer.howstuffworks.com/nat.htm/printable HowStuffWorks: ''How Network Address Translation Works'' by Jeff Tyson]
*[http://www.nattraversal.com/nat-traversal.htm P2P Nat Traversal techniques for IP Communications - White Paper]
* [http://www.newport-networks.com/whitepapers/nat-traversal1.html NAT traversal techniques in multimedia Networks] – White Paper from Newport Networks
* [http://www.brynosaurus.com/pub/net/p2pnat/ Peer-to-Peer Communication Across Network Address Translators] [http://www.brynosaurus.com/pub/net/p2pnat.pdf (PDF)] – NAT traversal techniques for UDP and TCP
* RFC 4008 – Standards Track – Definitions of Managed Objects for Network Address Translators (NAT)
* RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
* RFC 1631 – Obsolete – The IP Network Address Translator (NAT)
* [http://freshmeat.net/projects/nat-traverse/ nat-traverse] – Tool to establish tunnels through NAT gateways without need for reconfiguration of the involved routers
* [http://www.fourmilab.ch/speakfree/unix/ Speak Freely End of Life Announcement] – John Walker's discussion of why he stopped developing a famous program for free internet communication, part of which is directly related to NAT.
* [http://www.newport-networks.com/whitepapers/IPsec-1.html NATs, IPsec and VoIP] – White paper looks at the issues of IPsec and NAT devices and how UDP encapsulation of IPsec solves the problems.
* [http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801af2b9.shtml Cisco IOS NAT Application Layer Gateway]
* [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html natd]
* [http://gluga.com/tech-talk/network-address-translation-nat/ A blog entry explanation of NAT]
* Alternative Taxonomy
** [http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzajw/rzajwstatic.htm Static NAT]
** [http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzajw/rzajwdynamic.htm Dynamic NAT]
** [http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzajw/rzajwaddmasq.htm Masquerade NAT]
* [http://www.phrack.com/issues.html?issue=65&id=5#article Clawing holes in NAT with UPnP]
[[Category:Network Address Translation]]
[[ar:ترجمة عنوان شبكة]]
[[an:Network Address Translation]]
[[bg:NAT]]
[[cs:Network address translation]]
[[da:Network Address Translation]]
[[de:Network Address Translation]]
[[es:Network Address Translation]]
[[fa:برگردان نشانی شبکه]]
[[fr:Network address translation]]
[[ko:네트워크 주소 변환]]
[[id:Network address translation]]
[[it:Network address translation]]
[[he:Network Address Translation]]
[[hu:NAT]]
[[nl:Network address translation]]
[[ja:ネットワークアドレス変換]]
[[no:Network Address Translation]]
[[pl:NAT]]
[[pt:NAT]]
[[ru:NAT]]
[[sr:NAT]]
[[fi:Osoitteenmuunnos]]
[[sv:Network Address Translation]]
[[th:Network address translation]]
[[tr:NAT]]
[[uk:NAT]]
[[zh:网络地址转换]]