    Network Working Group                                           T. Hain
    Request for Comments: 2993                                    Microsoft
    Category: Informational                                   November 2000

                       Architectural Implications of NAT

    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 (2000).  All Rights Reserved.

    Abstract

       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

       1.  Introduction................................................... 2
       2.  Terminology.................................................... 4
       3.  Scope.......................................................... 6
       4.  End-to-End Model............................................... 7
       5.  Advantages of NATs............................................. 8
       6.  Problems with NATs............................................ 10
       7.  Illustrations................................................. 13
        7.1 Single point of failure...................................... 13
        7.2.  ALG complexity............................................. 14
        7.3. TCP state violations........................................ 15
        7.4.  Symmetric state management................................. 16
        7.5.  Need for a globally unique FQDN when advertising public
              services................................................... 18
        7.6.  L2TP tunnels increase frequency of address collisions...... 19
        7.7.  Centralized data collection system report correlation...... 20
       8.  IPv6.......................................................... 21
       9.  Security Considerations....................................... 22
       10.  Deployment Guidelines........................................ 23
       11.  Summary...................................................... 24
       12.  References................................................... 27

    Hain                         Informational                      [Page 1]

    RFC 2993           Architectural Implications of NAT       November 2000

       13.  Acknowledgments.............................................. 28
       14.  Author's Address............................................. 28
       15.  Full Copyright Statement..................................... 29

    1.  Introduction

       Published in May 1994, written by K. Egevang and P. Francis, RFC-1631
       [2] defined NAT as one means to ease the growth rate of IPv4 address
       use.  But the authors were worried about the impact of this
       technology.  Several places in the document they pointed out 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.'

       Now, six years later and in spite of the prediction, the use of NATs
       is becoming widespread in the Internet.  Some people are proclaiming
       NAT as both the short and long term solution to some of the
       Internet's address availability issues and questioning the need to
       continue the development of IPv6.  The claim is sometimes made that
       NAT 'just works' with no serious effects except on a few legacy
       applications.  At the same time others see a myriad of difficulties
       caused by the increasing use of NAT.

       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 NAT
          transparency.  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).
       -  An opposing view of NAT is that of a malicious technology, a 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. Reality lies
          somewhere in between these extreme viewpoints.

       In any case it is clear NAT affects the transparency of end-to-end
       connectivity for transports relying on consistency of the IP header,
       and for protocols which carry that address information in places
       other than the IP header.  Using a patchwork of consistently
       configured application specific gateways (ALG's), endpoints can work
       around some of the operational challenges of NAT.  These operational
       challenges vary based on a number of factors including network and

    Hain                         Informational                      [Page 2]

    RFC 2993           Architectural Implications of NAT       November 2000

       application topologies and the specific applications in use.  It can
       be relatively easy to deal with the simplest case, with traffic
       between two endpoints running over an intervening network with no
       parallel redundant NAT devices.  But things can quickly get quite
       complicated when there are parallel redundant NAT devices, or where
       there are more distributed and multi-point applications like multi-
       party document sharing.  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 update all endpoints of a given application or
       service.

       The architectural intent of NAT is to divide the Internet into
       independent address administrations, (also see "address realms",
       RFC-2663 [3]) specifically facilitating casual use of private address
       assignments RFC-1918 [4].  As noted by Carpenter, et al RFC-2101 [5],
       once private use addresses were deployed in the network, addresses
       were guaranteed to be ambiguous.  For example, when simple NATs are
       inserted into the network, the process of resolving names to or from
       addresses becomes dependent on where the question was asked.  The
       result of this division is to enforce a client/server architecture
       (vs. peer/peer) where the servers need to exist in the public address
       realm.

       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 (discussed further below), which notes that certain
       functions can only be performed in the endpoints, thus they are in
       control of the communication, and the network should be a simple
       datagram service that moves bits between these points.  Restated, the
       endpoint applications are often the only place capable of correctly
       managing the data stream.  Removing this concern from the lower layer
       packet-forwarding devices streamlines the forwarding process,
       contributing to system-wide efficiency.

       Another advantage is that the network does not maintain per
       connection state information.  This allows fast rerouting around
       failures through alternate paths and to better scaling of the overall
       network.  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 destination, first hop
       router(s), and an optional name resolution service.  Packet integrity
       is preserved through the network, and transport checksums and any
       address-dependent security functions are valid end-to-end.

    Hain                         Informational                      [Page 3]

    RFC 2993           Architectural Implications of NAT       November 2000

       NAT devices (particularly the NAPT variety) undermine most of these,
       basic advantages of the end-to-end model, reducing overall
       flexibility, while often increasing operational complexity and
       impeding diagnostic capabilities.  NAT variants such as RSIP [6] have
       recently been proposed to address some of the end-to-end concerns.
       While these proposals may be effective at providing the private node
       with a public address (if ports are available), they do not eliminate
       several issues like network state management, upper layer constraints
       like TCP_TIME_WAIT state, or well-known-port sharing. Their port
       multiplexing variants also have the same DNS limitations as NAPT, and
       each host requires significant stack modifications to enable the
       technology (see below).

       It must be noted that firewalls also break the end-to-end model and
       raise several of the same issues that NAT devises do, while adding a
       few of their own.  But one operational advantage with firewalls is
       that they are generally installed into networks with the explicit
       intent to interfere with traffic flow, so the issues are more likely
       to be understood or at least looked at if mysterious problems arise.
       The same issues with NAT devices can sometimes be overlooked since
       NAT devices are frequently presented as transparent to applications.

       One thing that should be clearly stated up front is, that attempts to
       use a variant of NAT as a simple router replacement may create
       several significant issues that should be addressed before
       deployment.  The goal of this document is to discuss these with the
       intent to raise awareness.

    2.  Terminology

       Recognizing that many of these terms are defined in detail in RFC
       2663 [3], the following are summaries as used in this document.

       NAT - Network Address Translation in simple form is a method by which
       IP addresses are mapped from one address administration to another.
       The NAT function is unaware of the applications traversing it, as it
       only looks at the IP headers.

       ALG - Application Layer Gateway: 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.

       NAT/ALG - combines ALG functions with simple NAT.  Generally more
       useful than pure NAT, because it embeds components for specific
       applications that would not work through a pure NAT.

    Hain                         Informational                      [Page 4]

    RFC 2993           Architectural Implications of NAT       November 2000

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

       Firewall - access control point that may be a special case of an ALG,
       or packet filter.

       Proxy - A relay service designed into a protocol, rather than
       arbitrarily inserted.  Unlike an ALG, the application on at least one
       end must be aware of the proxy.

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

       Dynamic NAT - provides dynamic mapping between address spaces
       normally used with a relatively large number of addresses on one side
       (private space) to a few addresses on the other (public space).

       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.  See 4.1.2 of RFC-2663.  This permits multiple
       endpoints to share and appear as a single IP address.

       RSIP - Realm Specific IP allows endpoints to acquire and use the
       public address and port number at the source.  It includes mechanisms
       for the private node to request multiple resources at once.  RSIP
       clients must be aware of the address administration boundaries, which
       specific administrative area its peer resides in for each
       application, and the topology for reaching the peer.  To complete a
       connection, the private node client requests one or more addresses
       and/or ports from the appropriate RSIP server, then initiates a
       connection via that RSIP server using the acquired public resources.
       Hosts must be updated with specific RSIP software to support the
       tunneling functions.

       VPN - For purposes of this document, 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.  Frequently the 2nd instance of IP
       uses a different set of IP addresses.

       AH - IP Authentication Header, RFC-2401 [7], which provides data
       integrity, data origin authentication, and an optional anti-replay
       service.

    Hain                         Informational                      [Page 5]

    RFC 2993           Architectural Implications of NAT       November 2000

       ESP - Encapsulating Security Payload protocol, RFC 2401, may provide
       data confidentiality (encryption), and limited traffic flow
       confidentiality.  It also may provide data integrity, data origin
       authentication, and an anti-replay service.

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

       Addressing realm -  a collection of routers and end systems
       exchanging locally unique location knowledge.  (Further defined in
       RFC-2663 NAT Terminology.)  NAT is used a means to distribute address
       allocation authority and provide a mechanism to map addresses from
       one address administration into those of another administration.

    3.  Scope

       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).  Rekhter, et al in 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 in terms of 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, part of the screening technology is a NAT, which
       manages the network locator between the public and private-use
       address spaces, and then, using ALGs adds support for protocols that
       are 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.)

       RFC-1631 limited the scope of NAT discussions to stub appendages of a
       public Internet, that is, networks with a single connection to the
       rest of the Internet.  The use of NAT in situations in which a
       network has multiple connections to the rest of the Internet is
       significantly more complex than when there is only a single

    Hain                         Informational                      [Page 6]

    RFC 2993           Architectural Implications of NAT       November 2000

       connection since the NATs have to be coordinated to ensure that they
       have a consistent understanding of address mapping for each
       individual device.

    4.  End-to-End Model

       The concept of the End-to-End model is reviewed by Carpenter in
       Internet Transparency [8].  One of the key points is "state should be
       maintained only in the endpoints, in such a way that the state can
       only be destroyed when the endpoint itself breaks"; this is termed
       "fate-sharing".  The goal behind fate-sharing is to ensure
       robustness.  As networks grow in size, likelihood of component
       failures affecting a connection becomes increasingly frequent. If
       failures lead to loss of communication, because key state is lost,
       then the network becomes increasingly brittle, and its utility
       degrades.  However, if an endpoint itself fails, then there is no
       hope of subsequent communication anyway.  Therefore the End-to-End
       model argues that as much as possible, only the endpoints should hold
       critical state.

       For NATs, this aspect of the End-to-End model translates into the NAT
       becoming a critical infrastructure element:  if it fails, all
       communication through it fails, and, unless great care is taken to
       assure consistent, stable storage of its state, even when it recovers
       the communication that was passing through it will still fail
       (because the NAT no longer translates it using the same mappings).
       Note that this latter type of failure is more severe than the failure
       of a router; when a router recovers, any communication that it had
       been forwarding previous can continue to be successfully forwarded
       through it.

       There are other important facets to the End-to-End model:

       -  when state is held in the interior of the network, then traffic
          dependent on that state cannot be routed around failures unless
          somehow the state is replicated to the fail-over points, which can
          be very difficult to do in a consistent yet efficient and timely
          fashion.
       -  a key principle for scaling networks to large size is to push
          state-holding out to the edges of the network.  If state is held
          by elements in the core of the network, then as the network grows
          the amount of state the elements must holds likewise grows.  The
          capacities of the elements can become severe chokepoints and the
          number of connections affected by a failure also grows.
       -  if security state must be held inside the network (see the
          discussion below), then the possible trust models the network can
          support become restricted.

    Hain                         Informational                      [Page 7]

    RFC 2993           Architectural Implications of NAT       November 2000

       A network for which endpoints need not trust network service
       providers has a great deal more security flexibility than one which
       does.  (Picture, for example, a business traveler connecting from
       their hotel room back to their home office: should they have to trust
       the hotel's networking staff with their security keys?, or the staff
       of the ISP that supplies the hotel with its networking service?  How
       about when the traveler connects over a wireless connection at an
       airport?)

       Related to this, RFC-2101 notes:
         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 or a NAT.

       In addition, there are distributed applications that assume that IP
       addresses are globally scoped, globally routable, and all hosts and
       applications have the same view of those addresses.  Indeed, a
       standard technique for such applications to manage their additional
       control and data connections is for one host to send to another the
       address and port that the second host should connect to.  NATs break
       these applications.  Similarly, 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 and RSIP
       break these.  For example, a web server may desire to associate a
       connection to port 80 with one to port 443, but due to the possible
       presence of a NATPT, the same IP address no longer ensures the same
       host.

       Limiting such applications is not a minor issue: much of the success
       of the Internet today is due to the ease with which new applications
       can run on endpoints without first requiring upgrades to
       infrastructure elements.  If new applications must have the NATs
       upgraded in order to achieve widespread deployment, then rapid
       deployment is hindered, and the pace of innovation slowed.

    5.  Advantages of NATs

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

       -  By 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 pushes the demand for addresses towards the
          number of active nodes rather than the total number of nodes.

    Hain                         Informational                      [Page 8]

    RFC 2993           Architectural Implications of NAT       November 2000

       -  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 an access
          interface.
       -  Breaking the Internet into a collection of address authorities
          limits the need for continual justification of allocations allows
          network managers to avoid the use of more advanced routing
          techniques such as variable length subnets.
       -  Changes in the hosts may not be necessary for applications that
          don't rely on the integrity of the packet header, or carry IP
          addresses in the payload.
       -  Like packet filtering Firewalls, NAPT, & 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.  Traditional NAT [2] provides a
       relatively simple function that is easily understood.

       Removing hosts that are not currently active lowers address demands
       on the public Internet.  In cases where providers would otherwise 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 reclaiming 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 potential customer connection options and minimizing
       the support matrix, it is possible that ISP provided NATs would lower
       support costs.

       Part of the motivation for NAT is to avoid the high cost of
       renumbering inherent in the current IPv4 Internet.  Guidelines for
       the assignment of IPv4 addresses RFC-2050 [9] mean that ISP customers
       are currently required to renumber their networks if they want to
       switch to a new ISP.  Using a NAT (or a firewall with NAT functions)
       means that only the Internet facing IP addresses must be changed and
       internal network nodes do not need to be reconfigured. Localizing
       address administration to the NAT minimizes renumbering 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 and manage routing table growth, until IPv6 is ready or new
       routing technology reduces the pressure on the routing table.  This
       is accomplished by managing allocations to match actual demand and to
       enforce hierarchical addressing.  An unfortunate byproduct of the

    Hain                         Informational                      [Page 9]

    RFC 2993           Architectural Implications of NAT       November 2000

       current guidelines is that they may end up hampering growth in areas
       where it is difficult to sort out real need from potential hoarding.)
       NAT is effective at masking provider switching or other requirements
       to change addresses, thus mitigates some of the growth issues.

       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 (i.e.: create an application gateway).  This may not be
       possible for all applications (such as IP based authentication in
       SNMP), and even with application gateways in the path it may be
       necessary to modify each end host to be aware when there are
       intermediaries modifying the data.

       Another popular practice is hiding a collection of hosts that provide
       a combined service behind a single IP address (i.e.: 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 processing and I/O capabilities of the NAT/ALG device
       bound the overall performance as it funnels the packets back and
       forth.

    6.  Problems with 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 complicate the use of multi-homing by a site in order to
          increase the reliability of their Internet connectivity. (While
          single routers are a point of fate sharing, the lack of state in a
          router makes creating redundancy trivial.  Indeed, this is on of
          the reasons why the Internet protocol suite developed using a
          connectionless datagram service as its network layer.)
       -  NATs inhibit implementation of security at the IP level.
       -  NATs enable casual use of private addresses.  These uncoordinated
          addresses are subject to collisions when companies using these
          addresses merge or want to directly interconnect using VPNs.
       -  NATs facilitate concatenating existing private name spaces with
          the public DNS.

    Hain                         Informational                     [Page 10]

    RFC 2993           Architectural Implications of NAT       November 2000

       -  Port versions (NAPT and RSIP) increase operational complexity when
          publicly published services reside on the private side.
       -  NATs complicated or may even invalidate the authentication
          mechanism of SNMPv3.
       -  Products may embed a NAT function without identifying it as such.

       By design, NATs impose limitations on flexibility.  As such, extended
       thought about the introduced complications is called for.  This is
       especially true for products where the NAT function is a hidden
       service, such as load balancing routers that re-write the IP address
       to other public addresses.  Since the addresses may be all in
       publicly administered space these are rarely recognized as NATs, but
       they break the integrity of the end-to-end model just the same.

       NATs place constraints on the deployment of applications that carry
       IP addresses (or address derivatives) in the data stream, and they
       operate on the assumption that each session is independent. However,
       there are applications such as FTP and H.323 that use one or more
       control sessions to set the characteristics of the follow-on sessions
       in their control session payload.  Other examples include SNMP MIBs
       for configuration, and COPS policy messages.  Applications or
       protocols like these assume end-to-end integrity of addresses and
       will fail when traversing a NAT.  (TCP was specifically designed to
       take advantage of, and reuse, the IP address in combination with its
       ports for use as a transport address.) To fix how NATs break such
       applications, an Application Level Gateway needs to exist within or
       alongside each NAT.  An additional gateway service is necessary for
       each application that may imbed an address in the data stream.  The
       NAT may also need to assemble fragmented datagrams to enable
       translation of the application stream, and then adjust TCP sequence
       numbers, prior to forwarding.

       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.  See further discussion in
       Illustration 1 below.

       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.  See
       further discussion in Illustration 2 below.

       While RSIP addresses the transparency and ALG issues, for the
       specific case of an individual private host needing public access,
       there is still a node with state required to maintain the connection.

    Hain                         Informational                     [Page 11]

    RFC 2993           Architectural Implications of NAT       November 2000

       Dynamic NAT and RSIP will eventually violate higher layer assumptions
       about address/port number reuse as defined in RFC-793 [10] RFC-1323
       [11].  The TCP state, TCP_TIME_WAIT, is specifically designed to
       prevent replay of packets between the 4-tuple of IP and port for a
       given IP address pair.  Since the TCP state machine of a node is
       unaware of any previous use of RSIP, its attempt to connect to the
       same remote service that its neighbor just released (which is still
       in TCP_TIME_WAIT) may fail, or with a larger sequence number may open
       the prior connection directly from TCP_TIME_WAIT state, at the loss
       of the protection afforded by the TCP_TIME_WAIT state (further
       discussion in 2.6 of RFC-2663 [3]).

       For address translators (which do not translate ports) to comply with
       the TCP_TIME_WAIT requirements, they must refrain from assigning the
       same address to a different host until a period of 2*MSL has elapsed
       since the last use of the address, where MSL is the Maximum Segment
       Lifetime defined in RFC-793 as two minutes.  For address-and-port
       translators to comply with this requirement, they similarly must
       refrain from assigning the same host/port pair until 2*MSL has
       elapsed since the end of its first use.  While these requirements are
       simple to state, they can place a great deal of pressure on the NAT,
       because they temporarily reduce the pool of available addresses and
       ports.  Consequently, it will be tempting or NAT implementers to
       ignore or shorten the TCP_TIME_WAIT requirements, at the cost of some
       of TCP's strong reliability.  Note that in the case where the strong
       reliability is in fact compromised by the appearance of an old
       packet, the failure can manifest itself as the receiver accepting
       incorrect data.  See further discussion in Illustration 3 below.

       It is sometimes argued that NATs simply function to facilitate
       "routing realms", where each domain is responsible for finding
       addresses within its boundaries.  Such a viewpoint clouds the
       limitations created by NAT with the better-understood need for
       routing management.  Compartmentalization of routing information is
       correctly 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 addresses from one address
       realm into those of another realm.

       In particular, it is sometimes erroneously believed that NATs serve
       to provide routing isolation.  In fact, if someone were to define an
       OSPF ALG it would actually be possible to route across a NAT
       boundary.  Rather than NAT providing the boundary, it is the
       experienced operators who know how to limit network topology that
       serve to avoid leaking addresses across a NAT.  This is an
       operational necessity given the potential for leaked addresses to
       introduce inconsistencies into the public infrastructure.

    Hain                         Informational                     [Page 12]

    RFC 2993           Architectural Implications of NAT       November 2000

       One of the greatest concerns from the explosion of NATs is the impact
       on the fledgling efforts at deploying network layer end-to-end 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 is
       guaranteed to fail.  Attempting to use the NAT as a security boundary
       fails when requirement is end-to-end network layer encryption, since
       only the endpoints have access to the keys.  See further discussion
       in Illustration 4 below.

       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.
       These may sound like only medium-grade restrictions for the present,
       but as a basic property of the Internet, not to change years into the
       future, it is highly undesirable.  The issue is that the public
       toward private usage requires administrative mapping for each target
       prior to connection.  If the ISP chooses to provide a standardized
       version of these to lower configuration options, they may find the
       support costs of managing the ALGs will exceed the cost of additional
       address space.  See further discussion in Illustration 6 below.

    7.  Illustrations

     7.1 Single point of failure

       A characteristic 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
       notification could be accomplished with a routing protocol, which
       might require modifications to the hosts so they will listen.)

    Hain                         Informational                     [Page 13]

    RFC 2993           Architectural Implications of NAT       November 2000

                            --------       --------
                           | Host A |-----| Host B |
                            --------   |   --------
                               -----------------
                                 |            |
                              ------        ------
                             | AD 1 |      | AD 2 |
                              ------        ------
                                  \         /
                                    --------
                                   /Internet\
                                   ----------

                                    --------
                                 Illustration 1

       In the traditional case where Access Device (AD) 1 & 2 are routers,
       the single point of failure is the end Host, and the only effort
       needed to maintain the connections through a router or link failure
       is a simple routing update from the surviving router.  In the case
       where the ADs are a NAT variant there will be connection state
       maintained in the active path that would need to be shared with
       alternative NATs.  When the Hosts have open connections through
       either NAT, and it fails, the application connections will drop
       unless the state had been previously moved to the surviving NAT. The
       hosts will still need to acquire a routing redirect.  In the case of
       RSIP, the public side address pool would also need to be shared
       between the ADs to allow movement.  This sharing creates another
       real-time operational complexity to prevent conflicting assignments
       at connection setup.  NAT as a technology creates a point fate
       sharing outside the endpoints, in direct contradiction to the
       original Internet design goals.

     7.2.  ALG complexity

       In the following example of a proposed corporate network, each
       NAT/ALG was to be one or more devices at each physical location, and
       there were to be multiple physical locations per diagramed
       connection.  The logistics of simply updating software on this scale
       is cumbersome, even when all the devices are the same manufacturer
       and model.  While this would also be true with routers, it would be
       unnecessary for all devices to run a consistent version for an
       application to work across an arbitrary path.

    Hain                         Informational                     [Page 14]

    RFC 2993           Architectural Implications of NAT       November 2000

                    ----------------------------------------
                   |           Corporate Network            |
                   | Asia |------| Americas |------| Europe |
                    ------        ----------        --------
                       |                |                |
                   --------         --------         --------
                  |NAT/ALGs|       |NAT/ALGs|       |NAT/ALGs|
                   --------         --------         --------
                       |                |                |
                  --------------------------------------------
                   |                Internet                |
                  --------------------------------------------
                       |                |                |
                   --------         --------         --------
                  |NAT/ALGs|       |NAT/ALGs|       |NAT/ALGs|
                   --------         --------         --------
                       |                |                |
           ------------------     --------------     ----------------
           Home Telecommuters     Branch Offices     Partner Networks
           ------------------     --------------     ----------------

                                    --------
                                 Illustration 2

     7.3. TCP state violations

       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, because it sometimes requires the diversity
       that comes with large-scale use to uncover unusual failure modes. The
       following example illustrates an instance of the problem discussed
       above in section 6.

    Hain                         Informational                     [Page 15]

    RFC 2993           Architectural Implications of NAT       November 2000

                            --------       --------
                           | Host A |-----| Host B |
                            --------   |   --------
                                    --------
                                   |NAT/RSIP|
                                    --------
                                       |
                                    --------
                                   |Internet|
                                    --------
                                       |
                                   ---------
                                  |   Web   |
                                  |  Server |
                                   ---------

                                    --------
                                 Illustration 3

       Host A completes its transaction and closes the web service on TCP
       port 80, and the RSIP releases the public side address used for Host
       A.  Host B attempts to open a connection to the same web service, and
       the NAT assigns then next free public side address which is the same
       one A just released.  The source port selection rules on Host B
       happen to lead it to the same choice that A used.  The connect
       request from Host B is rejected because the web server, conforming to
       the TCP specifications, has that 4-tuple in TIME WAIT for 4 minutes.
       By the time a call from Host B gets through to the helpdesk
       complaining about no access, the requested retry will work, so the
       issue is marked as resolved, when it in fact is an on-going, but
       intermittent, problem.

     7.4.  Symmetric state management

       Operational management of networks incorporating stateful packet
       modifying device is considerably easier if inbound and outbound
       packets traverse the same path.  (Otherwise it's a headache to keep
       state for the two directions synchronized.)  While easy to say, even
       with careful planning it can be difficult to manage using a
       connectionless protocol like IP.  The problem of creating redundant
       connections 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, in spite of frequent or
       simultaneous internal and external topology churn.  Consider the
       following case where the -X- links are broken, or flapping.

    Hain                         Informational                     [Page 16]

    RFC 2993           Architectural Implications of NAT       November 2000

                              --------       --------
                             | Host A |     | Host B |
                             |   Foo  |     |   Bar  |
                              --------       --------
                                  |             |
                                ----          ----
                               |Rtr1|---X1---|Rtr2|
                                ----          ----
                                  |            |
                                 ----         ----
                                |NAT1|       |NAT2|
                                 ----         ----
                                   |          |
                                  --------------
                                 |Rtr         Rtr|
                                 | /  Internet \ |     ---
                                 |Rtr----X2---Rtr|----|DNS|
                                  --------------       ---
                                   |          |
                                   |          |
                              --------       --------
                             | Host C |     | Host D |
                              --------       --------

                                    --------
                                 Illustration 4

       To preserve a consistent view of routing, the best path to the
       Internet for Routers 1 & 2 is via NAT1, while the Internet is told
       the path to the address pool managed by the NATs is best found
       through NAT1.  When the path X1 breaks, Router 2 would attempt to
       switch to NAT2, but the external return path would still be through
       NAT1.  This is because the NAT1 device is advertising availability of
       a pool of addresses.  Directly connected routers in this same
       situation would advertise the specific routes that existed after the
       loss.  In this case, redundancy was useless.

       Consider the case that the path between Router 1 & 2 is up, and some
       remote link in the network X2 is down.  It is also assumed that DNS
       returns addresses for both NATs when queried for Hosts A or B.  When
       Host D tries to contact Host B, the request goes through NAT2, but
       due to the internal routing, 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.

    Hain                         Informational                     [Page 17]

    RFC 2993           Architectural Implications of NAT       November 2000

       In a third case, both Host A & B want to contact Host D, when the
       remote link X2 in the Internet breaks.  As long as the path X1 is
       down, Host B is able to connect, but Host A is cut off.  Without a
       thorough understanding of the remote topology (unlikely since
       Internet providers tend to consider that 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 the redundant
       paths through the NATs are up but only one connection works.  Again,
       this is due to lack of visibility to the topology that is inherent
       when a stateful device is advertising availability to a pool rather
       than the actual connected networks.

       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 understood or resolved.

     7.5.  Need for a globally unique FQDN when advertising public services

       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.  As noted in
       RFC 1123 [12] DNS queries may be resolved via local multicast.
       Connecting the NAT device, and reconfiguring it's 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.

    Hain                         Informational                     [Page 18]

    RFC 2993           Architectural Implications of NAT       November 2000

                              --------       --------
                             | Host A |     | Host B |
                             |   Foo  |-----|   Bar  |
                              --------   |   --------   ---
                                         |-------------|DNS|
                                        ---             ---
                                       |NAT|
                                        ---
                                         |
                                     --------      ---
                                    |Internet|----|DNS|
                                     --------      ---
                                         |
                                        ---
                                       |NAT|
                                        ---             ---
                                         |-------------|DNS|
                              --------   |   --------   ---
                             | Host C |-----| Host D |
                             |   Foo  |     |   Bar  |
                              --------       --------

                                    --------
                                 Illustration 5

       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://D/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
       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.

     7.6.  L2TP tunnels increase frequency of address collisions

       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) frequently accomplished
       using L2TP.  Technically VPN tunnels treat an IP infrastructure as a
       multiplexing substrate allowing the endpoints to build what appear to
       be clear pathways from end-to-end.  These tunnels redefine network
       visibility and increase the likelihood of address collision when

    Hain                         Informational                     [Page 19]

    RFC 2993           Architectural Implications of NAT       November 2000

       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.  L2TP tunnels 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 interface, 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 gateway address of
       Host A from its own private address on the physical interface, thus
       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
       that cannot be resolved.

                  ---------------                     ----------------
                 |  10.10.10.10  |--------L2TP-------| Assigned by A  |
                 |    Host A     |   ---       ---   |    Host B      |
                 |    10.1.1.1   |--|NAT|-----|NAT|--|  10.10.10.10   |
                  ---------------    ---       ---    ----------------

                                    --------
                                 Illustration 6

     7.7.  Centralized data collection system report correlation

       It has been reported that NAT introduces additional challenges when
       intrusion detection systems attempt to correlate reports between
       sensors inside and outside the NAT.  While the details of individual
       systems are beyond the scope of this document, it is clear that a
       centralized system with monitoring agents on both sides of the NAT
       would also need access to the current NAT mappings to get this right.
       It would also be critical that the resulting data be indexed properly
       if there were agents behind multiple NATs using the same address
       range for the private side.

       This also applies to management data collected via SNMP.  Any time
       the data stream carries an IP address; the central collector or ALG
       will need to manipulate the data based on the current mappings in the

    Hain                         Informational                     [Page 20]

    RFC 2993           Architectural Implications of NAT       November 2000

       NAT.

    8.  IPv6

       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.

       If NAT had never been defined, the motivation to resolve the
       dwindling IPv4 address space would be a much greater.  Given that
       NATs are enabling untold new hosts to attach to the Internet daily,
       it is difficult to ascertain the actual impact to the lifetime of
       IPv4, but NAT has certainly extended it.  It is also difficult to
       determine the extent of delay NAT is causing for IPv6, both by
       relieving the pressure, and by redirecting the intellectual cycles
       away from the longer-term solution.

       But at the same time NAT functionality may be a critical facilitator
       in the deployment of IPv6.  There are already 100 million or more
       computers running IPv4 on data networks.  Some of these networks are
       connected to and thus part of the Internet and some are on private
       isolated networks.  It is inconceivable that we could have a "flag
       day" and convert all of the existing IPv4 nodes to IPv6 at the same
       time.  There will be a very long period of coexistence while both
       IPv4 and IPv6 are being used in the Internet and in private networks.
       The original IPv6 transition plan relied heavily on having new IPv6
       nodes also be able to run IPv4 - a "dual stack" approach. When the
       dual stack node looks up another node in the DNS it will get back a
       IPv4 or an IPv6 address in response.  If the response is an IPv4
       address then the node uses IPv4 to contact the other node. And if the
       response is an IPv6 address then IPv6 can be used to make the
       contact.  Turning the NAT into a 6to4 [13]router enables widespread
       deployment of IPv6 while providing an IPv4 path if IPv6 is
       unavailable.  While this maintains the current set of issues for IPv4
       connections, it reestablishes the end-to-end principle for IPv6
       connections.

    Hain                         Informational                     [Page 21]

    RFC 2993           Architectural Implications of NAT       November 2000

       An alternative methodology would be to translate the packets between
       IPv6 and IPv4 at the boarders between IPv4 supporting networks and
       IPv6 supporting networks.  The need for this functionality was
       recognized in [RFC 1752], the document that recommended to the IETF
       that IPv6 be developed and recommended that a set of working groups
       be established to work on a number of specific problems.  Header
       translation (i.e, NAT) was one of those problems.

       Of course, NATs in an IPv6 to IPv4 translation environment encounter
       all of the same problems that NATs encounter in a pure IPv4 and the
       environment and cautions in this document apply to both situations.

    9.  Security Considerations

       NAT (particularly NAPT) actually has the potential to lower overall
       security because it creates the illusion of a security barrier, but
       does so without the managed intent of a firewall.  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 that make internal
       breaches much easier.

       IPsec RFC-2401 [7] defines a set of mechanisms to support packet-
       level authentication and encryption for use in IP networks.  While
       this may be less efficient than application-level security but in the
       words of RFC-1752 [14] "support for basic packet-level authentication
       will provide for the adoption of a much needed, widespread, security
       infrastructure throughout the Internet."

       NATs break IPsec's authentication and encryption technologies because
       these technologies depend on an end-to-end consistency of the IP
       addresses in the IP headers, and therefore may stall further
       deployment of enhanced security across the Internet.  NATs raise a
       number of specific issues with IPsec.  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.
       - The Revised Mode of public key encryption includes the peer
         identity in the encrypted payload.

    Hain                         Informational                     [Page 22]

    RFC 2993           Architectural Implications of NAT       November 2000

       It may be possible to engineer and work around NATs for IPsec on a
       case-by-case basis, but at the cost of restricting the trust model,
       as discussed in section 4 above.  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 RFC-2694 [15], 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 [16], SSL [17], or SSH [18] 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 [19] discusses
       the issues in more detail.

       Arguments that NATs may operate in a secure mode preclude true End-
       to-End security, as the NAT becomes the security endpoint.
       Operationally the NAT must be managed as part of the security domain,
       and in this mode the packets on the unsecured side of the NAT are
       fully exposed.

    10.  Deployment Guidelines

       Given that NAT devices are being deployed at a fairly rapid pace,
       some guidelines are in order.  Most of these cautionary in nature and
       are designed to make sure that the reader fully understands the
       implications of the use of NATs in their environment.

       - 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 administrations.

    Hain                         Informational                     [Page 23]

    RFC 2993           Architectural Implications of NAT       November 2000

       - 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 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 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 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 of RSIP (end-to-end address/port pair use) is lost.
       - For RSIP, determine the probability of TCP_Time_Wait collisions
         when subsequent private side hosts attempt to contact a recently
         disconnected public side service.

    Hain                         Informational                     [Page 24]

    RFC 2993           Architectural Implications of NAT       November 2000

    11.  Summary

       Over the 6-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
       Eases renumbering when providers    Facilitates concatenation of
       change                              multiple name spaces
                                           Breaks IPsec
                                           Stateful points of failure
       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
                                           conflicts
       Lowers ISP support burden           Increases local support burden and
                                           complexity
       Transparent to end systems in some  Unique development for each app
       cases
       Load sharing as virtual host        Performance limitations with scale
       Delays need for IPv4 replacement    May complicate integration of IPv6

    Hain                         Informational                     [Page 25]

    RFC 2993           Architectural Implications of NAT       November 2000

       There have been many discussions lately about the value of continuing
       with IPv6 development when the market place is widely deploying IPv4
       NATs.  A shortsighted 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.  NATs are a diversion from forward motion, but they do
       enable wider participation at the present state.  They also break a
       class of applications, which creates the need for complex work-around
       scenarios.

       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 L2TP 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 tunnel.

       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.

    Hain                         Informational                     [Page 26]

    RFC 2993           Architectural Implications of NAT       November 2000

    12.  References

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

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

       3   Srisuresh, P. and M. Holdrege, "NAT Terminology and
           Considerations", RFC 2663, August 1999.

       4   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
           Lear, "Address Allocation for Private Internets", BCP 5, RFC
           1918, February 1996.

       5   Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
           Behavior Today", RFC 2101, February 1997.

       6   M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP:
           Protocol Specification", Work in Progress, March 2000.

       7   Kent, S. and R. Atkinson, "Security Architecture for IP", RFC
           2401, November 1998.

       8   Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

       9   Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
           Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC
           2050, November 1996.

       10  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
           September 1981.

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

       12  Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123,
           October 1989.

       13  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
           Clouds without Explicit Tunnels", Work in Progress.

       14  Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752,
           January 1995.

       15  Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS
           extensions to NAT", RFC 2694, September 1999.

    Hain                         Informational                     [Page 27]

    RFC 2993           Architectural Implications of NAT       November 2000

       16  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
           1999.

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

       18  T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress,
           August 1998.

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

    13.  Acknowledgments

       Valuable contributions to this document came from the IAB, Vern
       Paxson (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas
       Narten (ibm), Yakov Rekhter (cisco), Pyda Srisuresh, Matt Holdrege
       (lucent), and Eliot Lear (cisco).

    14.  Author's Address

       Tony Hain
       Microsoft
       One Microsoft Way
       Redmond, Wa. USA

       Phone:  1-425-703-6619
       EMail:  tonyhain@microsoft.com

    Hain                         Informational                     [Page 28]

    RFC 2993           Architectural Implications of NAT       November 2000

    Full Copyright Statement

       Copyright (C) The Internet Society (2000).  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 INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Hain                         Informational                     [Page 29]