IAB                                                              T. Hain
   Internet Draft                                                 Microsoft
   Document: draft-iab-nat-implications-04.txt                   April 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.
   Hain             Informational - Expires August 1999                 1
                     Architectural Implications of NAT      February 1999
   Table of Contents
    Status of this Memo ..................................................1
    Abstract .............................................................1
    Introduction .........................................................3
    Definitions ..........................................................5
      Terminology ........................................................5
      Scope ..............................................................7
      End-to-End Model ...................................................7
    Advantages of NATs ...................................................8
    Disadvantages of NATs ...............................................10
    Illustrations .......................................................12
      1.  Single point of failure .......................................12
      2.  ALG complexity ................................................13
      3.  TCP state violations ..........................................13
      4.  Symmetric state management ....................................14
      5.  Need for a globally unique FQDN ...............................15
      6.  Name space collisions .........................................16
      7.  VPNs increase frequency of collisions .........................18
      8.  Address Reuse .................................................19
    Considerations ......................................................20
      IPv6 ..............................................................20
      Security ..........................................................20
      Deployment Guidelines .............................................22
    Summary .............................................................23
    References ..........................................................25
      Acknowledgments ...................................................26
      Author's Addresses ................................................26
      Copyright .........................................................26
   Hain             Informational - Expires August 1999                 2
                     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, there are 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 shortage of IPv4 addresses, caused by the current
      stringent allocation guidelines and drive to limit routing table
      growth, 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 and 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 sucessful 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 Layer Gateways (ALGs),
      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 (like multi-party document sharing) 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 (like an auto manufacturer network
      connecting independent suppliers who may also connect to other
      manufacturers), this may require concerted effort to simultaneously
      upgrade all endpoints of a given application or service.
   Hain             Informational - Expires August 1999                 3
                     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 (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 is a simple datagram
      service that moves bits between these points. Restated, the endpoint
      applications are the only place capable of correctly managing the
      data stream. Removing this concern from the lower layer packet
      routing devices streamlines the forwarding process, contributing to
      system-wide efficiency. 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 destination, first hop router(s), and
      optional name resolution service. 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. (Note: while firewalls also break
      the end-to-end model, they are installed with the explicit intent to
      manage traffic flow, where NAT claims to be transparent.) 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 (when ports/addresses are
      available), they do not deal with the issues of; network state
      management, upper layer constraints like TCP TIME_WAIT state, or
      inbound 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
      One thing that should be clearly stated up front is that any attempt
      to use a NAT variant as a simple router replacement, will create a
      set of issues that must be addressed. Some of these are discussed in
      this document with the intent to raise awareness.
   Hain             Informational - Expires August 1999                 4
                     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
      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 a work around to a specific
      application that NAT breaks.
      DNS/ALG - special case of NAT/ALG, where an ALG for the DNS service
      interacts with the NAT component to manage the contents of a DNS
      Firewall - access control point that may be a special case of an
      ALG, or routing filter.
      Proxy - Special case of an ALG that is a simple relay service
      designed into a protocol, rather than arbitrarily inserted.
      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 has the same requirement to modify Hosts as RSIP.
      RSIP - Realm Specific IP is a generalization of HNAT, including
      mechanisms for the private node to request multiple resources at
      once. RSIP clients must be aware of the address administration
      boundaries, which specific administration the peer resides in for
      each application, and the topology for reaching it. To complete a
      connection, the private node client requests one or more
      addresses/ports from the appropriate RSIP server, then initiates a
      connection via that RSIP server using the acquired public resources.
   Hain             Informational - Expires August 1999                 5
                     Architectural Implications of NAT      February 1999
      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.
      AH - IP Authentication Header which provides connectionless
      integrity, data origin authentication, and an optional anti-replay
      ESP - Encapsulating Security Payload protocol may provide
      confidentiality (encryption), and limited traffic flow
      confidentiality. It also may provide connectionless 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.
      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 created by NAT, attempts to hide them behind the
         well-understood need for routing management. Compartmentalization
         of routing information is actually 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 administration 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. By announcing the private addresses (which may include
         any of the address space from the public side) across the NAT,
         the public infrastructure can become confused. 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                 6
                     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.
    End-to-End Model
      The concept of the End-to-End model is reviewed for current
      attention by Carpenter in Internet Transparency [8]. One of the key
      points, "state should be maintained only in the endpoints, in such a
      way that the state can only be destroyed when the endpoint itself
      breaks" has direct significance when discussing NAT. The highly
      robust nature of a stateless network is lost as NAT is deployed.
      Taken to the extreme, global connectivity would end up depending on
      endless patchwork of application gateways and encapsulation headers.
      Another point is the inclination of applications toward client /
      server, rather than peer / peer due to the ambiguity of endpoint
      identity. While there may be additional reasons for this tendency,
      the intentional spread of ambiguity in the endpoint identifier will
      not lead to an environment where peer /peer is easier.
   Hain             Informational - Expires August 1999                 7
                     Architectural Implications of NAT      February 1999
      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
      those. For example, a web server may desire to associate a
      connection to port 80, with one to port 443, but the same IP address
      no longer insures the same host.
   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 new 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.
   Hain             Informational - Expires August 1999                 8
                     Architectural Implications of NAT      February 1999
      Taken together these explain some of the strong motivations for
      moving quickly with NAT deployment. Traditional NAT [9] provides a
      relatively simple function that is easily understood.
      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 for ISP-provided NATs to lower support costs.
      Part of the motivation for NAT 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 and
      manage routing table growth, 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
      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) [10]. 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.
   Hain             Informational - Expires August 1999                 9
                     Architectural Implications of NAT      February 1999
   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.
        (While single routers have the same property, the lack of state in
        a router makes creating redundancy trivial.)
      - NATs inhibit implementation of security at the IP level.
      - NATs enable casual use of private addresses. These uncoordinated
        addresses are subject to collisions when VPNs traverse multiple
        NATs along a path.
      - NATs facilitate concatenating existing name spaces with the DNS.
      - Port versions (NAPT, HNAPT, & RSIP) increase operational
        complexity when publicly published services reside on the private
        side. This includes the restriction that only one private side
        well-known-port can be accessed through a given public side name.
      - NATs 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 end-to-end integrity 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 H.323 that use one or more
      control sessions to set the characteristics of the follow-on
      sessions in their control session payload. Applications or protocols
      such as this 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 in combination with its ports
      for use as a transport address.) To resolve this, 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. The NAT may also need to assemble fragmented
      datagrams, to enable translation of the application stream, prior to
      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. Further discussion
      in Illustration 1.
   Hain             Informational - Expires August 1999                10
                     Architectural Implications of NAT      February 1999
      In addition, NATs are not transparent to all applications, as they
      Managing simultaneous updates to a large array of ALGs may exceed
      the cost of acquiring additional globally routable addresses.
      Further discussion in Illustration 2.
      While RSIP addresses the transparency and ALG issues, for the
      specific case of individual private host needing public access,
      there is still a node with specific state required to maintain the
      connection. Dynamic NAT, HNAT, and RSIP will all eventually violate
      higher layer assumptions about address/port number reuse as defined
      in RFC-793 [11] RFC-1185 [12] RFC-1323 [13]. 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 node is unaware of any previous
      use via RSIP, their attempt to connect to the same remote service
      its neighbor just released (which is still in TIME_WAIT) may fail,
      or with a larger sequence number may even REOPEN the prior
      connection directly from TIME_WAIT state [14]. Further discussion in
      Illustration 3.
      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 will fail. This combination of required global
      uniqueness of the address, and assured ambiguity by NAT leaves the
      IPsec effort without a workable solution. Attempting to use the NAT
      as a security boundary will fail when requirement is end-to-end
      network layer encryption, since only the endpoints have access to
      the keys. Further discussion in Illustration 4.
      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 at a time. This can 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. 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. Further discussion in Illustration 6.
   Hain             Informational - Expires August 1999                11
                     Architectural Implications of NAT      February 1999
    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.
                             --------       --------
                            | Host A |-----| Host B |
                             --------   |   --------
                                 |            |
                              ------        ------
                             | AD 1 |      | AD 2 |
                              ------        ------
                                   \         /
      In the traditional case where Access Device (AD) 1 & 2 are simple
      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 also need to acquire a 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.
   Hain             Informational - Expires August 1999                12
                     Architectural Implications of NAT      February 1999
    2.  ALG complexity
      In the following (actually proposed) example, each NAT/ALG may be
      one or more devices at each physical location, and there may be
      multiple physical locations per diagramed connection. The logistics
      of simply updating software on this potential scale is cumbersome,
      even when all the devices are all the same manufacturer and model.
                   |           Corporate Network            |
                   | Asia |------| Americas |------| Europe |
                    ------        ----------        --------
                       |                |                |
                   --------         --------         --------
                  |NAT/ALGs|       |NAT/ALGs|       |NAT/ALGs|
                   --------         --------         --------
                       |                |                |
                   |                Internet                |
                       |                |                |
                   --------         --------         --------
                  |NAT/ALGs|       |NAT/ALGs|       |NAT/ALGs|
                   --------         --------         --------
                       |                |                |
           ------------------    --------------       ----------------
           Home Telecommuters    Branch Offices       Partner Networks
           ------------------    --------------       ----------------
    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. The following example outlines one simple
                             --------       --------
                            | Host A |-----| Host B |
                             --------   |   --------
                                   |   Web   |
                                   |  Server |
   Hain             Informational - Expires August 1999                13
                     Architectural Implications of NAT      February 1999
      Host A completes its transaction and closes the web service on TCP
      port 80, and the DNAT/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 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 is really deployed to be
      intermittent. In the case Host B had happened to select a sequence
      number that was higher than that used by Host A, the Web server may
      have REOPENED the prior connection. The results of this action are
      clearly application dependent, but the potential exists for Host B
      to access data intended to be private for Host A.
    4.  Symmetric state management
      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, even with careful planning it is difficult to manage
      using a connectionless protocol like IP. 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 cases where the -X- links are broken, or flapping.
                             --------       --------
                            | Host A |     | Host B |
                            |   Foo  |     |   Bar  |
                             --------       --------
                                 |             |
                               ----          ----
                               ----          ----
                                 |            |
                                ----         ----
                               |NAT1|       |NAT2|
                                ----         ----
                                  |          |
                                |Rtr         Rtr|
                                | /  Internet \ |     ---
                                 --------------       ---
                                  |          |
                                  |          |
                             --------       --------
                            | Host C |     | Host D |
                             --------       --------
   Hain             Informational - Expires August 1999                14
                     Architectural Implications of NAT      February 1999
      To maintain sanity with external routing, the default path for
      Routers 1 & 2 is via NAT1. When the path X1 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, Internet
      access 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 stateful
      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 NAT 1 & 2 when queried for Hosts A or B.
      When Host D tries to contact Host B, the working request goes
      through NAT2, but the Router 2 default will send the reply through
      NAT1. Since the state information for this connection is in NAT2,
      NAT1 will provide a new mapping or fail. Even if the remote path is
      restored, the connection will not be made because the initial
      request was to the public IP of NAT2, while the replies are from the
      public IP of NAT1.
      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
      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 any local outage, but only one connection
      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.
    5.  Need for a globally unique FQDN
      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.
   Hain             Informational - Expires August 1999                15
                     Architectural Implications of NAT      February 1999
                             --------       --------
                            | 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
      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.
    6.  Name space collisions
      The most common installation of NAT technology is to connect the
      existing office, or home where globally unique names were not
      necessary, and local name resolutions may not have used DNS. The
      private name space used in this environment may not be administered,
      thus clients test a string to see if it is currently being used for
      name selection. When this environment is attached to the Internet
      through a NAT without renaming all hosts, the name spaces are
      By facilitating concatenation of multiple name spaces, NAT
      exaggerates a problem in the process of resolving addresses from
      names, or names from addresses. 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
   Hain             Informational - Expires August 1999                16
                     Architectural Implications of NAT      February 1999
      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. Another option for a DNS/ALG
      is discussed below.
      The example below shows a potential configuration as three sites
      deploy NAT. (note: since Host A has no access to the Internet DNS 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 the same 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. 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 system.
                     --------    ---        ---    --------
                    | 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
      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 [15]. 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 access to the mapping state for the final connection.
      (note: see illustration 4 for operational failure potential of
      finding the correct NAT.) The DNS/ALG specifically avoids discussion
      of private nodes finding each other when the DNS server is on the
      far side of a NAPT. While it may appear that this case would never
      occur, it is likely that unique services are provided on individual
   Hain             Informational - Expires August 1999                17
                     Architectural Implications of NAT      February 1999
      machines, thus allowing multiple inbound connections by name that
      map to the same IP address. For this reason, if a port type NAT is
      used, the DNS service must be provided on the private side for
      private resolutions.
    7.  VPNs increase frequency of collisions
      The recent massive 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.
                 ---------------                     ----------------
                |    Host A     |   ---       ---   |    Host B      |
                |  |~~+~~~+~VPN~+~~~+~~| Assigned by A  |
                |   |--|NAT|-----|NAT|--|   |
                 ---------------    ---       ---    ----------------
   Hain             Informational - Expires August 1999                18
                     Architectural Implications of NAT      February 1999
    8.  Address Reuse
      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 /24 of the corporate allocation on the public
      side at each site. To avoid publicized problems with private address
      use, the same half of the publicly allocated address block is
      assigned to the local DHCP service, at each site.
                             --------       --------
                            | Host A |-----| Host B |
                             --------   |   --------
                                        |  134.1.x.x /20  ---
                                       ---                ---
                                        |  134.1.1.x /24
                                   ---------      ---
                                  |   ISP   |----|DNS|
                                   ---------      ---
                                        |  134.1.2.x /24
                                        |  134.1.x.x /20  ---
                             --------   |   --------      ---
                            | Host C |-----| Host D |
                             --------       --------
      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 creating address ambiguity is the source of the
      concerns, not the use of published private address ranges.
   Hain             Informational - Expires August 1999                19
                     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.
      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.
      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 an IPv6 node explicitly supports multiple addresses,
      the disjoint name space described in illustration 6 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) may actually lower 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 without notification 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 lax
      practices making internal breaches that much easier.
      NATs break the defined implementation modes of IPsec [16], 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
   Hain             Informational - Expires August 1999                20
                     Architectural Implications of NAT      February 1999
      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.
      - 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 [17], SSL [18], or SSH [19] 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 [20]
      discusses the issues in more detail.
      Arguments that NAT may operate in a secure mode [21] 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.
      One of the more subtle security exposures is that created by RSIP
      when multiple nodes share an address. Without a means to prevent it,
      the probability is high that a subsequent node will choose the same
      port number as its neighbor. If its choice of sequence numbers is
      higher than the previous connection at closure, this enables the
      subsequent node to REOPEN a connection in TIME-WAIT. The result of
      this action is application dependent, but the potential security
      risk exists for inadvertent data access.
   Hain             Informational - Expires August 1999                21
                     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 administrations.
      - 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 zero, 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. 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, a DNS/ALG will require
        access to the authentication keys for all translated records.
      - 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.
      - For DNAT or RSIP, determine the probability of Time-Wait
        collisions when subsequent private side hosts attempt to contact a
        recently disconnected public side service.
   Hain             Informational - Expires August 1999                22
                     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 and     Breaks end-to-end model
   eases renumbering
   Lowers address utilization           Enables end-to-end address
                                        Stateful points of failure
   Lowers ISP support burden            Increases local support burden and
   Independent address administrations  Requires source specific DNS reply
   avoid justifications to registries   or DNS/ALG
                                        Facilitates concatenation of
                                        multiple name spaces
                                        DNS/ALG breaks DNSsec replies
                                        Breaks IPsec
                                        May allow a node to REOPEN a
                                        connection of another node when the
                                        remote end is in TCP-TIME-WAIT
   Transparent to end systems in some   Unique ALG 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
   Hain             Informational - Expires August 1999                23
                     Architectural Implications of NAT      February 1999
      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
      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                24
                     Architectural Implications of NAT      February 1999
      1  RFC-2026 Bradner, S., " The Internet Standards Process --
         Revision 3", BCP 9, October 1996.
      2  RFC-1631 Egevang, K., Francis, P., "The IP Network Address
         Translator", May 1994
      3  RFC-1918, Rekhter, et al, "Address Allocation for Private
         Internets", February 1996
      4  RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today",
         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  draft-carpenter-transparency-01.txt, B. Carpenter, "Internet
         Transparency", April 1999
      9  draft-ietf-nat-traditional-01.txt P. Srisuresh, K. Egevang,
         "Traditional IP Network Address Translator", October 1998
      10 RFC-2391, P. Srisuresh, D. Gan, "Load Sharing using IP Network
         Address Translation", August 1998
      11 RFC-793, J. Postel, "Transmission Control Protocol", September
      12 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for
         High-Speed Paths", October 1990
      13 RFC-1323, V. Jacobson, R. Braden, D. Borman, " TCP Extensions for
         High Performance", May 1992  (Appendix B.2)
      14 RFC 1122, R. Braden, "Requirements for Internet Hosts", October
      15 draft-ietf-nat-dns-alg-01.txt, P. Srisuresh, G. Tsirtsis, P.
         Akkiraju, A. Heffernan "DNS extensions to Network Address
         Translators", October 1998
      16 RFC 2401, S. Kent, R. Atkinson, "Security Architecture for the
         Internet Protocol", November 1998
   Hain             Informational - Expires August 1999                25
                     Architectural Implications of NAT      February 1999
      17 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS
         Protocol", November 1997
      18 http://home.netscape.com/eng/ssl3/ssl-toc.html   March 1996
      19 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH
         Protocol Architecture", August 1998
      20 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP
         MD5 Signature Option", August 1998
      21 draft-ietf-nat-security-01.txt, P. Srisuresh, "Security Model for
         Network Address Translator", February 1999
      Valuable contributions to this draft came from the IAB, Vern Paxson
      (lbl), Keith Moore (utk), Thomas Narten (ibm), Matt Holdrege
      (Ascend), Pyda Srisuresh (lucent), 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                26