HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:55:39 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 14 Aug 1998 13:06:00 GMT ETag: "2e7e23-caec-35d43638" Accept-Ranges: bytes Content-Length: 51948 Connection: close Content-Type: text/plain INTERNET DRAFT Michael Borella David Grabelsky Ikhlaq Sidhu Brian Petry 3Com Corp. April 1998 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 ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract 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. Borella et. al. [Page 1] INTERNET DRAFT April 1998 1. Introduction 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 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. This has the undesirable effect that protocols that transmit IP address and port data within packet Borella et. al. [Page 2] INTERNET DRAFT April 1998 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. This document is organized as follows. In Section 3 we present an overview of NAT operation. In Section 4 we discuss some of the difficulties that NAT introduces. In Section 5 we introduce DNAT and provide a high-level outline of DNAT operation as well as examples. In Section 6 we discuss support for protocols from the LAN environment (such as ICMP, ARP and DNS) that DNAT will have to inter-operate with. Section 7 concludes with a look towards future work. 2. Architecture A typical NAT-enabled LAN subnet architecture is shown below. The subnet is assigned the IP address 149.112.240.55 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 (10.0.0.2 and 10.0.0.3) 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 (10.0.0.1) from this space. +----------+ | PC 1 | | +--+ | 10.0.0.2 | | +--------+ +----------+ | 10.0.0.1 | NAT or | 149.112.240.55 +-----------------+ DNAT +------------------ +----------+ | | router | | PC 2 | | +--------+ | +--+ Local (internal) Global (external) | 10.0.0.3 | network network +----------+ A typical NAT- or DNAT-enabled LAN. Borella et. al. [Page 3] INTERNET DRAFT April 1998 We will be using the architecture of this figure throughout this draft. With respect to this architecture, we define the following terminology: - External IP address: The globally routable IP address that is assigned to the NAT- or DNAT-enabled subnet (in our case, 149.112.240.55). 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. 3. 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 Borella et. al. [Page 4] INTERNET DRAFT April 1998 their destination IP address to that of the appropriate host (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 Section 6.4 for details. 4. 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 10.0.0.4 with 149.112.240.55 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 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 Borella et. al. [Page 5] INTERNET DRAFT April 1998 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]. 5. 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. 5.1. Architecture Consider the LAN architecture shown in Section 2. The hosts have their own IP addresses, which must be translated to 149.112.240.55 when these hosts transmit to the Internet. Using DNAT, the TCP/IP stacks of hosts are programmed so that their IP layers use their 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 Borella et. al. [Page 6] INTERNET DRAFT April 1998 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 in Section 5.2. 5.2. 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 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: 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 for ports under 10000, 128 for ports above 10000. - 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. Borella et. al. [Page 7] INTERNET DRAFT April 1998 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. The PDP response is sent from the router to the host either confirming or denying the 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: - 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 block. - Total ports (1 byte): Total number of ports allocated to the host. - Unused (1 byte): Should be 0. Upon receiving a successful PDP response, the host makes note of the block of ports that it may use. It retains these ports in a data structure and flags each as either allocated 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. 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. Borella et. al. [Page 8] INTERNET DRAFT April 1998 The PDP invalidate message is used to invalidate (de-allocate) the ports currently allocated to a host. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 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 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. Borella et. al. [Page 9] INTERNET DRAFT April 1998 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. 5.3 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 in the form of flowcharts. These flowcharts are implementation guidelines and serve to further illustrate the DNAT technique. 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. 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 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. Borella et. al. [Page 10] INTERNET DRAFT April 1998 +-----------------+ | 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 | | | | | 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. Borella et. al. [Page 11] INTERNET DRAFT April 1998 +-----------------+ +-------------->+ 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 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. Borella et. al. [Page 12] INTERNET DRAFT April 1998 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 | +-----------------+ +-----------------+ +-----------------+ DNAT host reception process. 5.4. Example 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 LAN architecture of Section 2 with all hosts and the router running DNAT, and that the DNAT router has allocated source ports 10000-10008 to PC 2 (10.0.0.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 192.156.136.22. 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: 10.0.0.2 | Src: 149.112.240.55 | Src port: 10000 | +----------------------+----------------------+-----------------+ | Dst: 10.0.0.1 | Dst: 192.156.136.22 | Dst port: 21 | +----------------------+----------------------+-----------------+ Outbound FTP control packet on DNAT subnet. Borella et. al. [Page 13] INTERNET DRAFT April 1998 IP header TCP header +----------------------+-----------------+ | Src: 149.112.240.55 | Src port: 10000 | +----------------------+-----------------+ | Dst: 192.156.136.22 | 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 192.156.136.22. The response that arrives back at the DNAT router from the external server is shown below. IP header TCP header +----------------------+-----------------+ | Src: 192.156.136.22 | Src port: 21 | +----------------------+-----------------+ | Dst: 149.112.240.55 | Dst port: 10000 | +----------------------+-----------------+ Inbound FTP control packet on external network. Outer IP header Inner IP header TCP header +----------------------+----------------------+-----------------+ | Src: 10.0.0.1 | Src: 192.156.136.22 | Src port: 21 | +----------------------+----------------------+-----------------+ | Dst: 10.0.0.2 | Dst: 149.112.240.55 | 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 10.0.0.2, 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. Borella et. al. [Page 14] INTERNET DRAFT April 1998 6. Discussion 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. 6.1. ICMP 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. 6.2. DNS 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 facilitate network management. 6.3. 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. 6.4. 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 (149.112.240.55, 80). The DNAT router will Borella et. al. [Page 15] INTERNET DRAFT April 1998 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. 6.5. 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-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. From these discussions we will develop a list of "DNAT-friendly" suggestions for protocol designers. 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. Borella et. al. [Page 16] INTERNET DRAFT April 1998 6.6. Performance 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. 6.7. Persepctive 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. Borella et. al. [Page 17] INTERNET DRAFT April 1998 7. 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 multicasting and security. For the former, the DNAT router must serve as a proxy for internal hosts that wish to join an existing multicast session. For the latter, we are currently developing a version of DNAT that will operate with the IPSEC security association and certificate authority architecture. Details are forthcoming. 8. Acknowledgements The authors would like to thank Dan Nessett, Cyndi Jung and Harry Bryson, George Tsirtsis and Jim Bound for providing feedback on an earlier draft of this document. A tunneling NAT bypass proposal [TO98] using L2TP has been individually developed, but is in a similar spirit as DNAT. 9. 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 http://dijon.nais.com/~nevo/masq/. 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, Diablo. 10. References [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. Borella et. al. [Page 18] INTERNET DRAFT April 1998 [Hain98] T. Hain, "Architectural Implications of NAT," Internet Draft , Mar 1998 (work in progress). [Huit96] C. Huitema, IPv6: The New Internet Protocol, Prentice Hall, 1996. [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 RFC 1918, Feb. 1996. [SE98] P. Srisuresh and K. Egevang, "The IP Network Address Translator (NAT)," Internet Draft , Feb. 1998 (work in progress). [Stev94] W. R. Stevens, TCP/IP Illustrated, Vol. 1, Addison- Wesley, 1994. [TO98] G. Tsirtsis and A. O'Neill, "NAT Bypass for End 2 End `Sensitive' Applications," Internet Draft , Jan. 1998 (work in progress). [TS98] G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)," Internet Draft , Mar. 1998 (work in progress). Authors' Addresses Michael Borella 3Com Advanced Technologies Research Center 1800 W. Central Rd. Mount Prospect IL 60056 (847) 342-6093 mike_borella@mw.3com.com David Grabelsky 3Com Advanced Technologies Research Center 1800 W. Central Rd. Mount Prospect IL 60056 (847) 222-2483 david_grabelsky@mw.3com.com Borella et. al. [Page 19] INTERNET DRAFT April 1998 Ikhlaq Sidhu 3Com Advanced Technologies Research Center 1800 W. Central Rd. Mount Prospect IL 60056 (847) 222-2487 ikhlaq_sidhu@mw.3com.com Brian Petry 3Com 12230 World Trade Dr. San Diego CA 92128 (619) 674-8533 brian_petry@3com.com Borella et. al. [Page 20]