Network address translator: Difference between revisions
imported>Howard C. Berkowitz mNo edit summary |
imported>Howard C. Berkowitz (Started extending; explained TCP/UDP checksum and embedded application) |
||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
A '''network address translator (NAT)''' is a device, or often a software function, which maps [[Internet Protocol]] addresses between two different address spaces, most often, in an [[Internet Protocol version 4]] context, the nonroutable "private" address space and the "public" space in which [[Internet Service Provider]]s communicate. NATs are not ideal solutions for many of their uses, and one of the design goals for [[Internet Protocol version 6]] was to do away with the need for a NAT function. Deployment experience suggests there will still be needs for some NAT-like functions in IPv6, but it is realistic to assume that they will be far less common in an all-IPv6 world. | A '''network address translator (NAT)''' is a device, or often a software function, which maps [[Internet Protocol]] addresses between two different address spaces, most often, in an [[Internet Protocol version 4]] context, the nonroutable "private" address space and the "public" space in which [[Internet Service Provider]]s communicate. NATs are not ideal solutions for many of their uses, and one of the design goals for [[Internet Protocol version 6]] was to do away with the need for a NAT function. Deployment experience suggests there will still be needs for some NAT-like functions in IPv6, but it is realistic to assume that they will be far less common in an all-IPv6 world. | ||
==Basic functionality== | |||
Introduced in 1994, a NAT is a controlled violation of the "end-to-end" architectural principle of the Internet, which assumes addresses are unique from end host to end host. <ref name=RFC1631>{{citation | Introduced in 1994, a NAT is a controlled violation of the "end-to-end" architectural principle of the Internet, which assumes addresses are unique from end host to end host. <ref name=RFC1631>{{citation | ||
| id = RFC1631 | | id = RFC1631 | ||
| Line 8: | Line 8: | ||
| date = May 1994 | | date = May 1994 | ||
| url = http://www.ietf.org/rfc/rfc1631.txt}}</ref> While NAT functions have been extremely useful, they also have created a variety of operational challenges, and one of the goals in developing [[Internet Protocol version 6]] was to do away with the need for NAT service. | | url = http://www.ietf.org/rfc/rfc1631.txt}}</ref> While NAT functions have been extremely useful, they also have created a variety of operational challenges, and one of the goals in developing [[Internet Protocol version 6]] was to do away with the need for NAT service. | ||
Its basic function is to translate the source and destination IP addresses, in the packet header, from one address space to another. In reality, it has to do more than this, since the IPv4 header has an error-detecting checksum that includes the IP addresses. After substituting the addresses, therefore, it has to recompute the checksum. | |||
Most IP packets carry [[Transmission Control Protocol]] (TCP) or [[User Datagram Protocol]] (UDP) payloads. The header of a TCP or UDP "segment" (i.e., a complete TCP or UDP message) also contains a checksum, which is computed on a "pseudo-header" containing not only the TCP/UDP header, but the IP addresses of the packet carrying it. The NAT, therefore, will have to recognize at least TCP and UDP payloads, and, as needed, recompute their checksum. | |||
==Application layer gatewaying== | |||
A number of protocols carried by TCP or UDP, such as [[File Transfer Protocol]] or [[Simple Network Management Protocol]], may have IP addresses embedded in their application-layer messages. Depending on the context, these may or may not need to be translated to the address space to which the packet-level addresses are translated. | |||
The ability to translate embedded IP addresses is beyond the scope of basic NAT. There are cases when they should be translated, as when going between two cooperating public address spaces. If the packet is being [[tunneling protocols|tunneled]] across the public Internet, the architecture may require that they ''not'' be translated. | |||
Devices that are aware of application-layer protocols and can be configured to translate, or not translate, embedded protocols are called [[application layer gateway]]s. | |||
==Advanced IPv4 NAT== | |||
==References== | ==References== | ||
{{reflist}} | {{reflist}} | ||
Revision as of 14:33, 15 October 2009
A network address translator (NAT) is a device, or often a software function, which maps Internet Protocol addresses between two different address spaces, most often, in an Internet Protocol version 4 context, the nonroutable "private" address space and the "public" space in which Internet Service Providers communicate. NATs are not ideal solutions for many of their uses, and one of the design goals for Internet Protocol version 6 was to do away with the need for a NAT function. Deployment experience suggests there will still be needs for some NAT-like functions in IPv6, but it is realistic to assume that they will be far less common in an all-IPv6 world.
Basic functionality
Introduced in 1994, a NAT is a controlled violation of the "end-to-end" architectural principle of the Internet, which assumes addresses are unique from end host to end host. [1] While NAT functions have been extremely useful, they also have created a variety of operational challenges, and one of the goals in developing Internet Protocol version 6 was to do away with the need for NAT service.
Its basic function is to translate the source and destination IP addresses, in the packet header, from one address space to another. In reality, it has to do more than this, since the IPv4 header has an error-detecting checksum that includes the IP addresses. After substituting the addresses, therefore, it has to recompute the checksum.
Most IP packets carry Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) payloads. The header of a TCP or UDP "segment" (i.e., a complete TCP or UDP message) also contains a checksum, which is computed on a "pseudo-header" containing not only the TCP/UDP header, but the IP addresses of the packet carrying it. The NAT, therefore, will have to recognize at least TCP and UDP payloads, and, as needed, recompute their checksum.
Application layer gatewaying
A number of protocols carried by TCP or UDP, such as File Transfer Protocol or Simple Network Management Protocol, may have IP addresses embedded in their application-layer messages. Depending on the context, these may or may not need to be translated to the address space to which the packet-level addresses are translated.
The ability to translate embedded IP addresses is beyond the scope of basic NAT. There are cases when they should be translated, as when going between two cooperating public address spaces. If the packet is being tunneled across the public Internet, the architecture may require that they not be translated.
Devices that are aware of application-layer protocols and can be configured to translate, or not translate, embedded protocols are called application layer gateways.
Advanced IPv4 NAT
References
- ↑ K. Egevang, P. Francis. (May 1994), The IP Network Address Translator (NAT), RFC1631