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 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.
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
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.
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.
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
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,
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.
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 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
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.
Architecture
Consider the LAN architecture shown above. 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
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
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 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
host.
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
format:
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
host.
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
retransmissions.
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.
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 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 (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.
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 |
+----------------------+-----------------+
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: 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.
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.
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
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.
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
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
(149.112.240.55, 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.
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.
Persepctive
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.
Acknowledgements
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
SOCKS.
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.
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.
[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.
[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,
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 Corp.
Advanced Technologies Research Center
1800 W. Central Rd.
Mount Prospect IL 60056
(847) 342-6093
mike_borella@3com.com
David Grabelsky
3Com Corp.
Advanced Technologies Research Center
1800 W. Central Rd.
Mount Prospect IL 60056
(847) 222-2483
david_grabelsky@3com.com
Ikhlaq Sidhu
3Com Corp.
Advanced Technologies Research Center
1800 W. Central Rd.
Mount Prospect IL 60056
(847) 222-2487
ikhlaq_sidhu@3com.com
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
brian_petry@3com.com
Borella, et. al. <draft-borella-aatn-dnat-01.txt> [Page 24]