Network Working Group
`Request for Comments: 2663
`Category:
`Informational
`
`P. Srisuresh
`M. Holdrege
`Lucent Technologies
`August 1999
`
`IP Network Address Translator (NAT) Terminology and Considerations
`
`Status of this Memo
`
`It does
`This memo provides information for the Internet community.
`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]
`
`1
`
`SAMSUNG 1009 |x| 2305
`
`1
`
`SAMSUNG 1009
`
`IXI 2306
`
`

`
`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.
`
`intended to describe the
`this document is not
`Note, however,
`operations of individual NAT variations or the applicability of NAT
`devices.
`
`NAT devices attewpt 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.
`
`Terminology and concepts used
`
`Terms most frequently used in the context of NAT are defined here for
`reference.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 2]
`
`2
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`2.1. Address realm cr realm
`
`An address realm is a network domain in which the network addresses
`
`are uniquely assigned to entities such that datagrams can be routed
`to them. Routing protocols used within the network domain are
`responsible for finding routes to entities given their network
`addresses. Note that this document is limited to describing NAT in
`IPv4 environment and does not address the use of NAT in other types
`of environment.
`(e.g.
`IPv6 environments)
`
`2.2. Transparent routing
`
`The term "transparent routing" is used throughout the document to
`identify the routing functionality that a NAT device provides. This
`is different from the routing functionality provided by a traditional
`router device in that a traditional router routes packets within a
`single address realm.
`
`Transparent routing refers to routing a datagram between disparate
`address realms, by modifying address contents in the IP header to be
`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 flow
`
`Connection or session flows are different from packet flows.
`session flow indicates the direction in which the session was
`initiated with reference to a network interface. Packet flow is the
`
`A
`
`direction in which the packet has traveled with reference to a
`The
`network interface. Take for example, an outbound telnet session.
`telnet session consists of packet flows in both inbound and outbound
`directions. Outbound telnet packets carry terminal keystrokes and
`inbound telnet packets carry screen displays from the telnet server.
`
`For purposes of discussion in this document, a session is defined as
`the set of traffic that is managed as a unit for translation.
`TCP/UDP sessions are uniquely identified by the tuple of
`(source IP
`address, source TCP/UDP port,
`target I? address,
`target TCP/UDP
`port}.
`ICMP query sessions are identified by the tuple of
`(source IP
`address,
`ICMP query ID,
`target IP address). All other sessions are
`characterized by the tuple of
`(source IP address,
`target IP address,
`IP protocol).
`
`Address translations performed by NAT are session based and would
`include translation of incoming as well as outgoing packets belonging
`to that session. Session direction is identified by the direction of
`the first packet of that session (see sec 2.5).
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 3]
`
`3
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`there is no guarantee that the idea of a session, determined as
`Note,
`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) as
`a single session and might not even view its communication with its
`peers as a session. Not all applications are guaranteed to work
`across realms, even with an ALG {defined below in section 2.9)
`enroute.
`
`2.4. TU ports, Server ports, Client ports
`
`For the reminder of this document, we will refer TCP/UDP ports
`associated with an IP address simply as "TU ports".
`
`For most TCP/IP hosts, TU port range 0-1023 is used by servers
`listening for incoming connections. Clients trying to initiate a
`connection typically select a source TU port in the range of 1024-
`65535. However,
`this convention is not universal and not always
`followed. Some client stations initiate connections using a source TU
`port number in the range of 0-1023, and there are servers listening
`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 others
`
`The first packet of every TCP session tries to establish a session
`and contains connection startup information. The first packet of a
`TCP session may be recognized by the presence of SYN bit and absence
`of ACK bit in the TCP flags. All TCP packets, with the exception of
`the first packet, must have the ACK bit set.
`
`there is no deterministic way of recognizing the start of a
`However,
`UDP based session or any non—TCP session. A heuristic approach would
`be to assume the first packet with hitherto non—existent session
`parameters (as defined in section 2.3) as constituting the start of
`new session.
`
`2.6. End of session for TCP, UDP and others
`
`The end of a TCP session is detected when FIN is acknowledged by both
`halves of the session or when either half receives a segment with the
`RST bit in TCP flags field. However, because it is impossible for a
`NAT device to know whether the packets it sees will actually be
`delivered to the destination {they may be dropped between the NAT
`device and the destination),
`the NAT device cannot safely assume that
`the segments containing FINs or SYNs will be the last packets of the
`session (i.e.,
`there could be retransmissions). Consequently, a
`session can be assumed to have been terminated only after a period of
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 4]
`
`4
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`4 minutes subsequent to this detection. The need for this extended
`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 terminate
`without
`the NAT device becoming aware of the event (e.g.,
`in the case
`where one or both peers reboot). Consequently, garbage collection is
`necessary on NAT devices to clean up unused state about TCP sessions
`that no longer exist. However, it is not possible in the general case
`to distinguish between connections that have been idle for an
`extended period of time from those that no longer exist.
`In the case
`of UDP—based sessions,
`there is no single way to determine when a
`session ends, since UDP—based protocols are application specific.
`
`Many heuristic approaches are used to terminate sessions. You can
`make the assumption that TCP sessions that have not been used for
`say, 24 hours, and non-TCP sessions that have not been used for a
`couple of minutes, are terminated. Often this assumption works, but
`sometimes it doesn’t. These idle period session timeouts vary a great
`deal both from application to application and for different sessions
`of the same application. Consequently, session timeouts must be
`configurable. Even so,
`there is no guarantee that a satisfactory
`value can be found. Further, as stated in section 2.3,
`there is no
`guarantee that NAT's view of session termination will coincide with
`that of the application.
`
`Another way to handle session terminations is to timestamp entries
`and keep them as long as possible and retire the longest idle session
`when it becomes necessary.
`
`2.7. Public/Global/External network
`
`A Global or Public Network is an address realm with unique network
`addresses assigned by Internet Assigned Numbers Authority (IANA) or
`an equivalent address registry. This network is also referred as
`External network during NAT discussions.
`
`2.3. Private/Local network
`
`A private network is an address realm independent of external network
`addresses. Private network may also be referred alternately as Local
`Network. Transparent routing between hosts in private realm and
`external realm is facilitated by a NAT router.
`
`RFC 1918 [Ref 1] has recommendations on address space allocation for
`private networks. Internet Assigned Numbers Authority (IANA) has
`three blocks of IP address space, namely 10/8, 172.16fl2, and
`192.168/16 set aside for private internets.
`In pre-CIDR notation,
`
`the
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 5]
`
`5
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`first block is nothing but a single class A network number, while the
`second block is a set of 16 contiguous class B networks, and the
`third block is a set of 256 contiguous class C networks.
`
`An organization that decides to use IP addresses in the address space
`defined above can do so without coordination with IANA or any other
`Internet registry such as APNIC, RIPE and ARIN.
`The address space
`can thus be used privately by many independent organizations at the
`same time. However,
`if those independent organizations later decide
`they wish to communicate with each other or the public Internet,
`they
`will either have to renumber their networks or enable NAT on their
`border routers.
`
`2.9. Application Level gateway (ALG)
`
`Not all applications lend themselves easily to translation by NAT
`devices; especially those that include IP addresses and TCP/UDP ports
`in the payload. Application Level Gateways
`(ALGs) are application
`specific translation agents that allow an application on a host in
`one address realm to connect to its counterpart running on a host in
`different realm transparently. An ALG may interact with NAT to set up
`state, use NAT state information, modify application specific payload
`and perform whatever else is necessary to get the application running
`across disparate address realms.
`
`ALGs may not always utilize NAT state information. They may glean
`application payload and simply notify NAT to add additional state
`information in some cases. ALGS are similar to Proxies,
`in that, both
`ALGs and proxies facilitate Application specific communication
`between clients and servers. Proxies use a special protocol to
`communicate with proxy clients and relay client data to servers and
`vice versa. Unlike Proxies, ALGs do not use a special protocol to
`communicate with application clients and do not require changes to
`application clients.
`
`3. What is NAT?
`
`Network Address Translation is a method by which IP addresses are
`mapped from one address realm to another, providing transparent
`routing to end hosts. There are many variations of address
`translation that lend themselves to different applications. However,
`all flavors of NAT devices should share the following
`characteristics.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 6]
`
`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 not
`exchanging routing information)
`ICMP error packet payload translation.
`
`o)
`
`Below is a diagram illustrating a scenario in which NAT is enabled on
`a stub domain border router, connected to the Internet through a
`regional router made available by a service provider.
`
`+ — - — — — — — — * — — — * — — -—+/
`.
`+ - — — — — ~ — — - — — - — —-+ WAN
`|Regional Router| — — — — — — — — — — — — — — — — — — — — ——|Stub Router wINAT|———
`+ — — — — — — — — — — — — — ——+
`.
`+ — — — — — — — — — — — — — — — ——+\
`
`Stub border
`
`Figure 1: A typical NAT operation scenario
`
`3.1. Transparent Address Assignment
`
`NAT binds addresses in private network with addresses in global
`network and vice versa to provide transparent routing for the
`datagrams traversing between address realms. The binding in some
`Cases may extend to transport level identifiers (such as TCP/UDP
`ports). Address binding is done at the start of a session. The
`following sub—secticns describe two types of address assignments.
`
`3.1.1. Static Address assignment
`
`there is one—to—one address
`In the case of static address assignment,
`mapping for hosts between a private network address and an external
`network address for the lifetime of NAT operation. Static address
`assignment ensures that NAT does not have to administer address
`management with session flows.
`
`3.1.2. Dynamic Address assignment
`
`In this case, external addresses are assigned to private network
`hosts or vice versa, dynamically based on usage requirements and
`session flow determined heuristically by NAT. When the last session
`using an address binding is terminated, NAT would free the binding so
`that the global address could be recycled for later use. The exact
`nature of address assignment is specific to individual NAT
`implementations.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 7]
`
`7
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`3.2. Transparent routing
`
`A NAT router sits at the border between two address realms and
`
`leaves one
`translates addresses in IP headers so that when the packet
`realm and enters another, it can be routed properly. Because NAT
`devices have connections to multiple address realms,
`they must be
`careful to not
`improperly propagate information (e.g., via routing
`protocols) about networks from one address realm into another, where
`such an advertisement would be deemed unacceptable.
`
`There are three phases to Address translation, as follows. Together
`these phases result in creation, maintenance and termination of state
`for sessions passing through NAT devices.
`
`3.2.1. Address binding
`
`Address binding is the phase in which a local node IP address is
`associated with an external address or vice versa,
`for purposes of
`translation. Address binding is fixed with static address assignments
`and is dynamic at session startup time with dynamic address
`assignments. Once the binding between two addresses is in place, all
`subsequent sessions originating from or to this host will use the
`same binding for session based packet translation.
`
`New address bindings are made at the start of a new session, if such
`an address binding didn't already exist. Once a local address is
`bound to an external address, all subsequent sessions originating
`from the same local address or directed to the same local address
`
`will use the same binding.
`
`The start of each new session will result in the creation of a state
`
`to facilitate translation of datagrams pertaining to the session.
`There can be many simultaneous sessions originating from the same
`host, based on a single address binding.
`
`3.2.2. Address lookup and translation
`
`Once a state is established for a session, all packets belonging to
`the session will be subject to address lookup (and transport
`identifier lookup,
`in some cases) and translation.
`
`Address or transport identifier translation for a datagram will
`result in the datagram forwarding from the origin address realm to
`the destination address realm with network addresses appropriately
`updated.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 8]
`
`8
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`3.2.3. Address unbinding
`
`Address unbinding is the phase in which a private address is no
`longer associated with a global address for purposes of translation.
`NAT will perform address unbinding when it believes that the last
`session using an address binding has terminated. Refer section 2.6
`for some heuristic ways to handle session terminations.
`
`3.3.
`
`ICMP error packet translation
`
`ICMP error messages (with the exception of Redirect message type}
`All
`will need to be modified, when passed through NAT. The ICMP error
`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.
`
`NAT
`
`Changes to ICMP error message will include changes to the original IP
`packet
`(or portions thereof) embedded in the payload of the ICMP
`error message.
`In order for NAT to be completely transparent to end
`hosts,
`the IP address of the IP header embedded in the payload of the
`ICMP packet must be modified,
`the checksum field of the same IP
`header must correspondingly be modified, and the accompanying
`transport header. The ICMP header checksum must also be modified to
`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 NAT
`
`There are many variations of address translation that lend themselves
`to different applications. NAT flavors listed in the following sub-
`sections are by no means exhaustive, but they do capture the
`significant differences that abound.
`
`The following diagram will be used as a base model to illustrate NAT
`flavors. Host—A, with address Addr—A is located in a private realm,
`represented by the network N-Pri. N-Pri is isolated from external
`network through a NAT router. Host-X, with address Addr-X is located
`in an external realm, represented by the network N-Ext.
`NAT router
`with two interfaces, each attached to one of the realms provides
`transparent routing between the two realms. The interface to the
`external realm is assigned an address of Addr—Nx and the interface to
`private realm is assigned an address of Addr-Np.
`Further, it may be
`understood that addresses Addr-A and Addr-Np correspond to N—Pri
`network and the addresses Addr—X and Addr-Nx correspond to N-Ext
`network.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 9]
`
`9
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`(
`
`(
`
`External
`
`I Address Realm
`I
`(N-Ext)
`
`(
`
`I
`
`)
`
`)
`
`}
`
`+--+
`
`}-— |__|
`\
`/
`Host-X
`
`|
`I(Addr—Nx}
`+ - - - - - - - - - - - - --+
`
`(Addr-X)
`
`I
`I
`|
`|
`I
`I
`+ — — — — — — — — — — — — --+
`
`NAT router
`
`| (Addr—Np}
`I
`
`+—~+
`
`|__| - - - — -—(
`\
`/
`Host-A
`{Addr-A)
`
`I
`
`I
`
`(
`
`(
`
`Private
`
`Address Realm
`(N—pri)
`
`J
`
`}
`
`)
`
`}
`
`)
`
`Figure 2: A base model to illustrate NAT terms.
`
`4.1. Traditional NAT (or) Outbound NAT
`
`Traditional NAT would allow hosts within a private network to
`transparently access hosts in the external network,
`in most cases.
`In a traditional NAT, sessions are uni—directional, outbound from the
`private network. This is in contrast with Bi-directional NAT, which
`permits sessions in both inbound and outbound directions. A detailed
`description of Bi—direotional NAT may be found in section 4.2.
`
`The following is a description of the properties of realms supported
`by traditional NAT.
`IP addresses of hosts in external network are
`unique and valid in external as well as private networks. However,
`the addresses of hosts in private network are unique only within the
`private network and may not be valid in the external network.
`In
`other words, NAT would not advertise private networks to the external
`realm. But, networks from the external realm may be advertised within
`the private network.
`The addresses used within private network must
`not overlap with the external addresses. Any given address must
`either be a private address or an external address; not both.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 10]
`
`10
`
`10
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`A traditional NAT router in figure 2 would allow Host-A to initiate
`sessions to Host-X, but not
`the other way around. Also, N-Ext is
`routable from within N-Pri, whereas N-Pri may not be routable from
`N—Ext.
`
`Traditional NAT is primarily used by sites using private addresses
`that wish to allow outbound sessions from their site.
`
`There are two variations to traditional NAT, namely Basic NAT and
`NAPT (Network Address Port Translation}. These are discussed in the
`following sub-sections.
`
`4.1.1. Basic NAT
`
`with Basic NAT, a block of external addresses are set aside for
`translating addresses of hosts in a private domain as they originate
`sessions to the external domain. For packets outbound from the
`private network,
`the source IP address and related fields such as IP,
`TCP, UDP and ICMP header cheoksums are translated. For inbound
`packets,
`the destination IP address and the checksums as listed above
`are translated.
`
`A Basic NAT router in figure 2 may be configured to translate N-Pri
`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 also
`translating transport identifier (e.g., TCP and UDP port numbers,
`ICMP query identifiers). This allows the transport identifiers of a
`number of private hosts to be multiplexed into the transport
`identifiers of a single external address. NAPT allows a set of hosts
`to share a single external address. Note that NAPT can be combined
`with Basic NAT so that a pool of external addresses are used in
`conjunction with port translation.
`
`For packets outbound from the private network, NAPT would translate
`the source IP address, source transport identifier and related fields
`such as IP, TCP, UDP and ICMP header checksums. Transport identifier
`can be one of TCP/UDP port or ICMP query ID. For inbound packets,
`the
`destination IP address, destination transport identifier and the IP
`and transport header checksums are translated.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 11]
`
`11
`
`11
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`A NAPT router in figure 2 may be configured to translate sessions
`originated from N-Pri into a single external address, say Addr—i.
`
`the external interface address Addr—Nx of NAPT router is
`Very often,
`used as the address to map N—Pri to.
`
`4.2. Bi—direCtional NAT (or) Two—Way NAT
`
`with a Bi-directional NAT, sessions can be initiated from hosts in
`
`the public network as well as the private network. Private network
`addresses are bound to globally unique addresses, statically or
`The
`dynamically as connections are established in either direction.
`name space (i.e.,
`their Fully Qualified Domain Names) between hosts
`in private and external networks is assumed to be end—to—end unique.
`Hosts in external realm access private realm hosts by using DNS for
`address resolution. A DNS—ALG must be employed in conjunction with
`Bi-Directional NAT to facilitate name to address mapping.
`Specifically,
`the DNS—ALG must be capable of translating private
`realm addresses in DNS Queries and responses into their external
`realm address bindings, and vice versa, as DNS packets traverse
`between private and external realms.
`
`The address space requirements outlined for traditional NAT routers
`are applicable here as well.
`
`A Bi—directional NAT router in figure 2 would allow Host-A to
`initiate sessions to Host—X, and Host-X to initiate sessions to
`Host-A. Just as with traditional NAT, N-Ext is routable from within
`N—Pri, but N—Pri may not be routable from N—Ext.
`
`4.3. Twice NAT
`
`Twice NAT is a variation of NAT in that both the source and
`
`destination addresses are modified by NAT as a datagram crosses
`address realms. This is in contrast to Traditional—NAT and Bi-
`
`Directional NAT, where only one of the addresses (either source or
`destination) is translated. Note,
`there is no such term as 'once-
`NAT‘ .
`
`Twice NAT is necessary when private and external realms have address
`collisions. The most common case where this would happen is when a
`site had (improperly) numbered its internal nodes using public
`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 by
`the first provider. That provider might
`then later reassign those
`addresses to someone else. The key issue in such cases is that the
`address of the host in the external realm may have been assigned the
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 12]
`
`12
`
`12
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`same address as a host within the local site. If that address were to
`
`appear in a packet, it would be forwarded to the internal node rather
`than through the NAT device to the external realm. Twice-NAT attempts
`to bridge these realms by translating both source and destination
`address of an IP packet, as the packet transitions realms.
`
`Twice—NAT works as follows. when HOSt—A wishes to initiate a session
`
`to Host—X, it issues a DNS query for Host—X. A DNS—ALG intercepts the
`DNS query, and in the response returned to Host-A the DNS—ALG
`replaces the address for Host-X with one that is properly routable in
`the local site (say Host-XPRIME). Host A then initiates communication
`with Host—XPRIME. when the packets traverse the NAT device,
`the
`source IP address is translated (as in the case of traditional NAT)
`and the destination address is translated to Host—X. A similar
`
`translation is performed on return packets Coming from Host-X.
`
`The following is a description of the properties of realms supported
`by Twice~NAT. Network address of hosts in external network are unique
`in external networks, but not within private network. Likewise,
`the
`network address cf hosts in private network are unique only within
`the private network.
`In other words,
`the address space used in
`private network to locate hosts in private and public networks is
`unrelated to the address space used in public network to locate hosts
`in private and public networks.
`Twice NAT would not be allowed to
`advertise local networks to the external network or vice versa.
`
`A Twice NAT router in figure 2 would allow Host—A to initiate
`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 Private
`network overlaps with addresses used in the Public space.
`For
`example, say a private site uses the 200.200.200.0/24 address space
`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_X
`{200.200.2DO.l00)
`in Public space.
`In order to make this connection
`work, Host_X’s address is mapped to a different address for Host_A
`and vice versa. The twice NAT located at the Private site border may
`be configured as follows:
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 13]
`
`13
`
`13
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`Private to Public
`Public to Private
`
`20o.200.200.0/24 -> 133.76.23.0/24
`200.2oo.20o.0/24 -:- 172.16.1.o/24
`
`Datagram flow
`
`Host_A(Private} ->
`
`Host_X(Public]
`
`a) Within private network
`
`DA:
`
`l72.16.l.100
`
`SA: 200.200.200.l
`
`b} After twice—NAT translation
`
`DA: 200.200.200.100
`
`SA: 138.76.28.1
`
`Datagram flow Host_X (Public) —> Host_A (Private)
`
`a) within Public network
`
`DA: 138.76.28.l
`
`SA: 200.200.200.100
`
`b) After twioe—NAT translation,
`
`in private network
`
`SA: 200.200.200.1
`
`DA: 172.l6.l.l00
`
`4
`
`.4.
`
`Multihomed NAT
`
`There are limitations to using NAT. For example, requests and
`responses pertaining to a session must be routed via the same NAT
`router, as a NAT router maintains state information for sessions
`established through it. For this reason, it is often suggested that
`NAT routers be operated on a border router unique to a stub domain,
`where all IP packets are either originated from the domain or
`destined to the domain. However, such a configuration would turn a
`NAT router into a single point of failure.
`
`In order for a private network to ensure that connectivity with
`external networks is retained even as one of the NAT links fail,
`is often desirable to multihome the private network to same or
`multiple service providers with multiple connections from the private
`domain, be it from same or different NAT boxes.
`
`it
`
`a private network could have links to two different
`For example,
`providers and the sessions from private hosts could flow through the
`NAT router with the best metric for a destination. When one of NAT
`
`routers fail,
`
`the other could route traffic for all connections.
`
`Srisuresh & Holdrege
`
`Informational
`
`[Page 14]
`
`14
`
`14
`
`

`
`RFC 2663
`
`NAT Terminology and Considerations
`
`August 1999
`
`Multiple NAT boxes or multiple links on the same NAT box, sharing the
`same NAT configuration can provide fail-safe backup for each other.
`In such a case, it is necessary for backup NAT device to exchange
`state information so that a backup NAT can take on session load
`transparently when the primary NAT fails. NAT backup becomes simpler,
`when configuration is based on static maps.
`
`5.0. Realm Specific IP (RSIPF
`
`is used to characterize the functionality
`"Realm Specific IP" (RSI?)
`of a rea1m—aware host in a private realm, which assumes realm-
`specific IP address to communicate with hosts in private or external
`realm.
`
`A "Realm Specific IP Client" (RSIP client) is a host in a private
`network that adopts an address in an external realm when connecting
`to hosts in that realm to pursue end-to-end communication. Packets
`generated by hosts on either end in such a setup would be based on
`addresses that are end-to~end unique in the external realm and do not
`require translation by an intermediary process.
`
`is a node resident on both
`A "Realm Specific IP Server" (RSIP server)
`private and external realms,
`that can facilitate routing of external
`realm