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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0001
`
`Alarm.com. v. Vivint
`IPR2015-01977
`
`

`
`
`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
` reference.
`
`Srisuresh & Holdrege Informational [Page 2]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0002
`
`

`
`
`RFC 2663 NAT Terminology and Considerations August 1999
`
`2.1. Address realm or 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. A
` session flow indicates the direction in which the session was
` initiated with reference to a network interface. Packet flow is the
` direction in which the packet has traveled with reference to a
` network interface. Take for example, an outbound telnet session. The
` 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 IP 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0003
`
`

`
`
`RFC 2663 NAT Terminology and Considerations August 1999
`
` Note, there is no guarantee that the idea of a session, determined as
` 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.
`
` However, there is no deterministic way of recognizing the start of a
` 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0004
`
`

`
`
`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.8. 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.16/12, and
` 192.168/16 set aside for private internets. In pre-CIDR notation, the
`
`Srisuresh & Holdrege Informational [Page 5]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0005
`
`

`
`
`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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0006
`
`

`
`
`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)
` c) ICMP error packet payload translation.
`
` 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 w/NAT|---
` +---------------+ . +-----------------+\
` . | \
` . | LAN
` . ---------------
` 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-sections describe two types of address assignments.
`
`3.1.1. Static Address assignment
`
` In the case of static address assignment, there is one-to-one address
` 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0007
`
`

`
`
`RFC 2663 NAT Terminology and Considerations August 1999
`
`3.2. Transparent routing
`
` A NAT router sits at the border between two address realms and
` translates addresses in IP headers so that when the packet leaves one
` 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0008
`
`

`
`
`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
`
` All ICMP error messages (with the exception of Redirect message type)
` 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. NAT
` should not attempt to modify a Redirect message type.
`
` 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0009
`
`

`
`
`RFC 2663 NAT Terminology and Considerations August 1999
`
` ________________
` ( )
` ( External ) +--+
` ( Address Realm )-- |__|
` ( (N-Ext) ) /____\
` (________________) Host-X
` | (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 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-directional 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0010
`
`

`
`
`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 checksums 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0011
`
`

`
`
`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.
`
` Very often, the external interface address Addr-Nx of NAPT router is
` 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
` dynamically as connections are established in either direction. The
` 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]
`
`Petitioner Alarm.com's Exhibit 1021
`1021.0012
`
`

`
`
`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 of 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 t