As per Relevance of the word sessions, we have this rfc below:
Network Working Group P.
Request for Comments: 2663 M.
Category: Informational Lucent
August 1999
IP Network Address Translator (NAT) Terminology and
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The motivation behind this document is to provide clarity to
terms used in conjunction with Network Address Translators. The
"Network Address Translator" means different things in
contexts. The intent of this document is to define the
flavors of NAT and standardize the meaning of terms used
The authors listed are editors for this document and owe the
to contributions from members of the working group. Large chunks
the document titled, "IP Network Address Translator (NAT)"
extracted almost as is, to form the initial basis for this document
The editors would like to thank the authors Pyda Srisuresh and
Egevang for the same. The editors would like to thank
Akkiraju for his contributions in describing NAT
scenarios. The editors would also like to thank the IESG
Scott Bradner, Vern Paxson and Thomas Narten for their
review of the document and adding clarity to the text
Network Address Translation is a method by which IP addresses
mapped from one realm to another, in an attempt to
transparent routing to hosts. Traditionally, NAT devices are used
connect an isolated address realm with private unregistered
to an external realm with globally unique registered addresses.
document attempts to describe the operation of NAT devices and
associated considerations in general, and to define the
used to identify various flavors of NAT
Srisuresh & Holdrege Informational [Page 1]
RFC 2663 NAT Terminology and Considerations August 1999
1. Introduction and
The need for IP Address translation arises when a network's
IP addresses cannot be used outside the network either because
are invalid for use outside, or because the internal addressing
be kept private from the external network
Address translation allows (in many cases, except as noted
sections 8 and 9) hosts in a private network to
communicate with destinations on an external network and vice versa
There are a variety of flavors of NAT and terms to match them.
document attempts to define the terminology used and to
various flavors of NAT. The document also attempts to describe
considerations applicable to NAT devices in general
Note, however, this document is not intended to describe
operations of individual NAT variations or the applicability of
devices
NAT devices attempt to provide a transparent routing solution to
hosts trying to communicate from disparate address realms. This
achieved by modifying end node addresses en-route and
state for these updates so that datagrams pertaining to a session
routed to the right end-node in either realm. This solution
works when the applications do not use the IP addresses as part
the protocol itself. For example, identifying endpoints using
names rather than addresses makes applications less dependent of
actual addresses that NAT chooses and avoids the need to
translate payload contents when NAT changes an IP address
The NAT function cannot by itself support all
transparently and often must co-exist with application level
(ALGs) for this reason. People looking to deploy NAT based
need to determine their application requirements first and assess
NAT extensions (i.e., ALGs) necessary to provide
transparency for their environment
IPsec techniques which are intended to preserve the
addresses of an IP packet will not work with NAT enroute for
applications in practice. Techniques such as AH and ESP protect
contents of the IP headers (including the source and
addresses) from modification. Yet, NAT's fundamental role is to
the addresses in the IP header of a packet
2. Terminology and concepts
Terms most frequently used in the context of NAT are defined here
reference
Srisuresh & Holdrege Informational [Page 2]
RFC 2663 NAT Terminology and Considerations August 1999
2.1. Address realm or
An address realm is a network domain in which the network
are uniquely assigned to entities such that datagrams can be
to them. Routing protocols used within the network domain
responsible for finding routes to entities given their
addresses. Note that this document is limited to describing NAT
IPv4 environment and does not address the use of NAT in other
of environment. (e.g. IPv6 environments
2.2. Transparent
The term "transparent routing" is used throughout the document
identify the routing functionality that a NAT device provides.
is different from the routing functionality provided by a
router device in that a traditional router routes packets within
single address realm
Transparent routing refers to routing a datagram between
address realms, by modifying address contents in the IP header to
valid in the address realm into which the datagram is routed
Section 3.2 has a detailed description of transparent routing
2.3. Session flow vs. Packet
Connection or session flows are different from packet flows.
session flow indicates the direction in which the session
initiated with reference to a network interface. Packet flow is
direction in which the packet has traveled with reference to
network interface. Take for example, an outbound telnet session.
telnet session consists of packet flows in both inbound and
directions. Outbound telnet packets carry terminal keystrokes
inbound telnet packets carry screen displays from the telnet server
For purposes of discussion in this document, a session is defined
the set of traffic that is managed as a unit for translation
TCP/UDP sessions are uniquely identified by the tuple of (source
address, source TCP/UDP port, target IP address, target TCP/
port). ICMP query sessions are identified by the tuple of (source
address, ICMP query ID, target IP address). All other sessions
characterized by the tuple of (source IP address, target IP address
IP protocol).
Address translations performed by NAT are session based and
include translation of incoming as well as outgoing packets
to that session. Session direction is identified by the direction
the first packet of that session (see sec 2.5).
Srisuresh & Holdrege Informational [Page 3]
RFC 2663 NAT Terminology and Considerations August 1999
Note, there is no guarantee that the idea of a session, determined
above by NAT, will coincide with the application's idea of a session
An application might view a bundle of sessions (as viewed by NAT)
a single session and might not even view its communication with
peers as a session. Not all applications are guaranteed to
across realms, even with an ALG (defined below in section 2.9)
enroute
2.4. TU ports, Server ports, Client
For the reminder of this document, we will refer TCP/UDP
associated with an IP address simply as "TU ports".
For most TCP/IP hosts, TU port range 0-1023 is used by
listening for incoming connections. Clients trying to initiate
connection typically select a source TU port in the range of 1024-
65535. However, this convention is not universal and not
followed. Some client stations initiate connections using a source
port number in the range of 0-1023, and there are servers
on TU port numbers in the range of 1024-65535.
A list of assigned TU port services may be found in RFC 1700 [Ref 2].
2.5. Start of session for TCP, UDP and
The first packet of every TCP session tries to establish a
and contains connection startup information. The first packet of
TCP session may be recognized by the presence of SYN bit and
of ACK bit in the TCP flags. All TCP packets, with the exception
the first packet, must have the ACK bit set
However, there is no deterministic way of recognizing the start of
UDP based session or any non-TCP session. A heuristic approach
be to assume the first packet with hitherto non-existent
parameters (as defined in section 2.3) as constituting the start
new session
2.6. End of session for TCP, UDP and
The end of a TCP session is detected when FIN is acknowledged by
halves of the session or when either half receives a segment with
RST bit in TCP flags field. However, because it is impossible for
NAT device to know whether the packets it sees will actually
delivered to the destination (they may be dropped between the
device and the destination), the NAT device cannot safely assume
the segments containing FINs or SYNs will be the last packets of
session (i.e., there could be retransmissions). Consequently,
session can be assumed to have been terminated only after a period
Srisuresh & Holdrege Informational [Page 4]
RFC 2663 NAT Terminology and Considerations August 1999
4 minutes subsequent to this detection. The need for this
wait period is described in RFC 793 [Ref 7], which suggests a TIME
WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes
Note that it is also possible for a TCP connection to
without the NAT device becoming aware of the event (e.g., in the
where one or both peers reboot). Consequently, garbage collection
necessary on NAT devices to clean up unused state about TCP
that no longer exist. However, it is not possible in the general
to distinguish between connections that have been idle for
extended period of time from those that no longer exist. In the
of UDP-based sessions, there is no single way to determine when
session ends, since UDP-based protocols are application specific
Many heuristic approaches are used to terminate sessions. You
make the assumption that TCP sessions that have not been used
say, 24 hours, and non-TCP sessions that have not been used for
couple of minutes, are terminated. Often this assumption works,
sometimes it doesn't. These idle period session timeouts vary a
deal both from application to application and for different
of the same application. Consequently, session timeouts must
configurable. Even so, there is no guarantee that a
value can be found. Further, as stated in section 2.3, there is
guarantee that NAT's view of session termination will coincide
that of the application
Another way to handle session terminations is to timestamp
and keep them as long as possible and retire the longest idle
when it becomes necessary
2.7. Public/Global/External
A Global or Public Network is an address realm with unique
addresses assigned by Internet Assigned Numbers Authority (IANA)
an equivalent address registry. This network is also referred
External network during NAT discussions
2.8. Private/Local
A private network is an address realm independent of external
addresses. Private network may also be referred alternately as
Network. Transparent routing between hosts in private realm
external realm is facilitated by a NAT router
RFC 1918 [Ref 1] has recommendations on address space allocation
private networks. Internet Assigned Numbers Authority (IANA)
three blocks of IP address space, namely 10/8, 172.16/12,
192.168/16 set aside for private internets. In pre-CIDR notation,
Srisuresh & Holdrege Informational [Page 5]
RFC 2663 NAT Terminology and Considerations August 1999
first block is nothing but a single class A network number, while
second block is a set of 16 contiguous class B networks, and
third block is a set of 256 contiguous class C networks
An organization that decides to use IP addresses in the address
defined above can do so without coordination with IANA or any
Internet registry such as APNIC, RIPE and ARIN. The address
can thus be used privately by many independent organizations at
same time. However, if those independent organizations later
they wish to communicate with each other or the public Internet,
will either have to renumber their networks or enable NAT on
border routers
2.9. Application Level gateway (ALG
Not all applications lend themselves easily to translation by
devices; especially those that include IP addresses and TCP/UDP
in the payload. Application Level Gateways (ALGs) are
specific translation agents that allow an application on a host
one address realm to connect to its counterpart running on a host
different realm transparently. An ALG may interact with NAT to set
state, use NAT state information, modify application specific
and perform whatever else is necessary to get the application
across disparate address realms
ALGs may not always utilize NAT state information. They may
application payload and simply notify NAT to add additional
information in some cases. ALGs are similar to Proxies, in that,
ALGs and proxies facilitate Application specific
between clients and servers. Proxies use a special protocol
communicate with proxy clients and relay client data to servers
vice versa. Unlike Proxies, ALGs do not use a special protocol
communicate with application clients and do not require changes
application clients
3. What is NAT
Network Address Translation is a method by which IP addresses
mapped from one address realm to another, providing
routing to end hosts. There are many variations of
translation that lend themselves to different applications. However
all flavors of NAT devices should share the
characteristics
Srisuresh & Holdrege Informational [Page 6]
RFC 2663 NAT Terminology and Considerations August 1999
a) Transparent Address assignment
b) Transparent routing through address translation
(routing here refers to forwarding packets, and
exchanging routing information
c) ICMP error packet payload translation
Below is a diagram illustrating a scenario in which NAT is enabled
a stub domain border router, connected to the Internet through
regional router made available by a service provider
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. |
. ---------------
Stub
Figure 1: A typical NAT operation
3.1. Transparent Address
NAT binds addresses in private network with addresses in
network and vice versa to provide transparent routing for
datagrams traversing between address realms. The binding in
cases may extend to transport level identifiers (such as TCP/
ports). Address binding is done at the start of a session.
following sub-sections describe two types of address assignments
3.1.1. Static Address
In the case of static address assignment, there is one-to-one
mapping for hosts between a private network address and an
network address for the lifetime of NAT operation. Static
assignment ensures that NAT does not have to administer
management with session flows
3.1.2. Dynamic Address
In this case, external addresses are assigned to private
hosts or vice versa, dynamically based on usage requirements
session flow determined heuristically by NAT. When the last
using an address binding is terminated, NAT would free the binding
that the global address could be recycled for later use. The
nature of address assignment is specific to individual
implementations
Srisuresh & Holdrege Informational [Page 7]
RFC 2663 NAT Terminology and Considerations August 1999
3.2. Transparent
A NAT router sits at the border between two address realms
translates addresses in IP headers so that when the packet leaves
realm and enters another, it can be routed properly. Because
devices have connections to multiple address realms, they must
careful to not improperly propagate information (e.g., via
protocols) about networks from one address realm into another,
such an advertisement would be deemed unacceptable
There are three phases to Address translation, as follows.
these phases result in creation, maintenance and termination of
for sessions passing through NAT devices
3.2.1. Address
Address binding is the phase in which a local node IP address
associated with an external address or vice versa, for purposes
translation. Address binding is fixed with static address
and is dynamic at session startup time with dynamic
assignments. Once the binding between two addresses is in place,
subsequent sessions originating from or to this host will use
same binding for session based packet translation
New address bindings are made at the start of a new session, if
an address binding didn't already exist. Once a local address
bound to an external address, all subsequent sessions
from the same local address or directed to the same local
will use the same binding
The start of each new session will result in the creation of a
to facilitate translation of datagrams pertaining to the session
There can be many simultaneous sessions originating from the
host, based on a single address binding
3.2.2. Address lookup and
Once a state is established for a session, all packets belonging
the session will be subject to address lookup (and
identifier lookup, in some cases) and translation
Address or transport identifier translation for a datagram
result in the datagram forwarding from the origin address realm
the destination address realm with network addresses
updated
Srisuresh & Holdrege Informational [Page 8]
RFC 2663 NAT Terminology and Considerations August 1999
3.2.3. Address
Address unbinding is the phase in which a private address is
longer associated with a global address for purposes of translation
NAT will perform address unbinding when it believes that the
session using an address binding has terminated. Refer section 2.6
for some heuristic ways to handle session terminations
3.3. ICMP error packet
All ICMP error messages (with the exception of Redirect message type
will need to be modified, when passed through NAT. The ICMP
message types needing NAT modification would include Destination
Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem.
should not attempt to modify a Redirect message type
Changes to ICMP error message will include changes to the original
packet (or portions thereof) embedded in the payload of the
error message. In order for NAT to be completely transparent to
hosts, the IP address of the IP header embedded in the payload of
ICMP packet must be modified, the checksum field of the same
header must correspondingly be modified, and the
transport header. The ICMP header checksum must also be modified
reflect changes made to the IP and transport headers in the payload
Furthermore, the normal IP header must also be modified
4.0. Various flavors of
There are many variations of address translation that lend
to different applications. NAT flavors listed in the following sub
sections are by no means exhaustive, but they do capture
significant differences that abound
The following diagram will be used as a base model to illustrate
flavors. Host-A, with address Addr-A is located in a private realm
represented by the network N-Pri. N-Pri is isolated from
network through a NAT router. Host-X, with address Addr-X is
in an external realm, represented by the network N-Ext. NAT
with two interfaces, each attached to one of the realms
transparent routing between the two realms. The interface to
external realm is assigned an address of Addr-Nx and the interface
private realm is assigned an address of Addr-Np. Further, it may
understood that addresses Addr-A and Addr-Np correspond to N-
network and the addresses Addr-X and Addr-Nx correspond to N-
network
Srisuresh & Holdrege Informational [Page 9]
RFC 2663 NAT Terminology and Considerations August 1999
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-
| (Addr-X
|(Addr-Nx
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A
Figure 2: A base model to illustrate NAT terms
4.1. Traditional NAT (or) Outbound
Traditional NAT would allow hosts within a private network
transparently access hosts in the external network, in most cases
In a traditional NAT, sessions are uni-directional, outbound from
private network. This is in contrast with Bi-directional NAT,
permits sessions in both inbound and outbound directions. A
description of Bi-directional NAT may be found in section 4.2.
The following is a description of the properties of realms
by traditional NAT. IP addresses of hosts in external network
unique and valid in external as well as private networks. However
the addresses of hosts in private network are unique only within
private network and may not be valid in the external network.
other words, NAT would not advertise private networks to the
realm. But, networks from the external realm may be advertised
the private network. The addresses used within private network
not overlap with the external addresses. Any given address
either be a private address or an external address; not both
Srisuresh & Holdrege Informational [Page 10]
RFC 2663 NAT Terminology and Considerations August 1999
A traditional NAT router in figure 2 would allow Host-A to
sessions to Host-X, but not the other way around. Also, N-Ext
routable from within N-Pri, whereas N-Pri may not be routable
N-Ext
Traditional NAT is primarily used by sites using private
that wish to allow outbound sessions from their site
There are two variations to traditional NAT, namely Basic NAT
NAPT (Network Address Port Translation). These are discussed in
following sub-sections
4.1.1. Basic
With Basic NAT, a block of external addresses are set aside
translating addresses of hosts in a private domain as they
sessions to the external domain. For packets outbound from
private network, the source IP address and related fields such as IP
TCP, UDP and ICMP header checksums are translated. For
packets, the destination IP address and the checksums as listed
are translated
A Basic NAT router in figure 2 may be configured to translate N-
into a block of external addresses, say Addr-i through Addr-n
selected from the external network N-Ext
4.1.2. Network Address Port Translation (NAPT
NAPT extends the notion of translation one step further by
translating transport identifier (e.g., TCP and UDP port numbers
ICMP query identifiers). This allows the transport identifiers of
number of private hosts to be multiplexed into the
identifiers of a single external address. NAPT allows a set of
to share a single external address. Note that NAPT can be
with Basic NAT so that a pool of external addresses are used
conjunction with port translation
For packets outbound from the private network, NAPT would
the source IP address, source transport identifier and related
such as IP, TCP, UDP and ICMP header checksums. Transport
can be one of TCP/UDP port or ICMP query ID. For inbound packets,
destination IP address, destination transport identifier and the
and transport header checksums are translated
Srisuresh & Holdrege Informational [Page 11]
RFC 2663 NAT Terminology and Considerations August 1999
A NAPT router in figure 2 may be configured to translate
originated from N-Pri into a single external address, say Addr-i
Very often, the external interface address Addr-Nx of NAPT router
used as the address to map N-Pri to
4.2. Bi-directional NAT (or) Two-Way
With a Bi-directional NAT, sessions can be initiated from hosts
the public network as well as the private network. Private
addresses are bound to globally unique addresses, statically
dynamically as connections are established in either direction.
name space (i.e., their Fully Qualified Domain Names) between
in private and external networks is assumed to be end-to-end unique
Hosts in external realm access private realm hosts by using DNS
address resolution. A DNS-ALG must be employed in conjunction
Bi-Directional NAT to facilitate name to address mapping
Specifically, the DNS-ALG must be capable of translating
realm addresses in DNS Queries and responses into their
realm address bindings, and vice versa, as DNS packets
between private and external realms
The address space requirements outlined for traditional NAT
are applicable here as well
A Bi-directional NAT router in figure 2 would allow Host-A
initiate sessions to Host-X, and Host-X to initiate sessions
Host-A. Just as with traditional NAT, N-Ext is routable from
N-Pri, but N-Pri may not be routable from N-Ext
4.3. Twice
Twice NAT is a variation of NAT in that both the source
destination addresses are modified by NAT as a datagram
address realms. This is in contrast to Traditional-NAT and Bi
Directional NAT, where only one of the addresses (either source
destination) is translated. Note, there is no such term as 'Once
NAT'.
Twice NAT is necessary when private and external realms have
collisions. The most common case where this would happen is when
site had (improperly) numbered its internal nodes using
addresses that have been assigned to another organization
Alternatively, a site may have changed from one provider to another
but chosen to keep (internally) the addresses it had been assigned
the first provider. That provider might then later reassign
addresses to someone else. The key issue in such cases is that
address of the host in the external realm may have been assigned
Srisuresh & Holdrege Informational [Page 12]
RFC 2663 NAT Terminology and Considerations August 1999
same address as a host within the local site. If that address were
appear in a packet, it would be forwarded to the internal node
than through the NAT device to the external realm. Twice-NAT
to bridge these realms by translating both source and
address of an IP packet, as the packet transitions realms
Twice-NAT works as follows. When Host-A wishes to initiate a
to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts
DNS query, and in the response returned to Host-A the DNS-
replaces the address for Host-X with one that is properly routable
the local site (say Host-XPRIME). Host A then initiates
with Host-XPRIME. When the packets traverse the NAT device,
source IP address is translated (as in the case of traditional NAT
and the destination address is translated to Host-X. A
translation is performed on return packets coming from Host-X
The following is a description of the properties of realms
by Twice-NAT. Network address of hosts in external network are
in external networks, but not within private network. Likewise,
network address of hosts in private network are unique only
the private network. In other words, the address space used
private network to locate hosts in private and public networks
unrelated to the address space used in public network to locate
in private and public networks. Twice NAT would not be allowed
advertise local networks to the external network or vice versa
A Twice NAT router in figure 2 would allow Host-A to
sessions to Host-X, and Host-X to initiate sessions to Host-A
However, N-Ext (or a subset of N-Ext) is not routable from within N
Pri, and N-Pri is not routable from N-Ext
Twice NAT is typically used when address space used in a
network overlaps with addresses used in the Public space.
example, say a private site uses the 200.200.200.0/24 address
which is officially assigned to another site in the public internet
Host_A (200.200.200.1) in Private space seeks to connect to Host_
(200.200.200.100) in Public space. In order to make this
work, Host_X's address is mapped to a different address for Host_
and vice versa. The twice NAT located at the Private site border
be configured as follows
Srisuresh & Holdrege Informational [Page 13]
RFC 2663 NAT Terminology and Considerations August 1999
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Datagram flow : Host_A(Private) -> Host_X(Public
a) Within private
DA: 172.16.1.100 SA: 200.200.200.1
b) After twice-NAT
DA: 200.200.200.100 SA: 138.76.28.1
Datagram flow Host_X (Public) -> Host_A (Private
a) Within Public
DA: 138.76.28.1 SA: 200.200.200.100
b) After twice-NAT translation, in private
SA: 200.200.200.1 DA: 172.16.1.100
4.4. Multihomed
There are limitations to using NAT. For example, requests
responses pertaining to a session must be routed via the same
router, as a NAT router maintains state information for
established through it. For this reason, it is often suggested
NAT routers be operated on a border router unique to a stub domain
where all IP packets are either originated from the domain
destined to the domain. However, such a configuration would turn
NAT router into a single point of failure
In order for a private network to ensure that connectivity
external networks is retained even as one of the NAT links fail,
is often desirable to multihome the private network to same
multiple service providers with multiple connections from the
domain, be it from same or different NAT boxes
For example, a private network could have links to two
providers and the sessions from private hosts could flow through
NAT router with the best metric for a destination. When one of
routers fail, the other could route traffic for all connections
Srisuresh & Holdrege Informational [Page 14]
RFC 2663 NAT Terminology and Considerations August 1999
Multiple NAT boxes or multiple links on the same NAT box, sharing
same NAT configuration can provide fail-safe backup for each other
In such a case, it is necessary for backup NAT device to
state information so that a backup NAT can take on session
transparently when the primary NAT fails. NAT backup becomes simpler
when configuration is based on static maps
5.0. Realm Specific IP (RSIP
"Realm Specific IP" (RSIP) is used to characterize the
of a realm-aware host in a private realm, which assumes realm
specific IP address to communicate with hosts in private or
realm
A "Realm Specific IP Client" (RSIP client) is a host in a
network that adopts an address in an external realm when
to hosts in that realm to pursue end-to-end communication.
generated by hosts on either end in such a setup would be based
addresses that are end-to-end unique in the external realm and do
require translation by an intermediary process
A "Realm Specific IP Server" (RSIP server) is a node resident on
private and external realms, that can facilitate routing of
realm packets within a private realm. These packets may either
been originated by an RSIP client or directed to an RSIP-client
RSIP-Server may also be the same node that assigns external
addresses to RSIP-Clients
There are two variations to RSIP, namely Realm-specific Address
(RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP).
variations are discussed in the following sub-sections
5.1. Realm Specific Address IP (RSA-IP
A Realm Specific Address IP (RSA-IP) client adopts an IP address
the external address space when connecting to a host in
realm. Once an RSA-IP client assumes an external address, no
host in private or external domain can assume the same address,
that address is released by the RSA-IP client
The following is a discussion of routing alternatives that may
pursued for the end-to-end RSA-IP packets within private realm.
approach would be to tunnel the packet to the destination. The
header can be translated by NAT as normal without affecting
addresses used in the internal header. Another approach would be
set up a bi-directional tunnel between the RSA-IP Client and
border router straddling the two address realms. Packets to and
the client would be tunneled, but packets would be forwarded
Srisuresh & Holdrege Informational [Page 15]
RFC 2663 NAT Terminology and Considerations August 1999
normal between the border router and the remote destination. Note
the tunnel from the client TO the border router may not be necessary
You might be able to just forward the packet directly. This
work so long as your internal network isn't filtering packets
on source addresses (which in this case would be external addresses).
As an example, Host-A in figure 2 above, could assume an
Addr-k from the external realm and act as RSA-IP-Client to
end-to-end sessions between Addr-k and Addr-X. Traversal of end-to
end packets within private realm may be illustrated as follows
First method, using NAT router enroute to translate
===================================================
Host-A NAT router Host-
------ ----------- ------
src=Addr-A, Dest=Addr-X>,
src=Addr-k, Dest=Addr-X
----------------------------->
src=Addr-k, Dest=Addr-X>,
src=Addr-k, Dest=Addr-X
--------------------------->
.
.
.
src=Addr-X, Dest=Addr-k>,
src=Addr-X, Dest=Addr-k
<---------------------------------
src=Addr-X, Dest=Addr-A>,
embedding
with src=Addr-X, Dest=Addr-k
<--------------------------------------
Srisuresh & Holdrege Informational [Page 16]
RFC 2663 NAT Terminology and Considerations August 1999
Second method, using a tunnel within private realm
==================================================
Host-A NAT router Host-
------ ----------- ------
src=Addr-A, Dest=Addr-Np>,
src=Addr-k, Dest=Addr-X
----------------------------->
src=Addr-k, Dest=Addr-X
------------------------------->
.
.
.
src=Addr-X, Dest=Addr-k
<--------------------------------
src=Addr-Np, Dest=Addr-A>,
embedding
with src=Addr-X, Dest=Addr-k
<----------------------------------
There may be other approaches to pursue
An RSA-IP-Client has the following characteristics. The
set of operations performed by an RSA-IP-Client may be termed "RSA
IP".
1. Aware of the realm to which its peer nodes belong
2. Assumes an address from external realm when communicating
hosts in that realm. Such an address may be assigned
or obtained dynamically (through a yet-to-be-defined protocol
from a node capable of assigning addresses from external realm
RSA-IP-Server could be the node coordinating external
address assignment
Srisuresh & Holdrege Informational [Page 17]
RFC 2663 NAT Terminology and Considerations August 1999
3. Route packets to external hosts using an approach amenable
RSA-IP-Server. In all cases, RSA-IP-Client will likely
to act as a tunnel end-point, capable of
end-to-end packets while forwarding and decapsulating in
return path
"Realm Specific Address IP Server" (RSA-IP server) is a node
on both private and external realms, that facilitates routing
external realm packets specific to RSA-IP clients inside a
realm. An RSA-IP-Server may be described as having the
characteristics
1. May be configured to assign addresses from external realm
RSA-IP-Clients, either statically or dynamically
2. Must be a router resident on both the private and
address realms
3. Must be able to provide a mechanism to route external
packets within private realm. Of the two approaches described
the first approach requires RSA-IP-Server to be a NAT
providing transparent routing for the outer header.
approach requires the external peer to be a tunnel end-point
With the second approach, an RSA-IP-Server could be any
(including a NAT router) that can be a tunnel end-point
RSA-IP-Clients. It would detunnel end-to-end packets
from RSA-IP-Clients and forward to external hosts. On
return path, it would locate RSA-IP-Client tunnel, based on
destination address of the end-to-end packet and encapsulate
packet in a tunnel to forward to RSA-IP-Client
RSA-IP-Clients may pursue any of the IPsec techniques,
transport or tunnel mode Authentication and confidentiality using
and ESP headers on the embedded packets. Any of the
techniques may be adapted for encapsulation between RSA-IP-Client
RSA-IP-Server or between RSA-IP-Client and external host.
example, IPsec tunnel mode encapsulation is a valid type
encapsulation that ensures IPsec authentication and
for the embedded end-to-end packets
5.2 Realm Specific Address and port IP (RSAP-IP
Realm Specific Address and port IP (RSAP-IP) is a variation of
in that multiple private hosts use a single external address
multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers
ICMP Query IDs).
Srisuresh & Holdrege Informational [Page 18]
RFC 2663 NAT Terminology and Considerations August 1999
"RSAP-IP-Client" may be defined similar to RSA-IP-Client with
variation that RSAP-IP-Client assumes a tuple of (external address
transport Identifier) when connecting to hosts in external realm
pursue end-to-end communication. As such, communication with
nodes for an RSAP-IP-Client may be limited to TCP, UDP and
sessions
"RSAP-IP-Server" is similar to RSA-IP-Server in that it
routing of external realm packets specific to RSAP-IP clients
a private realm. Typically, an RSAP-IP-Server would also be the
to assign transport tuples to RSAP-IP-Clients
A NAPT router enroute could serve as RSAP-IP-Server, when the
encapsulation is TCP/UDP based and is addressed between the RSAP-IP
Client and external peer. This approach requires the external peer
be the end-point of TCP/UDP based tunnel. Using this approach
RSAP-IP-Clients may pursue any of the IPsec techniques,
transport or tunnel mode authentication and confidentiality using
and ESP headers on the embedded packets. Note however, IPsec
mode is not a valid type of encapsulation, as a NAPT router
provide routing transparency to AH and ESP protocols
Alternately, packets may be tunneled between RSAP-IP-Client
RSAP-IP-Server such that RSAP-IP-Server would detunnel
outbound from RSAP-IP-Clients and forward to external hosts. On
return path, RSAP-IP-Server would locate RSAP-IP-Client tunnel
based on the tuple of (destination address, transport Identifier)
encapsulate the original packet within a tunnel to forward to RSAP
IP-Client. With this approach, there is no limitation on
tunneling technique employed between RSAP-IP-Client and RSAP-IP
Server. However, there are limitations to applying IPsec
security on end-to-end packets. Transport mode based
and integrity may be attained. But, confidentiality cannot
permitted because RSAP-IP-Server must be able to examine
destination transport Identifier in order to identify the RSAP-IP
tunnel to forward inbound packets to. For this reason, only
transport mode TCP, UDP and ICMP packets protected by AH and ESP
authentication can traverse a RSAP-IP-Server using this approach
As an example, say Host-A in figure 2 above, obtains a tuple
(Addr-Nx, TCP port T-Nx) from NAPT router to act as RSAP-IP-Client
initiate end-to-end TCP sessions with Host-X. Traversal of end-to
end packets within private realm may be illustrated as follows.
the first method, outer layer of the outgoing packet from Host-A
(private address Addr-A, source port T-Na) as source tuple
communicate with Host-X. NAPT router enroute translates this
into (Addr-Nx, Port T-Nxa). This translation is independent of RSAP
IP-Client tuple parameters used in the embedded packet
Srisuresh & Holdrege Informational [Page 19]
RFC 2663 NAT Terminology and Considerations August 1999
First method, using NAPT router enroute to translate
====================================================
Host-A NAPT router Host-
------ ----------- ------
src=Addr-A, Src Port=T-Na
Dest=Addr-X>,
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X
----------------------------->
src=Addr-Nx, Src Port=T-Nxa
Dest=Addr-X>,
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X
--------------------------------------->
.
.
.
src=Addr-X, Dest=Addr-Nx
Dest Port=T-Nxa>,
src=Addr-X, Dest=Addr-Nx
Dest Port=T-Nx
<----------------------------------
src=Addr-X, Dest=Addr-A
Dest Port=T-Na>,
src=Addr-X, Dest=Addr-Nx
Dest Port=T-Nx
<-----------------------------------
Srisuresh & Holdrege Informational [Page 20]
RFC 2663 NAT Terminology and Considerations August 1999
Second method, using a tunnel within private realm
==================================================
Host-A NAPT router Host-
------ ----------- ------
src=Addr-A, Dest=Addr-Np>,
src=Addr-Nx, Src Port=T-Nx
Dest=Addr-X
----------------------------->
src=Addr-Nx, Src Port=T-Nx
Dest=Addr-X
-------------------------------->
.
.
.
src=Addr-X, Dest=Addr-Nx
Dest Port=T-Nx
<----------------------------------
src=Addr-Np, Dest=Addr-A>,
src=Addr-X, Dest=Addr-Nx
Dest Port=T-Nx
<----------------------------------
6.0. Private Networks and
Let us consider the case where your private network is connected
the external world via tunnels. In such a case, tunnel
traffic may or may not contain translated packets depending upon
characteristics of address realms a tunnel is bridging
The following subsections discuss two scenarios where tunnels
used (a) in conjunction with Address translation, and (b)
translation
Srisuresh & Holdrege Informational [Page 21]
RFC 2663 NAT Terminology and Considerations August 1999
6.1. Tunneling translated
All variations of address translations discussed in the
section can be applicable to direct connected links as well
tunnels and virtual private networks (VPNs).
For example, a private network connected to a business
through a VPN could employ traditional NAT to communicate with
partner. Likewise, it is possible to employ twice NAT, if
partner's address space overlapped with the private network.
could be a NAT device on one end of the tunnel or on both ends of
tunnel. In all cases, traffic across the VPN can be encrypted
security purposes. Security here refers to security for
across VPNs alone. End-to-end security requires trusting NAT
within private network
6.2. Backbone partitioned private
There are many instances where a private network (such as a
network) is spread over different locations and use public
for communications between those locations. In such cases, it is
desirable to do address translation, both because large numbers
hosts may want to communicate across the backbone, thus
large address tables, and because there will be more
that depend on configured addresses, as opposed to going to a
server. We call such a private network a backbone-partitioned
network
Backbone-partitioned stubs should behave as though they were a non
partitioned stub. That is, the routers in all partitions
maintain routes to the local address spaces of all partitions.
course, the (public) backbones do not maintain routes to any
addresses. Therefore, the border routers must tunnel (using VPNs
through the backbones using encapsulation. To do this, each NAT
will set aside a global address for tunneling
When a NAT box x in stub partition X wishes to deliver a packet
stub partition Y, it will encapsulate the packet in an IP header
destination address set to the global address of NAT box y that
been reserved for encapsulation. When NAT box y receives a
with that destination address, it decapsulates the IP header
routes the packet internally. Note, there is no address
in the process; merely transfer of private network packets over
external network tunnel backbone
Srisuresh & Holdrege Informational [Page 22]
RFC 2663 NAT Terminology and Considerations August 1999
7.0. NAT operational
NAT devices are application unaware in that the translations
limited to IP/TCP/UDP/ICMP headers and ICMP error messages only.
devices do not change the payload of the packets, as payloads tend
be application specific
NAT devices (without the inclusion of ALGs) do not examine or
transport payload. For this reason, NAT devices are transparent
applications in many cases. There are two areas, however, where
devices often cause difficulties: 1) when an application
includes an IP address, and 2) when end-to-end security is needed
Note, this is not a comprehensive list
Application layer security techniques that do not make use of
depend on IP addresses will work correctly in the presence of
(e.g., TLS, SSL and ssh). In contrast, transport layer
such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385
[Ref 17] do not
In IPSec transport mode, both AH and ESP have an integrity
covering the entire payload. When the payload is TCP or UDP,
TCP/UDP checksum is covered by the integrity check. When a NAT
modifies an address the checksum is no longer valid with respect
the new address. Normally, NAT also updates the checksum, but this
ineffective when AH and ESP are used. Consequently, receivers
discard a packet either because it fails the IPSec integrity
(if the NAT device updates the checksum), or because the checksum
invalid (if the NAT device leaves the checksum unmodified).
Note that IPsec tunnel mode ESP is permissible so long as
embedded packet contents are unaffected by the outer IP
translation. Although this technique does not work in traditional
deployments (i.e., where hosts are unaware that NATs are present),
the technique is applicable to Realm-Specific IP as described
Section 5.0.
Note also that end-to-end ESP based transport mode authentication
confidentiality are permissible for packets such as ICMP, whose
payload content is unaffected by the outer IP header translation
NAT devices also break fundamental assumptions by public
distribution infrastructures such as Secure DNS RFC 2535 [Ref 18]
X.509 certificates with signed public keys. In the case of
Srisuresh & Holdrege Informational [Page 23]
RFC 2663 NAT Terminology and Considerations August 1999
DNS, each DNS RRset is signed with a key from within the zone
Moreover, the authenticity of a specific key is verified by
a chain of trust that goes all the way to the DNS root. When a DNS
ALG modifies addresses (e.g., as in the case of Twice-NAT),
verification of signatures fails
It may be of interest to note that IKE (Session key
protocol) is a UDP based session layer protocol and is not
by network based IPsec security. Only a portion of the
payloads within IKE are protected. As a result, IKE sessions
permissible across NAT, so long as IKE payload does not
addresses and/or transport IDs specific to one realm and not
other. Given that IKE is used to setup IPSec associations, and
are at present no known ways of making IPSec work through a
function, it is a future work item to take advantage of IKE through
NAT box
One of the most popular internet applications "FTP" would not
with the definition of NAT as described. The following sub-section
devoted to describing how FTP is supported on NAT devices. FTP
is an integral part of most NAT implementations. Some vendors
choose to include additional ALGs to custom support
applications on the NAT device
7.1. FTP
"PORT" command and "PASV" response in FTP control session
identify the IP address and TCP port that must be used for the
session it supports. The arguments to the PORT command and
response are an IP address and a TCP port in ASCII. An FTP ALG
required to monitor and update the FTP control session payload
that information contained in the payload is relevant to end nodes
The ALG must also update NAT with appropriate data session tuples
session orientation so that NAT could set up state information
the FTP data sessions
Because the address and TCP port are encoded in ASCII, this
result in a change in the size of packet. For instance
10,18,177,42,64,87 is 18 ASCII characters,
193,45,228,137,64,87 is 20 ASCII characters. If the new size is
as the previous, only the TCP checksum needs adjustment as a
of change of data. If the new size is less than or greater than
previous, TCP sequence numbers must also be changed to reflect
change in length of FTP control data portion. A special table may
used by the ALG to correct the TCP sequence and acknowledge numbers
The sequence number and acknowledgement correction will need to
performed on all future packet of the connection
Srisuresh & Holdrege Informational [Page 24]
RFC 2663 NAT Terminology and Considerations August 1999
8.0. NAT
8.1. Applications with IP-address
Not All applications lend themselves easily to address translation
NAT devices. Especially, the applications that carry IP address (
TU port, in case of NAPT) inside the payload. Application
Gateways, or ALGs must be used to perform translations on
pertaining to such applications. ALGs may optionally utilize
(and TU port) assignments made by NAT and perform
specific to the application. The combination of NAT functionality
ALGs will not provide end-to-end security assured by IPsec. However
tunnel mode IPsec can be accomplished with NAT router serving
tunnel end point
SNMP is one such application with address content in payload.
routers would not translate IP addresses within SNMP payloads. It
not uncommon for an SNMP specific ALG to reside on a NAT router
perform SNMP MIB translations proprietary to the private network
8.2. Applications with inter-dependent control and data
NAT devices operate on the assumption that each session
independent. Session characteristics like session orientation
source and destination IP addresses, session protocol, and source
destination transport level identifiers are determined
at the start of each new session
However, there are applications such as H.323 that use one or
control sessions to set the characteristics of the follow-on
in their control session payload. Such applications require use
application specific ALGs that can interpret and translate
payload, if necessary. Payload interpretation would help NAT
prepared for the follow-on data sessions
8.3. Debugging
NAT increases the probability of mis-addressing. For example,
local address may be bound to different global address at
times and vice versa. As a result, any traffic flow study
purely on global addresses and TU ports could be confused and
misinterpret the results
If a host is abusing the Internet in some way (such as trying
attack another machine or even sending large amounts of junk mail
something) it is more difficult to pinpoint the source of the
because the IP address of the host is hidden in a NAT router
Srisuresh & Holdrege Informational [Page 25]
RFC 2663 NAT Terminology and Considerations August 1999
8.4. Translation of fragmented FTP control
Translation of fragmented FTP control packets is tricky when
packets contain "PORT" command or response to "PASV" command
Clearly, this is a pathological case. NAT router would need
assemble the fragments together first and then translate prior
forwarding
Yet another case would be when each character of packets
"PORT" command or response to "PASV" is sent in a separate datagram
unfragmented. In this case, NAT would simply have to let the
through, without translating the TCP payload. Of course,
application will fail if the payload needed to be altered.
application could still work in a few cases, where the
contents can be valid in both realms, without modifications enroute
For example, FTP originated from a private host would still
while traversing a traditional NAT or bi-directional NAT device,
long as the FTP control session employed PASV command to
data sessions. The reason being that the address and port
specified by FTP server in the PASV response (sent as
unfragmented packets) is valid to the private host, as is. The
device will simply view the ensuing data session (also
from private host) as an independent TCP session
8.5. Compute
NAT is compute intensive even with the help of a clever
adjustment algorithm, as each data packet is subject to NAT
and modifications. As a result, router forwarding throughput
be slowed considerably. However, so long as the processing
of the NAT device exceeds line processing rate, this should not be
problem
9.0. Security
Many people view traditional NAT router as a one-way (session
traffic filter, restricting sessions from external hosts into
machines. In addition, when address assignment in NAT router is
dynamically, that makes it harder for an attacker to point to
specific host in the NAT domain. NAT routers may be used
conjunction with firewalls to filter unwanted traffic
If NAT devices and ALGs are not in a trusted boundary, that is
major security problem, as ALGs could snoop end user traffic payload
Session level payload could be encrypted end to end, so long as
payload does not contain IP addresses and/or transport
that are valid in only one of the realms. With the exception of RSIP
end-to-end IP network level security assured by current
Srisuresh & Holdrege Informational [Page 26]
RFC 2663 NAT Terminology and Considerations August 1999
techniques is not attainable with NAT devices in between. One of
ends must be a NAT box. Refer section 7.0 for a discussion on
end-to-end IPsec security cannot be assured with NAT devices
the route
The combination of NAT functionality, ALGs and firewalls will
a transparent working environment for a private networking domain
With the exception of RSIP, end-to-end network security assured
IPsec cannot be attained for end-hosts within the private
(Refer section 5.0 for RSIP operation). In all other cases, if
want to use end-to-end IPsec, there cannot be a NAT device in
path. If we make the assumption that NAT devices are part of
trusted boundary, tunnel mode IPsec can be accomplished with
router (or a combination of NAT, ALGs and firewall) serving as
end point
NAT devices, when combined with ALGs, can ensure that the
injected into Internet have no private addresses in headers
payload. Applications that do not meet these requirements may
dropped using firewall filters. For this reason, it is not
to find NAT, ALG and firewall functions co-exist to provide
at the borders of a private network. NAT gateways can be used
tunnel end points to provide secure VPN transport of packet
across an external network domain
Below are some additional security considerations associated with
routers
1. UDP sessions are inherently unsafe. Responses to a
could come from an address different from the target
used by sender ([Ref 4]). As a result, an incoming UDP
might match the outbound session of a traditional NAT
only in part (the destination address and UDP port number
the packet match, but the source address and port number
not). In such a case, there is a potential security
for the NAT device in permitting inbound packets with
match. This UDP security issue is also inherent to firewalls
Traditional NAT implementations that do not track datagrams
a per-session basis but lump states of multiple UDP
using the same address binding into a single unified
could compromise the security even further. This is because
the granularity of packet matching would be further limited
just the destination address of the inbound UDP packets
2. Multicast sessions (UDP based) are another source for
weakness for traditional-NAT routers. Once again, firewalls
the same security dilemma as the NAT routers
Srisuresh & Holdrege Informational [Page 27]
RFC 2663 NAT Terminology and Considerations August 1999
Say, a host on private network initiated a multicast session
Datagram sent by the private host could trigger responses in
reverse direction from multiple external hosts. Traditional-
implementations that use a single state to track a
session cannot determine for certain if the incoming UDP
is in response to an existing multicast session or the start
new UDP session initiated by an attacker
3. NAT devices can be a target for attacks
Since NAT devices are Internet hosts they can be the target of
number of different attacks, such as SYN flood and ping
attacks. NAT devices should employ the same sort of
techniques as Internet-based servers do
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E
Lear, "Address Allocation for Private Internets", BCP 5,
1918, February 1996.
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October, 1994.
[3] Braden, R., "Requirements for Internet Hosts --
Layers", STD 3, RFC 1122, October 1989.
[4] Braden, R., "Requirements for Internet Hosts -- Application
Support", STD 3, RFC 1123, October 1989.
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
9, RFC 959, October 1985.
[7] Postel, J., "Transmission Control Protocol (TCP) Specification",
STD 7, RFC 793, September 1981.
[8] Postel, J., "Internet Control Message Protocol Specification
STD 5, RFC 792, September 1981.
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
August 1980.
[10] Mogul, J. and J. Postel, "Internet Standard
Procedure", STD 5, RFC 950, August 1985.
Srisuresh & Holdrege Informational [Page 28]
RFC 2663 NAT Terminology and C