NAT (Network Address Translation) (Linktionary term)

Site home page
(news and notices)

Get alerts when Linktionary is updated

Book updates and addendums

Get info about the Encyclopedia of Networking and Telecommunicatons, 3rd edition (2001)

Download the electronic version of the Encyclopedia of Networking, 2nd edition (1996). It's free!

Contribute to this site

Electronic licensing info

NAT (Network Address Translation)

Note: Many topics at this site are reduced versions of the text in "The Encyclopedia of Networking and Telecommunications." Search results will not be as extensive as a search of the book's CD-ROM.

Network address translation is a scheme that allows two connected networks to use different and incompatible IP addressing schemes. Address translation allows hosts on a private internal network to transparently communicate with destinations on an external network or vice versa. NAT also refers to the name of a device that performs these functions.

NATs perform transparent routing, which refers to the translation of and routing of datagrams between different address realms. An address realm is typically an inside network that uses its own addressing as compared to the external Internet. Traditional routers route packets within a single address realm.

NAT was introduced with RFC 1631 (The IP Network Address Translator, May 1994) and was developed as a follow-up to supernetting-that is, CIDR (Classless Inter-Domain Routing). Supernetting was first discussed in RFC 1338 (Supernetting: an Address Assignment and Aggregation Strategy, June 1992), which was later replaced with RFC 1519 (Classless Inter-Domain Routing: an Address Assignment and Aggregation Strategy, September 1993). It was developed as a short-term fix to solve the potential problem of IP address depletion and scaling in routing. The long-term fix was intended to be a new Internet protocol with a larger address space, namely IPv6. However, IPv6 deployment is progressing very slowly, so NATs still provide a valuable service. In addition, they have also been recruited into the firewall brigade because of their talents at hiding internal addresses.

Supernetting changed the way that IP addresses were allocated...

This topic continues in "The Encyclopedia of Networking and Telecommunications."

One of the big concerns with NAT is the loss of transparency, which is the Internet concept of a single universal logical addressing scheme and the mechanisms by which packets may flow from source to destination essentially unaltered. This is discussed in RFC 2775 (Internet Transparency, February 2000). Other problems are outlined in the RFCs listed later. In particular, RFC 3027 (Protocol Complications with the IP Network Address Translator, January 2001) identifies protocols that do not work well with NAT.

An Internet protocol called RSIP (Realm-Specific Internet Protocol) solves some of the address problems of IPv4 and provides better support for multimedia. The IETF has stated that RSIP is a replacement for NAT (network address translation) and a potential alternative to IPv6. At the same time, RSIP provides a transition path to IPv6 for organizations that implement it.

Two IETF Working Groups are working on NAT:

Network Address Translators (nat) This group is working to define NAT operations, limitations of NAT, and the impact of NAT operation on Internet protocols and applications. RSIP is being developed by this group. The group is located at http://www.ietf.org/html.charters/nat-charter.html.

Middlebox Communication (midcom) This IETF group uses the term "middlebox" to refer to devices that enforce transport policy, such as firewalls and NATs. These devices need to identify the applications related to datagrams. This requires application-level intelligence. The midcom group is specifying an architecture and framework in which this intelligence is moved to a "midcom agent" which assists the middlebox in its task. By decoupling the application intelligence from the middlebox, complexity is removed and updates are easier. See http://www.ietf.org/html.charters/midcom-charter.html.

The following RFCs provide information about NAT:

RFC 1631 (The IP Network Address Translator, May 1994)

RFC 2401 (Security Architecture for the Internet Protocol, November 1998)

RFC 2663 (IP Network Address Translator Terminology and Considerations, August 1999)
RFC 2694 (DNS extensions to Network Address Translators, September 1999)

RFC 2709 (Security Model with Tunnel-mode IPsec for NAT Domains, October 1999)

RFC 2766 (Network Address Translation - Protocol Translation, February 2000)

RFC 2775 (Internet Transparency, February 2000)

RFC 2993 (Architectural Implications of NAT, November 2000)

RFC 3022 (Traditional IP Network Address Translator, January 2001)

RFC 3027 (Protocol Complications with the IP Network Address Translator, January 2001)