IAB                                                             T. Hain
Internet Draft                                                Microsoft
Document: draft-iab-nat-implications-03.txt               February 1999
Category: Informational

                   Architectural Implications of NAT

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [1].
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at

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


   In light of the growing interest in, and deployment of network
   address translation (NAT) RFC-1631, this paper will discuss some of
   the architectural implications and guidelines for implementations.
   It is assumed the reader is familiar with the address translation
   concepts presented in RFC-1631.

Table of Contents
 Abstract ............................................................1
 Definitions .........................................................4
  Terminology ........................................................4
 Advantages of NATs ..................................................7
 Disadvantages of NATs ...............................................8
 Illustrations ......................................................10
 Considerations .....................................................16
  IPv6 ..............................................................16
  Security ..........................................................16
  Deployment Guidelines .............................................18
 Summary ............................................................19
 References .........................................................21
  Acknowledgments ...................................................22
  Author's Addresses ................................................22
  Copyright .........................................................22

Hain             Informational - Expires August 1999                 1
                  Architectural Implications of NAT      February 1999


   In May 1994, K. Egevang and P. Francis RFC-1631 [2] defined NAT as
   one means to ease the growth rate of IPv4 address use. Several
   places in the document they recognized the need to experiment and
   see what applications may be adversely affected by NAT's header
   manipulations, even before there was any significant operational
   experience. This is further evidenced in a quote from the
   conclusions: 'NAT has several negative characteristics that make it
   inappropriate as a long term solution, and may make it inappropriate
   even as a short term solution.'

   Nearly five years later, we find arguments that NAT is 'THE' short
   *AND* long-term solution, while questioning the strategy or
   continued effort at developing IPv6 as a replacement protocol. At
   the same time, the artificial shortage of IPv4 addresses, caused by
   the current stringent allocation guidelines, creates a perceived
   need to promote private address use via NAT. This increase in
   popularity of private addresses has resulted in additional
   experience, further exposing NAT's shortcomings. Unfortunately even
   as the failings of NAT are exposed, the technology is widely
   promoted as if it 'just works' with no serious effects except on a
   few legacy applications.

   The arguments pro & con frequently take on religious tones, with
   each side passionate about its position.
   - Proponents bring enthusiasm and frequently cite the most popular
     applications of Mail & Web services as shining examples of their
     cause. They will also point out that NAT is the feature that
     finally breaks the semantic overload of the IP address as both a
     locator and the global endpoint identifier (EID).
   - The opposing view of NAT is that of a malicious technology, where
     there is a concern that NAT is the weed which is destined to choke
     out continued Internet development. While recognizing there are
     perceived address shortages, the opponents of NAT view it as
     operationally inadequate at best, bordering on a sham as an
     Internet access solution.

   With reality somewhere in between these extreme viewpoints, it is
   clear NAT affects the transparency of end-to-end connectivity for
   transports relying on consistency of the IP header. Using a
   patchwork of mutually configured application specific gateways
   (ALG's), endpoints can work around some of the operational
   challenges of NAT. When there are two endpoints in a conversation
   this effort is straightforward, but for applications with more
   distributed and multi-point expectations it can be a significant
   ordeal. The complexity of coordinating the updates necessary to work
   around NAT grows geometrically with the number of endpoints. In a
   large environment, this may require concerted effort to
   simultaneously upgrade all endpoints of a given application or

Hain             Informational - Expires August 1999                 2
                  Architectural Implications of NAT      February 1999

   The architectural role of NAT is to divide the Internet into
   independent address administrations, specifically facilitating
   casual use of private address assignments RFC-1918 [3]. As noted by
   Carpenter, et al RFC-2101 [4], once private use addresses were
   deployed in the network, addresses were guaranteed to be ambiguous.
   At the same time when NATs are attached to the network, the process
   of resolving names to or from addresses gains a dependency on where
   the question was asked. As NAT concatenates existing stand-alone
   name spaces, both names and addresses become globally ambiguous.

   A significant factor in the success of the Internet is the
   flexibility derived from a few basic tenets. Foremost is the End-to-
   End principle, which assumes the endpoints are in control of the
   communication and the network simply moves bits between these
   points. Restated, the data stream delivered by the transport
   protocol of the endpoints is of no concern to the lower layer packet
   routing devices, and therefore may contain anything the endpoint
   applications consider appropriate. (Note: while firewalls also break
   the end-to-end model, they are installed with the explicit intent to
   prevent access, where NAT claims to be transparent.) Another is that
   the network does not maintain per connection state information,
   which allows fast rerouting around failures through alternate paths.
   Lack of state also removes any requirement for the network nodes to
   notify each other as endpoint connections are formed or dropped.
   Furthermore, the endpoints are not, and need not be, aware of any
   network components other than the first hop router(s), name
   resolution service, and destination. Packet integrity is preserved
   through the network, and transport checksums are valid end-to-end.
   NATs (particularly the NAPT variety) break most of these, reducing
   overall flexibility, while increasing operational complexity and
   impeding diagnostic capabilities.  The HNAT [5] and RSIP [6]
   variants have recently been proposed to address the end-to-end
   concerns. While they may be effective at providing the private node
   with a public address (if ports are available), they do not deal
   with the issues of; network state management, upper layer
   constraints like TCP TIME_WAIT state, or well-known-port sharing.
   Their port multiplexing variants also share the same neighbor DNS
   visibility concerns of NAPT, and each host requires significant
   stack modifications to enable the technology.

Hain             Informational - Expires August 1999                 3
                  Architectural Implications of NAT      February 1999



   NAT - Network Address Translation in simple form is a method by
   which IP addresses are mapped from one address administration to

   ALG/NAT - combines ALG functions with simple NAT. Generally more
   useful than pure NAT, because it embeds a work around to specific
   applications that NAT breaks.

   DNS/ALG - special case of ALG/NAT, where an ALG for the DNS service
   interacts with the NAT component to manage DNS response contents.

   Static NAT - provides stable one-to-one mapping between address

   Dynamic NAT - provides many-to-few mapping from a relatively large
   number of addresses on one side to a few addresses on the other.

   NAPT - Network Address Port Translation accomplishes translation by
   multiplexing transport level identifiers of multiple addresses from
   one side, simultaneously into the transport identifiers of a single
   address on the other.

   HNAT - Host NAT allows endpoints to acquire and use their public
   address and port number at the source. The public / private process
   only allocates public addresses and forwards unmodified packets.
   This approach requires significant changes to the host stack
   implementation to dynamically manage tunnels to the HNAT server.

   RSIP - Realm Specific IP is a generalization of HNAT, including
   mechanisms for the private node to request multiple resources at
   once. This has the same requirement to modify Hosts as HNAT.

   ALG - Application Gateway is inserted between application peers to
   simulate a direct connection, when some intervening protocol or
   device prevents direct access. It terminates the transport protocol,
   and may modify the data stream before forwarding.

   Firewall - Special case of an ALG or routing filter, which
   implements access controls.

   Proxy - Special case of an ALG that is a simple relay service
   designed into a protocol, rather than capriciously inserted.

   VPN - Virtual Private Networks technically treat an IP
   infrastructure as a multiplexing substrate, allowing the endpoints
   to build virtual transit pathways, over which they run another
   instance of IP.

Hain             Informational - Expires August 1999                 4
                  Architectural Implications of NAT      February 1999

   Address administration - coordinator of an address pool assigned to
   a collection of routers and end systems.

   Routing realm - collection of routers and end systems exchanging
   locally unique location knowledge (potentially in a hierarchical
      NAT proponents define the NAT function as providing routing
      realms [7], where each domain is responsible for finding
      addresses within its boundaries. This work-around to the
      limitations NAT creates, hides them behind the well-understood
      need for routing management. Compartmentalization of routing
      information is really a function of routing protocols and their
      scope of application. NAT is simply a means to distribute address
      allocation authority and provide a mechanism to map one
      administrations addresses into those of another administration.
      The fact that experienced operators limit network topology, and
      don't leak addresses across a NAT, does not mean NAT itself
      provides any routing isolation services. In fact, if someone were
      to define an OSPF ALG it would be technically possible to route
      across a NAT boundary.  Using a routing ALG, in combination with
      the fact that NAT breaks IPsec, could allow a private network to
      enforce which endpoints are even capable of attempting secure
      access while allowing non-secure access to other services.

Hain             Informational - Expires August 1999                 5
                  Architectural Implications of NAT      February 1999


   RFC-1631 limited the scope of NAT discussions to stub appendages of
   a public Internet. Therefore, in discussing the architectural impact
   of NATs on the Internet, the first task is defining the scope of the
   Internet. The most basic definition is; a concatenation of networks
   built using IETF defined technologies. This simple description does
   not distinguish between the public network known as the Internet,
   and the private networks built using the same technologies
   (including those connected via NAT). An approach resolving this
   would be including the resources of Names or Addresses administered
   through IANA or its delegates. While this is more accurate, it still
   includes many private networks that have coordinated their names or
   addresses with the public Internet. Rekhter, et al RFC-1918 defined
   hosts as public when they need network layer access outside the
   enterprise, using a globally unambiguous address. Those that need
   limited or no access are defined as private. Another way to view
   this is the transparency of the connection between any given node
   and the rest of the Internet.

   The ultimate resolution of public or private is found in the intent
   of the network in question. Generally, networks that do not intend
   to be part of the greater Internet will use some screening
   technology to insert a barrier. Historically barrier devices between
   the public and private networks were known as Firewalls or
   Application Gateways, and were managed to allow approved traffic
   while blocking everything else. Increasingly the screening
   technology is becoming a simple NAT, which manages the network
   locator between the public and private-use address spaces, and then
   using ALGs attempts to be transparent to protocols incompatible with
   NAT.  (Use of NAT within a private network is possible, and is only
   addressed here in the context that some component of the private
   network is used as a common transit service between the NAT attached
   stubs.)  The primary distinction between a Firewall and NAT in this
   context is the intent to block, or facilitate traffic flow.

Hain             Informational - Expires August 1999                 6
                  Architectural Implications of NAT      February 1999

Advantages of NATs

   A quick look at the popularity of NAT as a technology shows that it
   tackles several real world problems.

   - Masking the address changes that take place, from either dial-
     access or provider changes, minimizes impact on the local network
     by avoiding renumbering.
   - Globally routable addresses can be reused for intermittent access
     customers. This lowers the demand and utilization of addresses to
     the number of active nodes rather than the total number of nodes.
   - There is a potential that ISP provided and managed NATs would
     lower support burden since there could be a consistent, simple
     device with a known configuration at the customer end of the
     access interface.
   - Breaking the Internet into a collection of address authorities
     limits the need for continual justification of allocations.
   - For applications that don't rely on the integrity of the packet
     header, changes in the hosts may not be necessary.
   - Like route filtering Firewalls, NAPT, HNAPT, & RSIP block inbound
     connections to all ports until they are administratively mapped.

   Taken together these explain some of the strong motivations for
   moving quickly with NAT deployment.

   Removing hosts that are not currently active, lowers address demands
   of the public Internet. In cases where providers would end up with
   address allocations that could not be aggregated, this improves the
   load on the routing system as well as lengthens the lifetime of the
   IPv4 address space. While removing idle addresses is a natural
   byproduct of the existing dynamic allocation, dial-access devices,
   in the dedicated connection case this service could be provided
   through a NAT. In the case of a NAPT, the aggregation potential is
   even greater as multiple end systems share a single public address.

   By reducing the options and minimizing the potential support matrix,
   there is a potential that ISP provided NATs would lower support
   costs. (These savings may be more than offset by the additional
   support costs created when NAT breaks various applications.)

   Part of the motivation here is to avoid the high cost of renumbering
   inherent in the current IPv4 Internet. Localizing address
   administration minimizes those costs, and simultaneously provides
   for a much larger local pool of addresses than is available under
   current allocation guidelines. (The registry guidelines are intended
   to prolong the lifetime of the IPv4 address space until IPv6 is
   ready, by managing allocations to match actual demand.  They may end
   up hampering growth in areas where it is difficult to sort out real
   need from potential hoarding.) Until IPv6 provides a simpler
   solution, NAT is effective at masking provider switching or other
   requirements to change addresses.

Hain             Informational - Expires August 1999                 7
                  Architectural Implications of NAT      February 1999

   NAT deployments have been raising the awareness of protocol
   designers who are interested in ensuring that their protocols work
   end-to-end. Breaking the semantic overload of the IP address will
   force applications to find a more appropriate mechanism for endpoint
   identification and discourage carrying the locator in the data
   stream. Since this will not work for legacy applications, RFC-1631
   discusses how to look into the packet and make NAT transparent to
   the application (ie: create an application gateway). This may not be
   possible for all applications, and even with application gateways in
   the path, it may be necessary to modify the end host to be aware
   there may be intermediaries modifying the data.

   Another popular practice is hiding a collection of hosts that
   provide a combined service behind a single IP address (ie: web host
   load sharing). In many implementations this is architecturally a
   NAT, since the addresses are mapped to the real destination on the
   fly. When packet header integrity is not an issue, this type of
   virtual host requires no modifications to the remote applications
   since the end client is unaware of the mapping activity. While the
   virtual host has the CPU performance characteristics of the total
   set of machines, the overall performance is bounded by the
   processing and I/O capabilities of the NAT device as it funnels the
   packets back and forth.

Disadvantages of NATs

   - NATs break the flexible end-to-end model of the Internet.
   - NATs create a single point where fates are shared, in the device
     maintaining connection state and dynamic mapping information.
   - NATs inhibit implementation of security at the IP level.
   - NATs facilitate concatenating existing name spaces with the DNS.
   - NATs enable address collisions when VPNs traverse multiple NATs
     along a path.
   - NAPT, HNAPT, & RSIP increase operational complexity when published
     services reside on the private side. This includes the restriction
     that only one private side system can be accessed through a given
     public side well-known-port.

   As noted earlier, NATs break the basic tenet of the Internet that
   the endpoints are in control of the communication. The original
   design put state control in the endpoints so there would be no other
   inherent points of failure. Moving the state from the endpoints to
   specific nodes in the network reduces flexibility, while it
   increases the impact of a single point failure.

   In addition, NATs are not transparent to all applications, and
   managing simultaneous updates to a large array of ALGs may exceed
   the cost of acquiring additional globally routable addresses. While
   RSIP addresses the transparency and ALG issues, for the specific
   case of individual private to public, there is still a node with
   specific state required to maintain the connection.

Hain             Informational - Expires August 1999                 8
                  Architectural Implications of NAT      February 1999

   Dynamic NAT, HNAT, and RSIP will eventually violate higher layer
   assumptions about address/port number reuse RFC-793 [8] RFC-1185
   [9]. The TCP state, TIME_WAIT, is specifically designed to prevent
   replay of packets between the 4-tuple of IP & port for a given IP
   address pair. Since the TCP state machine of a second private side
   node is unaware of any previous use, its attempts to connect to the
   same service as its neighbor, which is still in TIME_WAIT, will
   fail. The full range of upper layer architectural assumptions that
   are broken by NAT technologies may not be well understood without a
   very large-scale deployment.

   One of the greatest concerns from the explosion of NATs is the
   impact on the fledgling efforts at deploying IP security. One
   fundamental issue for IPSec is that with both AH and ESP, the
   authentication check covers the TCP/UDP checksum (which in turn
   covers the IP address). When a NAT changes the IP address, the
   checksum calculation will fail, and therefore authentication will
   fail. This combination of required global uniqueness of the address,
   and assured ambiguity by NAT leaves the IPsec effort without a
   workable solution.

   In a statement about the use of IPv4 today, RFC-2101 details
   architectural issues and notes:
       "... it has been considered more useful to deliver the packet,
       then worry about how to identify the endpoints, than to provide
       identity in a packet that cannot be delivered."
   This argument presumes that delivering the packet has an inherent
   value, even if the endpoints cannot be identified. In a self-
   fulfillment of that prophecy, many applications developed to date
   are structured to assume packets will be delivered and identity is
   only assured in controlled environments.

   In another note from RFC-2101:
       "Since IP Security authentication headers assume that the
       addresses in the network header are preserved end-to-end, it is
       not clear how one could support IP Security-based authentication
       between a pair of hosts communicating through either an ALG (ed:
       Application Level Gateway) or a NAT."
   There are distributed applications that assume that IP addresses are
   globally scoped, globally unique, globally routable, and all hosts
   have the same view of those addresses. NATs break these
   applications. There are other applications that assume that all
   upper layer ports from a given IP address map to the same endpoint,
   and port multiplexing technologies like NAPT, HNAPT, and RSIP breaks

   NATs place constraints on the deployment of applications that carry
   IP addresses (or derivatives), in the data stream. Applications or
   protocols that assume end-to-end integrity of the address will fail
   when traversing a NAT. (TCP was specifically designed to take
   advantage of, and reuse the IP address for use as a transport
   address.) To resolve this, an Application Level Gateway needs to

Hain             Informational - Expires August 1999                 9
                  Architectural Implications of NAT      February 1999

   exist within each NAT. An additional gateway service is necessary
   for each application that may imbed an address. Even this approach
   will fail when requirement is end-to-end encryption since only the
   endpoints have access to the keys.

   Finally, while the port multiplexing variants of NAT (popular
   because they allow Internet access through a single address) work
   modestly well for connecting private hosts to public services, they
   create management problems for applications connecting from public
   toward private. The concept of a well-known-port is undermined
   because only one private side system can be mapped through the
   single public-side port number. This will affect home networks, when
   applications like multi-player Internet games can only be played on
   one system at a time. It will also affect small businesses when only
   one system at a time can be operated on the standard port to provide
   web services. The issue is that the public toward private usage
   requires administrative mapping for each target prior to connection.


   A feature of stateful devices like NATs is the creation of a single
   point of failure. Attempts to avoid this by establishing redundant
   NATs, creates a new set of problems related to timely communication
   of the state, and routing related failures. This encompasses several
   issues such as update frequency, performance impact of frequent
   updates, reliability of the state update transaction, a-priori
   knowledge of all nodes needing this state information, and
   notification to end nodes of alternatives. (This last point could be
   accomplished with a routing protocol, which might require
   modifications to the hosts so they will listen.)

   It has been observed that operational management of networks
   incorporating stateful packet modifying device is considerably
   easier if inbound and outbound packets traverse the same path. While
   easy to say, it is difficult to manage using a connectionless
   protocol, even with careful planning. The problem is ensuring that
   routes advertised to the private side reach the end nodes and map to
   the same device as the public side route advertisements. This state
   needs to persist throughout the lifetime of sessions traversing the
   NAT. A point to bear in mind is the frequency of simultaneous
   internal and external topology churn. Consider the following case
   where the -X- links are broken, or flapping.

Hain             Informational - Expires August 1999                10
                  Architectural Implications of NAT      February 1999

                          --------       --------
                         | Host A |     | Host B |
                         |   Foo  |     |   Bar  |
                          --------       --------
                              |             |
                            ----          ----
                            ----          ----
                              |            |
                             ----         ----
                            |NAT1|       |NAT2|
                             ----         ----
                               |          |
                             |Rtr         Rtr|
                             | /  Internet \ |     ---
                              --------------       ---
                               |          |
                               |          |
                          --------       --------
                         | Host C |     | Host D |
                          --------       --------

   To maintain sanity with external routing, the default path for
   Routers 1 & 2 is via NAT1. When the path between Router 1 & 2
   breaks, Router 2 would attempt to switch to NAT2, but the external
   return path would still be through NAT1. In this case, redundancy
   was useless. While this scenario is strictly a routing failure, the
   normal routing tools for resolving it are not available because the
   connection to the Internet is via NATs.

   Consider the case that the path between Router 1 & 2 is up, and some
   remote link in the network is down. When Host D tries to contact
   Host B, the request goes through NAT2, but the reply is through
   NAT1. Since the state information for this connection is in NAT2,
   NAT1 will provide a new mapping. Even if the remote path is
   restored, the connection will not be made because the requests are
   to the public IP of NAT2, while the replies are from the public IP
   of NAT1.

   In another case, both Host A & B want to contact Host D, when some
   remote link in the Internet breaks. As long as the path between
   Router 1 & 2 is still down, Host B is able to connect, but Host A is
   cut off. In addition, Host A is unable to contact DNS to even find
   the address of Host D.  Without a thorough understanding of the
   remote topology (unlikely since that tends to be sensitive
   proprietary information), the administrator of Hosts A & B would
   have no clue why one worked and the other didn't. As far as he can
   tell both paths are up and the redundancy is covering the local
   outage, but only one connection works.

Hain             Informational - Expires August 1999                11
                  Architectural Implications of NAT      February 1999

   In any network topology, individual router or link failures may
   present problems with insufficient redundancy, but the state
   maintenance requirements of NAT present an additional burden that is
   not as easily resolved.

   By facilitating concatenation of multiple name spaces, NAT
   exaggerates a problem in the process of resolving addresses from
   names, or names from addresses. (This occurs when an existing stand-
   alone site attaches to the Internet through a NAT, without renaming
   all hosts.) When the public DNS is required to resolve a given host
   name on both sides of a NAT there is no obviously correct answer. In
   the example below it is not clear what answer DNS should return for
   Host D.  Returning the local address will assure global
   invisibility, while returning the global address will prevent local
   access from Host C. If DNS were to return both, the results would be
   unpredictable. By knowing which side the request came from the DNS
   server could provide the correct answer, but significant development
   would be required to add the capability to DNS for source specific
   responses. (note: since Host A has no access to the Internet
   (therefore the DNS service), it is required to maintain a local
   table, but the others may be expecting DNS to provide the
   appropriate resolution.) In the case where Hosts C & D share an
   address (either time-shared or port multiplexed), there is no way
   Host B could know which it was connecting to. DNS would return a
   public side address for either, then it is up to the NAT to decide
   where the packets are eventually directed. Since Host B cannot tell,
   it may end up connecting to a very different service than it
   expected for the name used. (This would also be true for connections
   from C or D to the other.) For connections originating from C or D
   toward B, B would not be able to resolve which system was really
   trying to connect, and might inadvertently allow access to the wrong

                  --------    ---        ---    --------
                 | Host A |--|NAT|------|NAT|--| Host B |
                  --------    ---        ---    --------
                                  \        \
                                    ---     --------      ---
                                    ---     --------      ---
                               |          |
                           --------    --------
                          | Host C |  | Host D |
                           --------    --------

   Even if forward mappings are working, implementations that require
   an unambiguous reverse mapping from the in-addr.arpa tree will fail.

   Discussions about an arbitrary mesh of NAT connections will
   ultimately exaggerate the issue of name space integration with the
   routing infrastructure. It will show that the only resolution to

Hain             Informational - Expires August 1999                12
                  Architectural Implications of NAT      February 1999

   appropriately answer name queries in a NAT environment is to locate
   the DNS service within each NAT. One proposal to deal with locating
   the DNS service in each NAT is the DNS/ALG [10]. Rather than running
   the full DNS server in the NAT, it provides a mapping service by
   intercepting DNS messages and modifying the contents appropriately.
   This method presents a requirement that the DNS response traverse
   the node with the mapping state for the final connection. Note the
   first example for operational failure potential of finding the
   correct NAT. DNS/ALG specifically avoids discussion of private nodes
   finding each other when the DNS server is on the far side of a NAPT.

   The primary feature of NATs is the 'simple' ability to connect
   private networks to the public Internet. When the private network
   exists prior to installing the NAT, it is unlikely and unnecessary
   that its name resolver would use a registered domain. Connecting the
   NAT device, and reconfiguring the resolver to proxy for all external
   requests allows access to the public network by hosts on the private
   network. Configuring the public DNS for the set of private hosts
   that need inbound connections would require a registered domain
   (either private, or from the connecting ISP) and a unique name. At
   this point the partitioned name space is concatenated and hosts
   would have different names based on inside vs. outside queries.

                          --------       --------
                         | Host A |     | Host B |
                         |   Foo  |-----|   Bar  |
                          --------   |   --------   ---
                                    ---             ---
                                 --------      ---
                                 --------      ---
                                    ---             ---
                          --------   |   --------   ---
                         | Host C |-----| Host D |
                         |   Foo  |     |   Bar  |
                          --------       --------

   Everything in this simple example will work until an application
   embeds a name. For example, a Web service running on Host D might
   present embedded URL's of the form http://bar/*.html, which would
   work from Host C, but would thoroughly confuse Host A. If the
   embedded name resolved to the public address, Host A would be happy,
   but Host C would be looking for some remote machine. Using the
   public FQDN resolution to establishing a connection from Host C to
   D, the NAT would have to look at the destination rather than simply

Hain             Informational - Expires August 1999                13
                  Architectural Implications of NAT      February 1999

   forwarding the packet out to the router. (Normal operating mode for
   a NAT is translate & forward out the other interface, while routers
   do not send packets back on the same interface they came from). The
   NAT did not create the name space fragmentation, but it facilitates
   attempts to merge networks with independent name administrations.

   The recent mass growth of the Internet has been driven by support of
   low cost publication via the web. The next big push appears to be
   support of Virtual Private Networks (VPNs). Technically VPNs treat
   an IP infrastructure as a multiplexing substrate allowing the
   endpoints to build what appear to be clear pathways from end-to-end.
   VPNs redefine network visibility and increase the likelihood of
   address collision when traversing multiple NATs. Address management
   in the private space behind NATs will become a significant burden,
   as there is no central body capable of, or willing to do it. The
   lower burden for the ISP is actually a transfer of burden to the
   local level, because administration of addresses and names becomes
   both distributed and more complicated.

   As noted in RFC-1918, the merging of private address spaces can
   cause an overlap in address use, creating a problem. VPNs will
   increase the likelihood and frequency of that merging through the
   simplicity of their establishment. There are several configurations
   of address overlap which will cause failure, but in the simple
   example shown below the private use address of Host B matches the
   private use address of the VPN pool used by Host A for inbound
   connections.  When Host B tries to establish the VPN, Host A will
   assign it an address from its pool for inbound connections, and
   identify the gateway for Host B to use. In the example, Host B will
   not be able to distinguish the remote VPN address of Host A from its
   own address, so the connection will fail. Since private use
   addresses are by definition not publicly coordinated, as the
   complexity of the VPN mesh increases so does the likelihood that
   there will be a collision which cannot be resolved.

              ---------------                     ----------------
             |  |--------VPN--------| Assigned by A  |
             |    Host A     |   ---       ---   |    Host B      |
             |   |--|NAT|-----|NAT|--|   |
              ---------------    ---       ---    ----------------

Hain             Informational - Expires August 1999                14
                  Architectural Implications of NAT      February 1999

   Another potential use of NAT is reusing a range of allocated
   addresses at multiple sites within an organization. In the following
   example, the network manager has chosen to use time-shared
   traditional NAT, with /8 of the corporate allocation on the public
   side at each site. To avoid any problems with private addresses, the
   upper half of the publicly allocated address block is assigned to
   the local DHCP service, at each site.

                          --------       --------
                         | Host A |-----| Host B |
                          --------   |   --------
                                     |  1.1.128.x /15  ---
                                    ---                ---
                                     |  1.1.2.x /8
                                 --------      ---
                               |   ISP   |----|DNS|
                                 --------      ---
                                     |  1.1.3.x /8
                                     |  1.1.128.x /15  ---
                          --------   |   --------      ---
                         | Host C |-----| Host D |
                          --------       --------

   While the addresses used are from publicly assigned space, the NAT
   in the path puts them in the same class as private allocations. NAT
   used in this instance has all the same characteristics as the
   implementations using any of the private ranges. This example shows
   that that NAT is the source of the concerns, not the use of private

Hain             Informational - Expires August 1999                15
                  Architectural Implications of NAT      February 1999



   It has been argued that IPv6 is no longer necessary because NATs
   relieve the address space constraints and allow the Internet to
   continue growing. The reality is they point out the need for IPv6
   more clearly than ever. People are trying to connect multiple
   machines through a single access line to their ISP and have been
   willing to give up some functionality to get that at minimum cost.
   Frequently the reason for cost increases is the perceived scarcity
   (therefore increased value) of IPv4 addresses, which would be
   eliminated through deployment of IPv6. This crisis mentality is
   creating a market for a solution to a problem already solved with
   greater flexibility by IPv6.

   Beyond all of the above issues, the existence of NATs will
   complicate the integration of IPv6 in the Internet as the name space
   and endpoint addresses attempt to become consistent and globally
   unique. While multiple addresses are explicitly supported by an IPv6
   node, the disjoint name space will certainly make management
   interesting. If IPv6 nodes are willing to continue in private
   networks behind a NAT, they will only need a site local address and
   all of the issues become the same as IPv4. If the intent is to move
   into a public address allocation as a feature of moving to IPv6, any
   independent name administrations will require explicit effort to
   merge with the public DNS as well.


   NAT (particularly NAPT) lowers overall security because it creates
   the illusion of a security barrier. Appropriate security mechanisms
   are implemented in the end host, without reliance on assumptions
   about routing hacks, firewall filters, or missing NAT translations,
   which may change over time to enable a service to a neighboring
   host. In general, defined security barriers assume that any threats
   are external, leading to practices which make internal breaches that
   much easier.

   NATs break the defined implementation modes of IPsec, and therefore
   may stall further deployment of enhanced security across the
   Internet. It is difficult to identify all the combinations of header
   orderings and options that are possible using NATs, VPNs, and IPsec.
   It is even more difficult to clearly state which of those are
   applicable, or workable in any given context. For example;
   - Use of AH is not possible via NAT as the hash protects the IP
     address in the header.
   - Authenticated certificates may contain the IP address as part of
     the subject name for authentication purposes.
   - Encrypted Quick Mode structures may contain IP addresses and ports
     for policy verifications.

Hain             Informational - Expires August 1999                16
                  Architectural Implications of NAT      February 1999

   - The Revised Mode of public key encryption includes the peer
     identity in the encrypted payload.
   It may be possible to engineer and work around NATs for IPsec on a
   case by case basis. With all of the restrictions placed on
   deployment flexibility, NATs present a significant obstacle to
   security integration being deployed in the Internet today.

   As noted in the DNS/ALG draft, the DNS/ALG cannot support secure DNS
   name servers in the private domain. Zone transfers between DNSsec
   servers will be rejected when necessary modifications are attempted.
   It is also the case that DNS/ALG will break any modified, signed
   responses. This would be the case for all public side queries of
   private nodes, when the DNS server is on the private side. It would
   also be true for any private side queries for private nodes, when
   the DNS server is on the public side. Digitally signed records could
   be modified by the DNS/ALG if it had access to the source
   authentication key. DNSsec has been specifically designed to avoid
   distribution of this key, to maintain source authenticity. So NATs
   that use DNS/ALG to repair the namespace resolutions will either;
   break the security when modifying the record, or will require access
   to all source keys to requested resolutions.

   Security mechanisms that do not protect or rely on IP addresses as
   identifiers, such as TLS [11], SSL [12], or SSH [13] may operate in
   environments containing NATs. For applications that can establish
   and make use of this type of transport connection, NATs do not
   create any additional complications. These technologies may not
   provide sufficient protection for all applications as the header is
   exposed, allowing subversive acts like TCP resets. RFC-2385 [14]
   discusses the issues in more detail.

Hain             Informational - Expires August 1999                17
                  Architectural Implications of NAT      February 1999

 Deployment Guidelines

   Given that NAT devices are being deployed at a fairly rapid pace,
   some guidelines are in order. Most of these amount to 'think before
   you leap', then think again, then make sure you really want to start
   down this path.
   - Determine the mechanism for name resolution, and ensure the
     appropriate answer is given for each address administration.
     Embedding the DNS server, or a DNS ALG in the NAT device will
     likely be more manageable than trying to synchronize independent
     DNS systems across realms.
   - Is the NAT configured for static one to one mappings, or will it
     dynamically manage them? If dynamic, make sure the TTL of the DNS
     responses is set to 0, and that the clients pay attention to the
     don't cache notification.
   - Will there be a single NAT device, or parallel with multiple
     paths? If single, consider the impact of a device failure. If
     multiple, consider how routing on both sides will insure the
     packets flow through the same box over the connection lifetime of
     the applications.
   - Examine the applications that will need to traverse the NAT and
     verify their immunity to address changes. If necessary provide an
     appropriate ALG or establish a VPN to isolate the application from
     the NAT.
   - Determine need for public toward private connections, variability
     of destinations on the private side, and potential for
     simultaneous use of public side port numbers. NAPTs increase
     administration if these apply.
   - Determine if the applications traversing the NAPT, HNAPT, or RSIP
     expect all ports from the public IP address to be the same
     endpoint. Administrative controls to prevent simultaneous access
     from multiple private hosts will be required if this is the case.
   - If there are encrypted payloads, the contents cannot be modified
     unless the NAT is a security endpoint, acting as a gateway between
     security realms. This precludes end-to-end confidentiality, as the
     path between the NAT and endpoint is exposed.
   - Determine the path for name resolutions. If hosts on the private
     side of a NAPT, HNAPT, or RSIP server need visibility to each
     other, a private side DNS server may be required.
   - If the environment uses secure DNS records, the DNS/ALG will
     require access to the source authentication keys for all records
     to be translated.
   - When using VPNs over NATs, identify a clearinghouse for the
     private side addresses to avoid collisions.
   - Assure that applications used both internally and externally avoid
     embedding names, or use globally unique ones.
   - When using HNAT or RSIP, recognize the scope is limited to
     individual private network connecting to the public Internet. If
     other NATs are in the path (including web-server load-balancing
     devices), the advantage is lost. In addition, the port
     multiplexing versions of these carry the same well-known-port
     sharing problem of NAPT.

Hain             Informational - Expires August 1999                18
                  Architectural Implications of NAT      February 1999


   Over the 5-year period since RFC-1631, the experience base has
   grown, further exposing concerns raised by the original authors. NAT
   breaks a fundamental assumption of the Internet design; the
   endpoints are in control. Another design principle, 'keep-it-simple'
   is being overlooked as more features are added to the network to
   work around the complications created by NATs. In the end, overall
   flexibility and manageability are lowered, and support costs go up
   to deal with the problems introduced.

   Evangelists, for and against the technology, present their cases as
   righteous while downplaying any rebuttals.
   - NATs are a 'fact of life', and will proliferate as an enhancement
     that sustains the existing IPv4 infrastructure.
   - NATs are a 'necessary evil' and create an administrative burden
     that is not easily resolved. More significantly, they inhibit the
     roll out of IPsec, which will in turn slow growth of applications
     that require a secure infrastructure.
   In either case, NATs require strong applicability statements,
   clearly declaring what works and what does not.

   An overview of the pluses and minuses:
NAT advantages                      NAT disadvantages
--------------------------------    --------------------------------
Masks global address changes        Breaks end-to-end model
                                    Stateful points of failure
                                    Breaks IPsec
                                    Facilitates concatenation of
                                    multiple name spaces
Address administrations avoid       Requires source specific DNS reply
justifications to registries        or DNS/ALG
                                    DNS/ALG breaks DNSsec replies
Lowers address utilization          Enables end-to-end address
Lowers ISP support burden           Increases local support burden and
Transparent to end systems in some  Unique development for each app
Load sharing as virtual host        Performance limitations with scale
Delays need for IPv4 replacement    May complicate integration of IPv6

   There have been many discussions lately about the value of
   continuing with IPv6 development when the market place is widely
   deploying IPv4 NATs. A short sighted view would miss the point that
   both have a role, because NATs address some real-world issues today,
   while IPv6 is targeted at solving fundamental problems, as well as
   moving forward. It should be recognized that there will be a long
   co-existence as applications and services develop for IPv6, while
   the lifetime of the existing IPv4 systems will likely be measured in
   decades. At their best, NATs are a diversion from forward motion,
   but they do enable wider participation at the present state. At

Hain             Informational - Expires August 1999                19
                  Architectural Implications of NAT      February 1999

   their worst, they break a class of applications, which creates the
   need for complex work-arounds.

   Efforts to enhance general security in the Internet include IPsec
   and DNSsec. These technologies provide a variety of services to both
   authenticate and protect information during transit. By breaking
   these technologies, NAT and the DNS/ALG work-around, hinder
   deployment of enhanced security throughout the Internet.

   There have also been many questions about the probability of VPNs
   being established that might raise some of the listed concerns.
   While it is hard to predict the future, one way to avoid ALGs for
   each application is to establish a VPN over the NATs. This restricts
   the NAT visibility to the headers of the tunnel packets, and removes
   its effects from all applications. While this solves the ALG issues,
   it raises the likelihood that there will be address collisions as
   arbitrary connections are established between uncoordinated address
   spaces. It also creates a side concern about how an application
   establishes the necessary VPN.

   The original IP architecture is powerful because it provides a
   general mechanism on which other things (yet unimagined) may be
   built. While it is possible to build a house of cards, time and
   experience have lead to building standards with more structural
   integrity. IPv6 is the long-term solution that retains end-to-end
   transparency as a principle. NAT is a technological diversion to
   sustain the lifetime of IPv4.

   Everyone needs to focus on the goal, which is continued evolution of
   the Internet, and recognize continued development of IP (in all
   current and future versions) is the path. It has been noted that the
   success of the Internet is based on the 'living' characteristic of
   IP. As in life, when growth, evolution, and forward progress stops,
   decay overtakes and destroys. History has shown that protocols that
   were 'complete and finished' as presented, have had very short
   lifetimes while those still 'a work in progress' manage to survive
   and continue moving ahead. All parties need to understand the
   significant role they are playing in pursuing the goal, and that
   none can get there without all the others.

Hain             Informational - Expires August 1999                20
                  Architectural Implications of NAT      February 1999


   1  RFC-2026 Bradner, S., " The Internet Standards Process --
      Revision 3", BCP 9, RFC 2026, October 1996.

   2  RFC-1631 Egevang, K., Francis, P., "The IP Network Address
      Translator", RFC 1631, May 1994

   3  RFC-1918, Rekhter, et al, "Address Allocation for Private
      Internets", RFC 1918 February 1996

   4  RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", RFC
      2101, February 1997

   5  draft-ietf-nat-hnat-00.txt, Jeffrey LoCategory, K.Taniguchi, "IP
      Host Network Address (and Port) Translation", November 1998

   6  draft-ietf-nat-rsip-protocol-00.txt, M. Borella, D. Grabelsky,
      J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification",
      February 1999

   7  draft-ietf-nat-terminology-01.txt, P. Srisuresh, Matt Holdrege,
      "IP Network Address Translator (NAT) Terminology and
      Considerations", October 1998

   8  RFC-793, J. Postel, "Transmission Control Protocol", RFC 793,
      September 1981

   9  RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for
      High-Speed Paths", RFC 1185, October 1990

   10  draft-ietf-nat-dns-alg-01.txt, P. Srisuresh, G. Tsirtsis, P.
      Akkiraju, A. Heffernan "DNS extensions to Network Address
      Translators", October 1998

   11 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS
      Protocol", November 1997

   12 http://home.netscape.com/eng/ssl3/ssl-toc.html   March 1996

   13 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH
      Protocol Architecture", August 1998

   14 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP
      MD5 Signature Option", RFC 2385, August 1998

Hain             Informational - Expires August 1999                21
                  Architectural Implications of NAT      February 1999

   Valuable contributions to this draft came from the IAB, Vern Paxson
   (lbl), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter(cisco)
   and Eliot Lear (cisco).

 Author's Addresses
   Tony Hain
   One Microsoft Way            Phone:  1-425-703-6619
   Redmond, Wa. USA             Email:  tonyhain@microsoft.com

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English. The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns. This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE

Hain             Informational - Expires August 1999                22