INTERNET DRAFT Michael Borella
David Grabelsky
Ikhlaq Sidhu
Brian Petry
3Com Corp.
April 1998
Distributed Network Address Translation
<draft-borella-aatn-dnat-00.txt>
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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> 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 <draft-borella-aatn-dnat-00.txt> April 1998
[Hain98] T. Hain, "Architectural Implications of NAT," Internet Draft
<draft-iab-nat-implications-00.txt>, 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 <draft-rfced-info- srisuresh-05.txt>,
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 <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
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 <draft-borella-aatn-dnat-00.txt> 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]