IP Network Address Translator (NAT) Terminology and Considerations
RFC 2663

Document Type RFC - Informational (August 1999; Errata)
Authors Matt Holdrege  , Pyda Srisuresh 
Last updated 2020-01-21
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 2663 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       P. Srisuresh
Request for Comments: 2663                                   M. Holdrege
Category: Informational                              Lucent Technologies
                                                             August 1999

    IP Network Address Translator (NAT) Terminology and Considerations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


   The motivation behind this document is to provide clarity to the
   terms used in conjunction with Network Address Translators.  The term
   "Network Address Translator" means different things in different
   contexts. The intent of this document is to define the various
   flavors of NAT and standardize the meaning of terms used.

   The authors listed are editors for this document and owe the content
   to contributions from members of the working group. Large chunks of
   the document titled, "IP Network Address Translator (NAT)" were
   extracted almost as is, to form the initial basis for this document.
   The editors would like to thank the authors Pyda Srisuresh and Kjeld
   Egevang for the same. The editors would like to thank Praveen
   Akkiraju for his contributions in describing NAT deployment
   scenarios. The editors would also like to thank the IESG members
   Scott Bradner, Vern Paxson and Thomas Narten for their detailed
   review of the document and adding clarity to the text.


   Network Address Translation is a method by which IP addresses are
   mapped from one realm to another, in an attempt to provide
   transparent routing to hosts. Traditionally, NAT devices are used to
   connect an isolated address realm with private unregistered addresses
   to an external realm with globally unique registered addresses. This
   document attempts to describe the operation of NAT devices and the
   associated considerations in general, and to define the terminology
   used to identify various flavors of NAT.

Srisuresh & Holdrege         Informational                      [Page 1]
RFC 2663           NAT Terminology and Considerations        August 1999

1. Introduction and Overview

   The need for IP Address translation arises when a network's internal
   IP addresses cannot be used outside the network either because they
   are invalid for use outside, or because the internal addressing must
   be kept private from the external network.

   Address translation allows (in many cases, except as noted in
   sections 8 and 9) hosts in a private network to transparently
   communicate with destinations on an external network and vice versa.
   There are a variety of flavors of NAT and terms to match them. This
   document attempts to define the terminology used and to identify
   various flavors of NAT. The document also attempts to describe other
   considerations applicable to NAT devices in general.

   Note, however, this document is not intended to describe the
   operations of individual NAT variations or the applicability of NAT

   NAT devices attempt to provide a transparent routing solution to end
   hosts trying to communicate from disparate address realms. This is
   achieved by modifying end node addresses en-route and maintaining
   state for these updates so that datagrams pertaining to a session are
   routed to the right end-node in either realm. This solution only
   works when the applications do not use the IP addresses as part of
   the protocol itself. For example, identifying endpoints using DNS
   names rather than addresses makes applications less dependent of the
   actual addresses that NAT chooses and avoids the need to also
   translate payload contents when NAT changes an IP address.

   The NAT function cannot by itself support all applications
   transparently and often must co-exist with application level gateways
   (ALGs) for this reason. People looking to deploy NAT based solutions
   need to determine their application requirements first and assess the
   NAT extensions (i.e., ALGs) necessary to provide application
   transparency for their environment.

   IPsec techniques which are intended to preserve the Endpoint
   addresses of an IP packet will not work with NAT enroute for most
   applications in practice. Techniques such as AH and ESP protect the
   contents of the IP headers (including the source and destination
   addresses) from modification. Yet, NAT's fundamental role is to alter
   the addresses in the IP header of a packet.

2. Terminology and concepts used

   Terms most frequently used in the context of NAT are defined here for

Srisuresh & Holdrege         Informational                      [Page 2]
RFC 2663           NAT Terminology and Considerations        August 1999
Show full document text