IP Network Address Translator (NAT) Terminology and Considerations
RFC 2663
|
| Document |
Type |
|
RFC - Informational
(August 1999; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
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.
Preface
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.
Abstract
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
devices.
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
Show full document text