INTERNET DRAFT                                       Michael Borella
Expires April 1999                                   David Grabelsky
                                                     Ikhlaq Sidhu
                                                     Brian Petry
                                                     3Com Corp.

                Distributed Network Address Translation

Status of this Memo

   This document is an Internet-Draft.  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 progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).


   NAT (Network Address Translation) has been proposed to extend the
   lifetime of IPv4 by allowing one or more subnets to exist behind a
   single IP address.  It is desirable to support dozens, if not
   hundreds, of nodes on a NAT subnet.  As it is currently defined, NAT
   may not gracefully scale beyond networks containing a few dozen
   nodes.  In particular, the computational burden placed on the NAT
   router may be significant, especially if the router is shared by
   several NAT-enabled subnets.  Additionally, NAT requires that support
   for many protocols be specifically programmed into the translation
   mechanism. In this document, we introduce DNAT (Distributed Network
   Address Translation), an alternative to NAT.  In particular, DNAT
   will eliminate all address and port translation at the router,
   providing an application independent mechanism for sharing an IP
   address amongst many hosts while providing end-to-end connectivity.


   Version 4 of the Internet Protocol (IPv4) contains 32 bits of address
   space, which theoretically allows about four billion individually
   addressable computers to exist on the Internet.  However, overly

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 1]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   generous address allocation schemes of the past have dramatically
   reduced the number of available addresses.  IP version 6 (IPv6), the
   proposed successor to IPv4, contains 128 bits of address space.
   Although code and an upgrade path does exist for IPv6 [Huit96], as of
   this writing there has been some, but not much, deployment of IPv6 in
   the public Internet.  Network Address Translation (NAT) [EP94] has
   been designed as an address-saving bandaid for IPv4.  It allows
   multiple hosts on one or more subnets to share a pool of IP addresses
   (for purposes of simplicity, throughout most of this draft we only
   consider the sharing of a single IP address), where the size of the
   pool is smaller than the number of hosts.

   A strong market in the coming years will be small-office/home-office
   (SOHO) networks consisting of multiple subnets of up to about one
   hundred nodes total, as well as mid-sized corporate networks,
   consisting of several hundred nodes.  These networks may be
   interconnected by MAC-layer bridges or leased lines.  It is likely
   that these networks will have a single point of access to the
   Internet via an Internet Service Provider (ISP) using PPP or a
   similar point- to-point protocol. Traditionally, the ISP would have
   to allocate a block of IP addresses for the network to use.  With
   NAT, IP address space is conserved by allowing all hosts to
   simultaneously use the same IP address for external communication.
   (Due to the scarcity and cost of IP addresses, it may be advantageous
   for the ISP to dynamically allocate IP addresses on demand with DHCP
   [Drom97] or IPCP [Mcgr92].  These on-demand IP addresses could also
   be used with NAT to facilitate Internet connectivity.)  This makes
   NAT an ideal candidate architecture for enabling virtual private
   networks (VPNs) with very few globally-routable IP addresses.  Beyond
   the corporate environment, we expect to see NAT used from within the
   ISP to multiplex the address space of several customers.  We also
   anticipate that NAT will be heavily used at conferences and off-site
   meetings in order to allow attendees to plug their laptops into LAN
   ports and access their organization's network remotely.  Recently,
   NAT extensions have been proposed that will allow translation between
   IPv4 and IPv6 networks [TS98].  Finally, NAT can be utilized by dial-
   up users who want to share a single SLIP or PPP connection between
   multiple PCs in their home.

   Essentially, a NAT router modifies all outgoing packets from LAN
   hosts so that their source IP address is the same but their source
   port numbers are different.  By maintaining a table of source-port to
   host mappings, incoming packets can be routed to the proper
   destinations.  NAT has been deployed in a number of commercial
   routers and gateways.  Implementations also exist for freeware
   operating systems such as Linux and FreeBSD.  Despite growing
   deployment and commercial support, NAT has a fundamental problem - it
   breaks the "end-to-end" model of Internet connectivity and transport.

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 2]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   This has the undesirable effect that protocols that transmit IP
   address and port data within packet payloads will not work with NAT.
   NAT implementations sidestep this issue by coding application
   specific support into the NAT router.  However, this is a clumsy,
   unscalable, and short-term solution.  Furthermore, it is unclear how
   to implement security and authentication protocols, such as IPSEC
   [Atki95] in conjunction with NAT.

   In this draft, we introduce Distributed Network Address Translation,
   or DNAT.  DNAT preserves the end-to-end nature of sessions by
   performing the address translation at the host, rather than at the
   router.  We argue that modifications to existing TCP/IP code at a
   host can enable DNAT.  The DNAT router only needs to assign ports to
   hosts and keep track of these assignments.  We expect that DNAT will
   be greatly favorable to NAT because no application specific support
   is required - DNAT will work "out of the box" with almost any
   existing application-layer protocol.


   A typical NAT-enabled LAN subnet architecture is shown below.  The
   subnet is assigned the IP address by its ISP.  This
   address is bound to the external port of the NAT router and is
   globally routable.  Within the LAN are two PCs with IP addresses
   ( and chosen from part of the well-known private
   address space 10.X.Y.Z [RMKDL96], where X, Y, and Z take on values
   between 0 and 255.  The NAT router's internal port is also assigned
   an IP address ( from this space.

   |   PC 1   |
   |          +--+
   | |  |                 +--------+
   +----------+  | | NAT or |
                 +-----------------+  DNAT  +------------------
   +----------+  |                 | router |
   |   PC 2   |  |                 +--------+
   |          +--+  Local (internal)          Global (external)
   | |        network                    network

                    A typical NAT- or DNAT-enabled LAN.

   We will be using the architecture of this figure throughout this
   draft.  With respect to this architecture, we define the following

   - External IP address: The globally routable IP address that is

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 3]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

     assigned to the NAT- or DNAT-enabled subnet (in our case,  We use this address to communicate with the rest
     of the Internet.

     - Internal IP addresses: The IP addresses are assigned to our hosts
     from the 10.X.Y.Z private domain.

     - Port (address) content: A protocol that transmits a transport-
     layer port number or IP address is said to transmit port (and/or
     address) content.

     - Locally-unique port: A port number that is only used at one host
     on the NAT or DNAT LAN.

     - Incoming traffic: Packets arriving at the NAT or DNAT router from
     the Internet.

     - Outgoing traffic: Packets arriving at the NAT or DNAT router from
     one of the internal (local) hosts that are bound for the Internet.

NAT Operation

   In this section, we describe the operation of NAT, as defined by RFC
   1631 [EP94] and [SE98]. Traditional or "basic" NAT [EP94] consists
   only of the mechanism for translating IP addresses.  In practice,
   "NAT" refers to the use of port numbers to facilitate this
   translation (sometimes called NAPT), as discussed in [SE98]).  NAT
   requires that the router perform all of the address translation
   functionality - no NAT support needs to be built into the hosts.  The
   NAT router performs three tasks:

   - Translation of the source IP address and source port number of
   outgoing packets.

   - Translation of the destination IP address and destination port
   number of incoming packets.

   - Maintenance and updating of a port number to local host table so
   that incoming packets can be demultiplexed to the appropriate hosts
   based on their destination port number.

   In other words, for all outgoing packets, the NAT router translates
   the source IP address to the globally routable IP address assigned to
   its external interface.  (Note that "translation" requires that the
   NAT router change the content of the packet header, and in some
   cases, the payload as well.)  Responses to these packets will be
   addressed to the NAT router.  When they arrive, the NAT router must
   translate the destination IP address to that of the appropriate host

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 4]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   (i.e., the host that sourced the corresponding outgoing packet).
   Since all incoming packets will have the same destination IP address
   when they arrive at the router, some other field in either the IP or
   transport-layer headers must be used as a token to uniquely identify
   a destination host.

   The NAT technique specifies that the destination port number of
   incoming packets is this token. Thus, no local hosts may use the same
   source port number at the same time.  The NAT router keeps track of
   the source port numbers that local hosts are using.  If a local host
   transmits a packet with a source port number that is not unique with
   respect to all of the source ports currently used on the subnet, the
   NAT router will change this port number so that it is unique.

   Note that we are assuming that the local hosts are acting as clients,
   not servers.  In practice, we expect that this will be the case for
   most situations.  However, servers on the local subnet can be
   supported by NAT and DNAT with some effort; see below for details.

Disadvantages of NAT

   When an IP address is translated, the packet's IP and TCP (or UDP)
   checksums must be recalculated (the TCP/UDP checksum includes a
   pseudo-header which contains the packet's source and destination IP
   addresses [Stev94]).  When a port is translated, the packet's TCP (or
   UDP) checksum must be recalculated.  However, since these checksums
   are implemented as 16-bit one's complement, it is only necessary to
   calculate the difference of the port fields before and after
   translation, then add this difference to the current checksum.
   Entries in the router's translation table can be stored and accessed
   efficiently by using standard hash tables.  Thus, the main cost of
   translation is computational.  However, if the NAT router is heavily
   utilized, it may become a performance bottleneck.

   The major drawback to NAT is in handling applications that transmit
   IP addresses and/or port numbers as application data.  For example,
   an FTP client transmits an IP address / port tuple (with the PORT
   command) to an FTP server on a control connection.  The server then
   uses this information to establish a data connection with the client.
   Not only does the IP address (and possibly the port number) within
   the payload need to be translated, this translation may change the
   length of the IP packet. (The IP address and port are sent as ASCII
   data, so replacing an IP address of with will
   increase the size of the data payload by 6 bytes.)  This will result
   in a greater computational requirement for TCP checksum calculation
   (though IP checksum calculation will not be affected since the IP
   checksum only covers the IP header), and requires that the TCP

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 5]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   sequence number be changed.  A running sequence number offset (delta)
   must be maintained throughout the remainder of the connection. This
   delta must be applied to all future control traffic, including
   acknowledgement numbers. Furthermore, IP fragmentation could force
   the PORT command to be split across more than one packet, making the
   task more resource-intensive.

   In general, applications that transmit IP address and/or port number
   information can be supported by NAT. Application-specific code must
   be added to the NAT router so that these applications can be
   identified and their offending payloads translated.  For example,
   most NAT implementations support FTP via an IP-layer kernel module.
   However, adding application-specific code for every application that
   requires support is an inelegant and expensive solution.  Some
   proprietary protocols that transmit IP addresses or ports in a non-
   ASCII format may not be documented well enough for this technique to
   work effectively.  An incomplete, but representative list of
   applications that require specific NAT support is given in Appendix
   A.  Unfortunately, this list contains many next-generation, real-time
   multimedia protocols, of the type that we expect to become very
   popular on the Internet.  In particular, NAT will not operate with
   any sort of end-to-end IP encryption mechanism, such as IPSEC.  A
   more complete treatment of the advantages and disadvantages of NAT is
   given in [Hain98].

DNAT Proposal

   In this section we introduce DNAT, a modified version of NAT in which
   the subnet hosts perform the address translation, and tunnel
   translated packets to the DNAT router. The DNAT router strips off the
   tunnel (out IP header) and forwards the inner packets unaltered on to
   the public network.  In fact, it would be more accurate to say that
   each host constructs externally-bound packets in such a way that
   address translation at the router is not required.  The main
   advantage of DNAT is that it avoids having to code application-
   specific support into the translation implementation.  DNAT also
   distributes some of the processing requirements from the router to
   the hosts, which may enable larger subnets to be supported by a
   single router.


      Consider the LAN architecture shown above.  The hosts have their
      own IP addresses, which must be translated to when
      these hosts transmit to the Internet.  Using DNAT, the TCP/IP
      stacks of hosts are programmed so that their IP layers use their

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 6]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      local addresses (10.X.Y.Z) for communication within the subnet.
      However, packets destined to remote hosts are tunneled through the
      DNAT router.  Thus, each host uses two IP addresses - their
      permanent local address and their subnet address.  The latter is
      the external address of the DNAT router.

      In order to avoid all port translation at the router, we require
      the host to use a set of locally-unique source ports for all
      external communication. The DNAT router allocates blocks of non-
      overlapping, locally-unique source ports to hosts on request.  The
      transport-layer protocols at the hosts must choose a source port
      from their allocated pool.  The process of hosts requesting, and
      the DNAT router allocating, source ports is controlled by the Port
      Distribution Protocol, which is discussed below.

  Port Distribution Protocol

      This section describes the Port Distribution Protocol (PDP) which
      is used on a DNAT LAN to ensure that all hosts use locally-unique
      ephemeral source port numbers.  Currently, we are considering
      implementation of PDP as an ICMP extension and have designed the
      packet format with ICMP in mind.  However, it would reasonable to
      use UDP instead (this would eliminate the need for checksum fields
      in the payload).

      The protocol consists of three types of messages:

      - PDP request

      - PDP response

      - PDP invalidate

      - PDP release

      - PDP ACK

      These messages a detailed below.

      PDP Request

         The PDP request is sent from a host to the router to request a
         block of port numbers. It has the following format in addition
         to an IP header:

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 7]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |     Type      |     Code      |           Checksum            |
            | # Ports Req.  |                  Unused                       |

                                PDP request packet format.

         The fields follow the standard ICMP defined format, and are
         defined as:

         - Type (1 byte): 32.

         - Code (1 byte): 0.

         - Checksum (2 bytes): 16-bit 1's complement of the 1's
         complement sum of the entire request.  For purposes of
         computing the checksum, the checksum field itself is 0.

         - Ports requested (1 byte): number of ports requested by the
         host.  By default this field should be 16 or 32, which is a
         reasonable number for most host's needs.

         - Unused (3 bytes): should be 0.

         A host will transmit a PDP request upon boot (possibly
         associated with BOOTP or DHCP), or if at some point it requires
         more ports than it currently has been allocated.

      PDP Response

         The PDP response is sent from the router to the host either
         confirming or denying a PDP request.  It has the following
         format in addition to an IP header:

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |     Type      |     Code      |           Checksum            |
            |          Lowest Port          | Total Ports   |    Unused     |

                                PDP response packet format.

         The fields are defined as:

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 8]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

         - Type (1 byte): 32

         - Code (1 byte): 1.

         - Checksum (2 bytes): 16-bit 1's complement of the 1's
         complement sum of the entire request.  For purposes of
         computing the checksum, the checksum field itself is 0.

         - Lowest port (2 bytes): Lowest port number allocated in the

         - Total ports (1 byte): Total number of ports allocated to the

         - Unused (1 byte): Should be 0.

         Upon receiving a successful PDP response, the host transmits a
         PDP ACK to the router.  It retains its allocated ports in a
         data structure and flags each as either used or unused.  Upon
         receiving a failed PDP response, the host may send another
         request for fewer ports if necessary.  If the router cannot
         allocate a large enough block of contiguous ports for the host,
         it may respond with a success code, but allocate fewer ports
         than requested. A router may time out and retransmit a PDP
         response if it does not receive a PDP ACK from the targeted

         The router maintains a mapping of ports to internal IP
         addresses in the Port-To-IP (PTIP) table.  An entry in the PTIP
         table is shown below.  There may be multiple entries for the
         same IP address.

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |                       Internal IP Address                     |
            |            Lowest Port         |        Number of Ports       |

                                      PTIP entry format.

      PDP Invalidate

         The PDP invalidate message is used to invalidate (de-allocate)
         the ports currently allocated to a host.  It has the following

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>            [Page 9]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |     Type      |     Code      |           Checksum            |
            |     Port      |                   Unused                      |

                                PDP invalidate packet format.

         The fields are defined as:

         - Type (1 byte): 32

         - Code (1 byte): 2.

         - Checksum (2 bytes): 16-bit 1's complement of the 1's
         complement sum of the entire request.  For purposes of
         computing the checksum, the checksum field itself is 0.

         - Port (1 byte): Port number used by the host.

         - Unused (3 bytes): Should be 0.

         Upon receiving a PDP invalidate, the host transmits a PDP ACK
         to the router.  A router may time out and retransmit a PDP
         invalidate if it does not receive a PDP ACK from the targeted

      PDP Release

         The PDP release message is used to allow a host to explicitly
         inform a DNAT router that it will no longer need a block of
         ports. It has the following format:

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |     Type      |     Code      |           Checksum            |
            |          Lowest Port          | Total Ports   |    Unused     |

                                PDP release packet format.

         The fields are defined as:

         - Type (1 byte): 32

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 10]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

         - Code (1 byte): 3.

         - Checksum (2 bytes): 16-bit 1's complement of the 1's
         complement sum of the entire request.  For purposes of
         computing the checksum, the checksum field itself is 0.

         - Lowest port (2 bytes): Lowest port number released.

         - Total ports (1 byte): Total number of ports released.

         - Unused (1 byte): Should be 0.

         Upon receiving a PDP release message, the router first verifies
         that the sending host has been allocated the block of ports
         that it is releasing, then it removes the PTIP entry for these
         ports.  The router should also transmit a PDP ACK message to
         the host.  A host may time outand transmit a PDP release if it
         does not receive a PDP ACK from the router.

      PDP ACK

         The PDP ACK is sent to acknowledge the receipt of a PDP
         message.  It has the following format:

             0                   1                   2                   3
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
            |     Type      |     Code      |           Checksum            |
            |                             Unused                            |

                                PDP ACK packet format.

         - Type (1 byte): 32

         - Code (1 byte): 8.

         - Checksum (2 bytes): 16-bit 1's complement of the 1's
         complement sum of the entire request.  For purposes of
         computing the checksum, the checksum field itself is 0.

         - Unused (4 bytes): Should be 0.

      It may be possible that two hosts erroneously are allocated
      overlapping blocks of port numbers (possibly as a result of a
      router crash or reboot).  Upon reception of a packet from a host

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 11]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      destined to the Internet, the router must check the PTIP table to
      make sure that the source port number is within the block assigned
      to the host.  If the port number is not assigned to the host, the
      router drops the packet in question and sends a PDP invalidate
      message to the host.  Upon reception of a PDP invalidate message,
      the host must discontinue using all currently allocated ports, and
      request a new block(s) of ports.  The PDP invalidate message may
      also be used to prevent port starvation by forcing a host to de-
      allocate some or all of the ports that it has been allocated.  The
      router should send a PDP invalidate message to any host that has
      not communicated with an external host for more than 10 minutes.
      When a router reboots, it should invalidate all allocated ports by
      sending a PDP invalidate to each host.

      When a port or some set of ports on a host are invalidated, all
      current transactions between the host and some external server
      will be interrupted.  The DNAT router should attempt to "black-
      out" recently invalidated port numbers for a period of time so
      that they are not allocated to a host while an external server may
      still be trying to transmit to them.

      It may be desirable for the router not to allocate the entire
      range of ports (0-65535) to hosts.  A host on the local LAN may
      need to open a passive listen socket for a server.  The act of
      opening this socket will not be propagated below the transport
      layer of the host.  Most well known servers bind to port numbers
      in the 0-1023 range.  However, some will choose arbitrary port
      numbers to use, though most will not choose ports above 10000.  We
      recommend that the router only allocate port numbers above 1023 to
      the hosts.

      The number of ports to allocate to each host is an issue that
      needs further consideration.  The PDP message formats allow the
      host to request up to 255 ports per request.  The router may
      allocate as many as requested or fewer.  The proper number of
      ports per host is likely to be site and application specific.
      While many simple clients may only need a very small number of
      ports (5 or less) busy internal hosts or servers may require many
      more.  Naturally, we do not want a host to be able to be allocated
      all available ports and starve other hosts.  A policing mechanism
      must be built into the DNAT router.  A good DNAT implementation
      will leave this mechanism configurable so that port volume can be
      a site-by-site administrative decision.

   State Diagrams

      In this section, we illustrate the processes that must be followed
      by the local hosts and the DNAT router. We present these processes

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 12]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      in the form of flowcharts.  These flowcharts are implementation
      guidelines and serve to further illustrate the DNAT technique.
      For simplicity, we do not include entries for PDP ACK messages or

      When a host transmits to an external server, it will send tunneled
      IP packets on the local subnet.  The outer IP header will contain
      the host's local IP address as source and the router's local IP
      address as destination. The inner IP header will contain the
      subnet's external IP address as source and the external server's
      IP address as destination.  The source port must be locally-unique
      - if the host does not have a free source port from a block that
      has been given to it by the DNAT router, it must request a new
      block using the PDP request message.  When a host transmits to
      another local host, neither tunnels nor locally-unique source
      ports are required.  This entire process is illustrated in the
      figure below.

      An issue that is not addressed in the figure is how a local host
      can determine whether or not a given IP address that is to be the
      destination of a transmission is local or external.  This issue is
      discussed in more detail below.

      |      Start      +<------------------------------------------------+
      +--------+--------+                                                 |
               |                                                          |
               |                                                          |
               |                                                          |
               v                                                          |
      +--------+--------+      +--------+--------+                        |
      |       Is        |      |    Create IP    |                        |
      |   destination   +-Yes->|    with host    +-------------+          |
      |  address local? |      |    address as   |             |          |
      +--------+--------+      |     source      |             |          |
               |               +-----------------+             |          |
               No                                              |          |
               |                                               |          |
               v                                               v          |
      +--------+--------+      +--------+--------+    +--------+--------+ |
      |   Is there a    |      |     Send PDP    |    |                 | |
      |   free locally  +-No-->+ request to DNAT |    | Transmit packet +-+
      |   unique port   |      |      router     |    |                 |
      |  at this host?  |      +--------+--------+    +--------+--------+
      +--------+--------+               |                      ^
               |                        |                      |
              Yes                       |                      |
               |                        |                      |

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 13]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

               v                        v             +--------+--------+
      +--------+--------+      +--------+--------+    | Build outer IP  |
      | Build transport |      |  Receive block  |    |   header with   |
      |   header with   |<-----+   of locally    |    | host address as |
      | locally unqiue  |      |   unique ports  |    |  source, DNAT   |
      |   source port   |      +--------+--------+    |  router's local |
      +--------+--------+                             |   address as    |
               |                                      |   destination   |
               |                                      +--------+--------+
               |                                               ^
               |               +--------+--------+             |
               |               |  Build inner IP |             |
               +-------------->+   header with   +-------------+
                               |  subnet address |
                               |     as source   |

                          DNAT host transmission process.

      When a tunneled packet arrives at the DNAT router from a local
      host, the router must verify with its PTIP table that the source
      IP address is within the block that has been allocated to the
      host.  If this is not the case, then the router transmits a PDP
      invalidate message to the host and drops the packet.  Otherwise,
      the DNAT router strips off the outer IP header and transmits the
      remaining packet to the server. This process is illustrated below.

               +-------------->+      Start      +<--------------+
               |               +--------+--------+               |
               |                        |                        |
               |                        v                        |
      +--------+--------+      +--------+--------+      +--------+--------+
      | Send PDP        |      | Is the          |      | Strip off outer |
      | invalidate      |      | source port     |      | IP header,      |
      | message to host,+<-No--+ allocated to    +-Yes->+ transmit inner  |
      | drop packet     |      | sending host?   |      | IP packet to    |
      +-----------------+      +-----------------+      | destination     |

                   DNAT router operations on outgoing packets.

      When a packet arrives at the DNAT router from an external host,
      the router first validates in its PTIP that the packet's
      destination port number has been assigned to a host.  If this is
      not the case, the packet is dropped and an ICMP "host unknown"
      error is sent to the external host.  Otherwise, the DNAT router
      finds the local (destination) host's IP address in the PTIP.  It

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 14]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      forms a tunnel to the local host by creating an outer IP header
      with the local host's IP address as destination and its own
      internal IP address as source.  The received packet is appended to
      this outer header, and the tunneled packet is transmitted.  This
      process is illustrated below.

               +-------------->+      Start      +<--------------+
               |               +--------+--------+               |
               |                        |                        |
               |                        v                        |
      +--------+--------+      +--------+--------+      +--------+--------+
      | Drop packet,    |      | Is the          |      | Look up local   |
      | send ICMP error |      | destination     |      | (destination)   |
      | message to      +<-No--+ port assigned   +-Yes->+ host in PTIP,   |
      | sender          |      | to a local host?|      | add outer IP    |
      +-----------------+      +-----------------+      | header with     |
                                                        | local host as   |
                                                        | destination and |
                                                        | DNAT router's   |
                                                        | internal address|
                                                        | as source,      |
                                                        | transmit packet |

                    DNAT router operations on incoming packets.

      When a DNAT host receives a packet it first determines whether or
      not the source is local or external.  This can be done by
      examining the next protocol field of the outer IP header, and
      perhaps the destination of the inner IP header.  If the source is
      local a normal reception procedure can be used.  If the source is
      external, the outer IP header must be stripped off and then a
      normal reception procedure can be used.  This process is
      illustrated below.

               +-------------->+      Start      +<--------------+
               |               +--------+--------+               |
               |                        |                        |
               |                        v                        |
      +--------+--------+      +--------+--------+      +--------+--------+
      | Receive packet  |      | Is the sender   |      | Strip off outer |
      | normally        |      | external?       |      | IP header,      |
      |                 +<-No--+                 +-Yes->+ receiver packet |
      |                 |      |                 |      | normally        |
      +-----------------+      +-----------------+      +-----------------+

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 15]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

                              DNAT host reception process.


      In this section we step through an example of DNAT operation.  Our
      goal is to clarify the preceding section through this example -
      this section does not add to the technical description of DNAT.
      We assume the same LAN architecture as earlier with all hosts and
      the router running DNAT, and that the DNAT router has allocated
      source ports 10000-10008 to PC 2 (  We assume that the
      reader is familiar with the details of FTP.

      Suppose that PC 2 initiates an FTP connection to a external server
      at  PC 2's TCP/IP stack creates the packet shown
      below.  PC 2 has chosen source port 10000.  It tunnels the FTP
      control request through the DNAT router.

          Outer IP header        Inner IP header        TCP header
      | Src:        | Src:  | Src port: 10000 |
      | Dst:        | Dst:  | Dst port: 21    |

                  Outbound FTP control packet on DNAT subnet.

                           IP header           TCP header
                    | Src:  | Src port: 10000 |
                    | Dst:  | Dst port: 21    |

                Outbound FTP control packet on external network.

      After the DNAT router receives the packet on its internal
      interface and verifies that a proper source port number is being
      used, it strips off the outer IP header and transmits the packet
      to  The response that arrives back at the DNAT
      router from the external server is shown below.

                           IP header           TCP header
                    | Src:  | Src port: 21    |
                    | Dst:  | Dst port: 10000 |

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 16]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

                Inbound FTP control packet on external network.

          Outer IP header        Inner IP header        TCP header
      | Src:        | Src:  | Src port: 21    |
      | Dst:        | Dst:  | Dst port: 10000 |

                  Inbound FTP control packet on DNAT subnet.

      The DNAT router looks up the destination port number in the PTIP.
      Finding a mapping from port 10000 to local host, it
      prepends the outer IP header, and transmits this tunneled packet
      on the local subnet.

      An FTP client initiates data connections with the PORT command.
      The client specifies its IP address and the port number for which
      it will open a passive socket.  The server will open a connection
      to this socket and transmit (receive) the data.  In order for this
      operation to work with DNAT, the transport-layer port selection
      code at the local host must give the FTP client a port number from
      the block that has been allocated by the DNAT router. Suppose that
      PC 2 chooses port 10001 to use for a data connection.  When the
      server's data connection SYN packet arrives, the DNAT router knows
      that it must tunnel the packet to PC 2, because the destination
      port number will be in the block allocated to PC 2.  The DNAT host
      must also know to use the global (subnet) IP address when it
      transmits its IP address to the external server.


   In this section we briefly discuss a number of issues that must be
   addressed in order for DNAT to work as seamlessly as possible in a
   production environment.  The purpose of this section is to make it
   clear that none of these issues will seriously impact the deployment
   of DNAT.  In practice, these issues can be addressed in any number of
   ways.  The solutions outlined here are not necessarily the only ones.

   To Tunnel or Not to Tunnel

      In general, a DNAT host must know, for a particular IP address,
      whether it should transmit the packet normally for local delivery,
      or tunnel the packet to the DNAT router.  Since more than one
      subnet may be behind the DNAT router, looking at a local subnet
      mask will not work.  We'd rather not have to propagate routing
      tables to all DNAT hosts.  A simple alternative that will solve
      this problem is to require that the DNAT router knows of all

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 17]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      subnet masks used by the DNAT subnets it is in charge of.  This
      information can be manually entered because it is not expected to
      change often.  Then, if an IP address in question is not on a
      host's local subnet, the host can query the router with the
      address.  The router will return a simple "yes or "no" answer -
      yes, this address is local, or no, it is not.

      Alternatively, a DNAT host could send all packets for destinations
      without an explicit static route to the DNAT router.  If they
      arrive at the DNAT router, it informs the host that it should
      instead tunnel the packet.  The host then acquires a block of
      ports (if necessary) and tunnels the packet (with a locally-unique
      source port number), to the DNAT router.  This approach may
      require considerable changes to the TCP/IP stack at the host,
      since a half-open TCP socket must be discarded.  Likewise, the
      DNAT host could at first tunnel the packets to the router.  If the
      router determines that the destination is local, it would inform
      the host of this fact and the host could then transmit the packet
      in the standard fashion.

      We consider this issue to be open.  Regardless of the solution
      chosen, hosts caching the "locality" of recently-contacted IP
      addresses may be beneficial.


      ICMP sends IP address information in the data portion of a
      message.  DNAT can deal with this by decoding each ICMP message
      type and "knowing" what to do with the enclosed IP headers. The
      DNAT router would have to look inside an ICMP message from the
      Internet and determine which local host should receive the
      message. Most ICMP messages are in response to TCP or UDP
      requests, like "host unreachable" or "time to live expired."
      These have TCP or UDP port numbers inside, and the DNAT router
      should be able to do the translation and tunnel the message to a
      local host.  However, some messages, like "echo" (used by ping)
      and "timestamp" only have an ID value.  DNAT, like regular NAT,
      would have to remember the request ID from a local host so it can
      match up the reply properly.


      In order to support the local addressing scheme of DNAT, DNS must
      be run on the local network. Local DNS entries must not be
      propagated to the external network, but external network DNS
      entries must be available to the hosts on the DNAT subnet.  For
      this reason, it may be desirable to co-locate a DNS server in the
      DNAT router.  While this scheme may impact performance, it will

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 18]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      facilitate network management.

   ARP and DHCP

      An ARP protocol must be run on the DNAT subnet to map local IP
      addresses to MAC addresses.  If DHCP or IPCP is used to assign the
      router's external IP address, the router must broadcast this
      address to all hosts whenever it changes.  The DNAT router must
      not serve as a proxy ARP for any DNAT hosts.

   Incoming Connections to Local Servers

      While connections initiated by a local host can be handled with
      DNAT, the destination of a connection originating from an external
      host may be ambiguous.  For example, assume that a WWW server is
      running on PC 1 at port 80 and another is running on PC 2 at port
      80.  An external host trying to access the server on PC 1 will
      send its request to the IP address / port tuple of
      (, 80).  The DNAT router will not be able to
      determine which host the request should be forwarded to.  This
      problem may not be a severe as it seems when one considers the
      typical architecture of a small business with public WWW or FTP
      sites.  Usually these servers are located outside of the local
      subnet for security purposes.  Thus, customers can retrieve the
      information at these sites without having access to the local
      subnet where proprietary information may exist.

      If a single WWW or FTP server is to be placed on the local subnet,
      connectivity can be facilitated by manually entering the port
      number to IP address mapping in the DNAT server.  As an
      alternative, the socket API of the DNAT hosts could be modified so
      that the DNAT router is automatically notified of the port number
      used when a host opens a passive (listen) socket.  The router then
      decides whether or not to tunnel packets destined to that port to
      the appropriate host based on local policy.

      Note that for purposes of simplicity, we have not addressed the
      fact that multiple external IP address can be assigned to the DNAT
      subnet in the discussion above.  If this is done, then multiple
      servers listening on the same port number can be supported, albeit
      with slightly more complicated code at the hosts and router.

   DNAT-Friendly Protocols

      Despite its flexibility, there are a number of protocols that will
      be difficult to use with DNAT.  For example, consider a peer-to-

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 19]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      peer Internet telephony application that requires both peers to
      listen and transmit data on a particular port.  Since the DNAT
      architecture allows only one host to receive packets on a
      particular port at any given time, two or more such applications
      will not be able to operate concurrently on the DNAT subnet.
      Also, this type of protocol may be hardcoded to use a port number
      that has not been allocated by the DNAT router.  Using fixed port
      numbers is an implementation decision made probably for ease of
      design; however, there is no reason why an application could not
      use an arbitrary port number.  The additional design effort would
      not be great, and would be far out-weighed by the benefit of
      operating in a DNAT environment.

      There has been some discussion of "NAT-friendly" protocols in IETF
      meetings and on NAT mailing lists.  There is evidence that some
      new protocols are being designed with NAT in mind, so it is safe
      to assume that, if DNAT becomes popular, DNAT-friendly design will
      emerge as a desirable feature of new protocols.  In particular, a
      DNAT-friendly protocol will avoid using a hardcoded port number if
      at all possible.  It will always try to use ephemeral ports
      assigned by the DNAT router.  We expect that a mechanism for using
      such ports can be transparently built into the existing socket API
      and transport-layer port-selection code.


      Traditional NAT requires IP address translation, as well as IP and
      TCP/UDP checksum recalculation, at the router for all incoming and
      outgoing packets. Port translation may be necessary as well. The
      router must maintain a translation table with an entry for every
      active session and connection.  DNAT requires that IP headers be
      added or removed at the router, but comparatively little state
      (the PTIP table) is required.  The only other computational
      expense of DNAT is the handling of the PDP.  Protocols that send
      IP address and port numbers as application data, such as FTP or
      H.323, will not require special processing by the router.  This is
      a major advantage, in terms of simplicity, performance, and
      management.  We expect that router throughput will increase
      modestly when using DNAT as opposed to NAT.  End-to-end delay may
      also improve (if less processing is required at the router,
      queueing delays are expected to decrease), but this improvement
      will probably not be significant, given that the individual hosts
      will have to do more work.  Overall, the DNAT's impact on
      performance is encouraging, especially considering that the goal
      of DNAT is to improve scalability and management, not necessarily
      to increase performance.


Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 20]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

      We see DNAT as a piece of a much larger puzzle.  In particular,
      the framework for alternative architectures to NAT will likely
      include many solutions.  In particular, DNAT is one of several
      tunnel-based solutions.  Other tunneling protocols (besides DNAT's
      IP-IP tunnels) may utilize L2TP or IPSEC.  It may be desirable to
      establish tunnels on a session-by-session basis and assign a
      globally-routable IP address as well as locally-unique port blocks
      from within these dynamic tunnels.  In other words, when the DNAT
      host needs to transmit a packet to an external site, it will
      establish a tunnel to the DNAT router.  Within the
      control/negotiation phase of the tunnel, the DNAT router assigns
      an IP address and port numbers for the host to use.  At the end of
      the session, the IP address and ports are de-allocated and the
      tunnel torn down (like traditional NAT, the concept of a session
      will be more clear for TCP than UDP transactions, and in either
      case a timeout mechanism for stale sessions must exist).  The
      actual IP address and port allocation protocol can be a version of
      the PDP presented here, or perhaps a modification of DHCP.  L2TP
      and IPSEC may be more easily extended to support this architecture
      than IP-IP, but the latter has the advantage of being simpler and
      more efficient.  Note that tunnels can also be initiated by the
      DNAT router, thus supporting internal servers.

Conclusions and Future Work

   We have proposed DNAT, an alternative to the NAT architecture that
   may significantly improve the ease of sharing one or more IP
   addresses.  The main disadvantage of DNAT is that it requires TCP/IP
   kernel modification of all local hosts.  However, DNAT does avoid
   many of the headaches involved with NAT, and if DNAT is standardized,
   plug-in implementations should become available for many systems.
   Our current work with DNAT includes a reference implementation as
   well as continuting work within the IETF.  Other issues that we would
   like to address include Mobile IP and security.  For the former, we
   have modified DNAT to operate with Mobile IP home and foreign router
   advertisement message.  For the latter, we are currently developing a
   version of DNAT that will operate with the IPSEC security association
   and certificate authority architecture.

   DNAT has been implemented by an agent other than the authors of this
   draft.  Preliminary reports indicate that the implementation operates
   as described in this draft, and is reasonably reliable and scalable.


   The authors would like to thank Dan Nessett, Cyndi Jung, Harry
   Bryson, George Tsirtsis and Jim Bound for providing feedback on an
   earlier draft of this document.  We'd especially like to thank Bruce

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 21]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   Wootton for his suggestion of the PDP release and PDP ACK messages.
   A tunneling NAT bypass proposal [TO98] using L2TP has been
   individually developed, but is in a similar spirit as DNAT.
   Negotiated Address Reuse (NAR) [Mont98] provides similar
   functionality as that of DNAT, but operates within the context of

Appendix A: Applications that Transmit Address/Port Content as Payload

   This section contains an incomplete list of applications that will
   break plain NAT implementations because they transmit IP address
   and/or port content as packet payload.  Many NAT implementations
   contain code to specifically support one or more of these protocols.
   This list is not exhaustive - for a more up to date list, see

   FTP, IRC, H.323, CUSeeMe, Real Audio, Real Video, Vxtreme / Vosiac,
   VDOLive, VIVOActive, True Speech, RSTP, PPTP, StreamWorks, NTT
   AudioLink, NTT SoftwareVision, Yamaha MIDPlug, iChat Pager, Quake,


   [Atki95] R.  Atkinson, "Security Architecture for the Internet
   Protocol," Internet RFC 1825, Aug. 1995.

   [Drom97] R.  Droms, "Dynamic Host Configuration Protocol," Internet
   RFC 2131, Mar. 1997.

   [EP94] K.  Egevang and P. Francis, "The IP Network Address Translator
   (NAT)," Internet RFC 1631, May 1994.

   [Hain98] T.  Hain, "Architectural Implications of NAT," Internet
   Draft <draft-iab-nat-implications-00.txt>, Mar 1998 (work in

   [Huit96] C.  Huitema, IPv6: The New Internet Protocol, Prentice Hall,

   [Mont98] G. Montenegro, "Negotiated Address Reuse," Internet Draft
   <draft-montenegro-aatn-nar-00.txt>, May 1998 (work in progress).

   [Mcgr92] G.  McGregor, "The PPP Internet Protocol Control Protocol
   (IPCP)," Internet RFC 1332, May 1992.

   [RMKDL96] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J.  de Groot
   and E.  Lear, "Address Allocation for Private Internets," Internet

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 22]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   RFC 1918, Feb. 1996.

   [SE98] P. Srisuresh and K. Egevang, "The IP Network Address
   Translator (NAT)," Internet Draft <draft-rfced-info-
   srisuresh-05.txt>, Feb. 1998 (work in progress).

   [Stev94] W. R. Stevens, TCP/IP Illustrated, Vol. 1, Addison- Wesley,

   [TO98] G. Tsirtsis and A. O'Neill, "NAT Bypass for End 2 End
   `Sensitive' Applications," Internet Draft <draft-tsirtsis- nat-
   bypass-00.txt>, Jan. 1998 (work in progress).

   [TS98] G.  Tsirtsis and P.  Srisuresh, "Network Address Translation -
   Protocol Translation (NAT-PT)," Internet Draft <draft-ietf-ngtrans-
   natpt-01.txt>, Mar.  1998 (work in progress).

Authors' Addresses

   Michael Borella
   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 342-6093

   David Grabelsky
   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 222-2483

   Ikhlaq Sidhu
   3Com Corp.
   Advanced Technologies Research Center
   1800 W. Central Rd.
   Mount Prospect IL 60056
   (847) 222-2487

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 23]

INTERNET DRAFT   Distributed Network Address Translation    October 1998

   Brian Petry
   3Com Corp.
   12230 World Trade Dr.
   San Diego CA 92128
   (619) 674-8533

Borella, et. al.    <draft-borella-aatn-dnat-01.txt>           [Page 24]