One document matched: draft-ford-behave-app-00.txt
Internet Draft B. Ford
Document: draft-ford-behave-app-00.txt M.I.T.
Expires: August 2005 P. Srisuresh
Caymas Systems
D. Kegel
kegel.com
February 2005
Application Design Guidelines for Traversal
of Network Address Translators
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this document is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document defines best current practices by which application
designers can create applications that communicate reliably and
Ford [Page 1]
draft-ford-behave-app-00.txt February 2005
efficiently in the presence of network address translators (NAT),
particularly when the application has a need for "peer-to-peer"-style
(P2P) communication patterns in addition to traditional
client/server-style communication. There is no single NAT traversal
algorithm that will make a P2P application reliably work over all
deployed NATs. Following the guidelines described in this document,
however, allows a P2P application to work reliably over a majority of
existing NATs, as well as all future NATs that conform to the
requirements specified in companion documents. The NAT traversal
techniques described here do not require the use of special proxy or
relay protocols, do not require specific knowledge about the network
topology or the number and type of NATs in the path, and do not
require any low-level modifications to IP or transport-layer
protocols that might require special privileges on the end hosts.
Table of Contents
1. Introduction .................................................
1.1. BEHAVE-compliant versus Legacy NATs .....................
1.2. Explicit Communication with NATs ........................
2. General NAT Traversal Concepts ...............................
2.1. NAT Functions Requiring Traversal Logic .................
2.2. IPv4 versus IPv6 ........................................
2.3. Communication Between Peers Behind Distinct NATs ........
2.4. Short-Circuiting Sessions on Private Networks ...........
2.5. Authenticating Peer-to-Peer Connections .................
3. NAT Traversal for UDP ........................................
3.1. UDP Idle Timeouts .......................................
4. NAT Traversal for TCP ........................................
4.1. Ensuring Robustness ....................................
5. Summary of Requirements ......................................
6. Security Considerations ......................................
1. Introduction
The present-day Internet has seen the ubiquitous deployment of
network address translators (NAT), driven by a variety of practical
challenges such as security and the ongoing depletion of the IPv4
address space. The asymmetric addressing and connectivity regimes
established by NATs, however, cause problems for many applications,
particularly those such as teleconferencing [SIP, H.323] and
multiplayer on-line gaming systems. Such application protocols
require "peer-to-peer" communication directly between arbitrary
hosts, and not just traditional "client/server" communication between
an arbitrary "client" host and a "well-known" server with a global IP
address and DNS name. RFC 3235 [NAT-APPL] already proposes some NAT-
friendly design guidelines for applications, but merely recommends
Ford [Page 2]
draft-ford-behave-app-00.txt February 2005
against using peer-to-peer communication without providing a workable
solution to this problem.
Given the increasing demand for applications that require P2P
communication, in conjunction with the ubiquity of NATs, applications
are increasingly implementing and deploying various workarounds to
this problem. Most of these workarounds take the form of a NAT
traversal or "hole punching" algorithm, by which two "peers" lying
behind one or more NATs cooperate with a well-known "rendezvous
server" to set up a direct peer-to-peer communication path between
them. The rendezvous server is crucial to the initial path setup but
does not take part in the subsequent peer-to-peer data stream.
There are many different NAT traversal algorithms already in use and
currently being explored, however, and due to the lack of
standardization for NAT behavior up to this point, none of these
algorithms can be guaranteed to work reliably over all currently
deployed NATs. Furthermore, without some standardization of NAT
traversal algorithms there is a strong danger that the proliferation
of traversal algorithms may further compound the reliability and
predictability problems that NAT created in the first place.
For this reason, this document defines a set of best current
practices for implementing NAT traversal in applications. The
specific recommendations are described at length in the sections
below and later summarized concicely in Section 5.
1.1. BEHAVE-compliant versus Legacy NATs
The NAT traversal practices set forth here are relatively simple to
implement and are guaranteed to work reliably on all BEHAVE-compliant
NATs, namely those conforming to the behavioral requirements set out
in the companion documents [BEH-GEN, BEH-TCP, BEH-UDP, BEH-IGMP].
These techniques are furthermore known to work in practice with a
wide variety of existing NATs in the most common interconnection
scenarios, even when those NATs are only partially BEHAVE-compliant.
To be considered a "BEHAVE-compliant application", an application
MUST be designed to operate reliably when all NATs in its
communication paths are BEHAVE-compliant NATs. It is also
RECOMMENDED that new applications assume that all NATs in the path
are BEHAVE-compliant, since non-BEHAVE-compliant NATs are expected to
become deprecated quickly, and adding complexity to applications for
the purpose of handling legacy NATs risks introducing additional
unpredictability into the network.
This document does not specifically prohibit applications from
implementing more elaborate NAT traversal algorithms that may
Ford [Page 3]
draft-ford-behave-app-00.txt February 2005
function over a wider variety of non-BEHAVE-compliant, "legacy" NATs.
Some known techniques for operating over such poorly-behaved NATs are
outlined briefly in the companion document [BEH-STATE], and are
described more thoroughly in [NUTSS, P2PNAT, NATBLAST, NATTRAV].
Applications implementing fancier protocols such as these, however,
MUST ensure that their traversal algorithms operate just as
efficiently as the ones specified here over BEHAVE-compliant NATs,
and do not create new security vulnerabilities or unnecessarily
burden network components in the path.
REQ-1 Applications MUST be designed to operate reliably over BEHAVE-
compliant NATs. New applications are RECOMMENDED to assume
that all NATs in the path are BEHAVE-compliant.
1.2. Explicit Communication with NATs
This document focuses exclusively on NAT traversal techniques that do
not require the application to communicate explicitly with the NATs
in the path. Protocols that allow applications to obtain external
communication endpoints through explicit interaction with NATs in the
path are outside the scope of this document. Several such protocols
exist and are documented elsewhere [SOCKS, RSIP, MIDCOM, UPNP], but
so far none of these protocols have become widely accepted.
2. General NAT Traversal Concepts
This section describes requirements and techniques for NAT traversal
that are independent of transport protocol; subsequent sections will
specifically address NAT traversal for the UDP and TCP transport
protocols. For more detailed background information on current
practices in use by existing applications, please refer to the
companion document [BEH-STATE].
2.1. NAT Functions Requiring Traversal Logic in Applications
Commonly-deployed NATs integrate two distinct logical functions, each of
which interferes with peer-to-peer communication in a different way and
thus requires NAT traversal support in applications:
Address Translation:
A NAT modifies the IP-level and often the transport-level header
information in packets flowing across the boundary, in order to
enable many "private" hosts behind the NAT to share the use of a
smaller number of public IP addresses (often just one). Hosts
behind the NAT therefore usually have no unique, permanently
usable address on the public Internet, but instead can only
communicate through temporary public endpoints that the NAT
Ford [Page 4]
draft-ford-behave-app-00.txt February 2005
assigns them dynamically as a result of communication attempts
initiated by hosts on the private network.
When two hosts reside on two different private networks behind
distinct NATs, neither of them has a permanent address that the
other can reach at any time, so in order to establish peer-to-peer
connections the hosts must rely on the temporary public endpoints
their NAT assigns them as a result of prior outgoing
client/server-style communication sessions. Discovering,
exchanging, and using these temporary public endpoints generally
requires that the two hosts first collaborate through a well-known
server on the public Internet that both hosts can reach, as
described below.
Filtering of Unsolicited Traffic:
The filtering function in a typical NAT restricts communication
between a private internal network and the public Internet for
security purposes, by dropping incoming sessions that are deemed
"unsolicited." NATs usually implement configurable filtering
policies. The most common filtering policy implemented by default
in most "off-the-shelf" consumer NAT-routers, however, is simply
to permit a communication session to cross the NAT if and only if
it was initiated from the private network. All packets arriving
from the public Internet are dropped unless they are part of an
existing communication session that was previously initiated by a
host on the private network.
When two hosts reside on two different private networks behind
distinct NATs, an attempt by either host to initiate a peer-to-
peer connection to the other will usually fail, even if the
connection attempt is directed to the correct temporary public
endpoint assigned by the opposite host's NAT, because the opposite
host's NATs will interpret this attempt as unsolicited incoming
traffic and reject it. NAT traversal in this case requires the
two hosts to cooperate, typically by communicating initially
through a well-known server on the public Internet that they can
both reach, so as to make their peer-to-peer connection appear to
each host's NAT as if it was initiated from within that host's own
private network.
The cooperation of two hosts to create a peer-to-peer connection
across NATs does not consitute a violation of the security policy
imposed by the NAT. On the contrary, NAT traversal provides a way
for applications to work *within* the ubiquitous "default" security
policy of filtering unsolicited incoming traffic, implicitly
indicating to their respective NATs that certain peer-to-peer traffic
actually *is* in fact "solicited" by the application and thus should
Ford [Page 5]
draft-ford-behave-app-00.txt February 2005
be permitted under this standard filtering policy. Network firewall
functionality in general is outside the scope of this document, and
this document does not condone any attempts by application developers
to subvert security policies that may be imposed by NATs or
firewalls.
2.2. IPv4 versus IPv6
Although NAT will become deprecated in the long term as the Internet
transitions to IPv6, in the short term NAT is commonly used not just
in pure IPv4 networks, but also as a compatibility mechanism to allow
IPv4 and IPv6 networks to interoperate semi-transparently [NAT-PT].
In addition, due to the critical importance of network security,
firewalls with a policy of filtering unsolicited incoming traffic are
likely to remain commonplace even after the transition to IPv6. The
NAT traversal techniques documented here are therefore likely to be
relevant to both IPv4-based and IPv6-based applications for the
foreseeable future.
REQ-2 Applications that make use of peer-to-peer-style communication
MUST implement NAT the traversal practices specified here when
operating over IPv4, and SHOULD also support NAT traversal
when operating over IPv6.
2.3. Communication Between Peers Behind Distinct NATs
Although the details of NAT traversal vary from one transport
protocol to another depending on how NATs recognize and handle
sessions for that transport, the basic approach to NAT traversal is
transport-independent. We merely assume for now that each transport
uses session endpoints consisting of an (IP address, port number)
pair to identify and differentiate communication sessions, and that
each communication session is uniquely identified by its two
endpoints. We focus here specifically on the one NAT traversal
algorithm recommended here for new applications: for background
information on other deployed NAT traversal techniques, refer to
[BEH-STATE].
Suppose client hosts A and B both have private IP addresses and lie
behind different NATs, as shown below.
Ford [Page 6]
draft-ford-behave-app-00.txt February 2005
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
A peer-to-peer application running on clients A and B, and also on a
well-known rendezvous server S, each use port number 1234 at their
own IP address to form their primary local communication endpoint. A
and B have each initiated communication sessions from their local
endpoint server S's endpoint. As a result of A's outgoing connection
attempt to S, NAT A has dynamically assigned port 62000 at its own
public IP address, 155.99.25.11, to A's session with S, so that S
sees this session as having been initiated from the endpoint
155.99.25.11:62000, rather than from A's original private endpoint of
10.0.0.1:1234. Similarly, B's outgoing connection to S causes NAT B
to assign port 31000 at its own IP address to B's session with S,
thus forming B's public endpoint of 138.76.29.7:31000.
Now suppose that host A wants to establish a communication session
directly with host B. If A just naively initiates a new
communication session to the endpoint B believes itself to be using,
namely 10.1.1.3:1234, then A's connection attempt will either reach
the wrong host - a different host on A's own private network that
happens to have the private IP address 10.1.1.3 - or it will reach no
host at all, because B's private IP address 10.1.1.3 is not routable
over the Internet.
Even if A learns B's temporary public endpoint, 138.76.29.7:31000,
from server S, and attempts to initiate a communication session to
that destination endpoint, then NAT B's firewall functionality will
typically reject this attempt because its source and destination
endpoints do not match those of an existing session previously
initiated from within the private network. (The destination endpoint
of A's connection attempt to B matches the source endpoint of B's
existing session with S, but the source endpoint of A's connection
attempt is of course different.) Similarly, if B makes a unilateral
connection attempt to A's public endpoint, then NAT A will similarly
reject B's attempt. As pointed out above, this difficulty arises
even if NATs A and B perform no address translation but are merely
firewalls with the standard filtering policy of rejecting unsolicited
Ford [Page 7]
draft-ford-behave-app-00.txt February 2005
incoming communication attempts.
In order to operate reliably across NATs and firewalls that reject
unsolicited incomming communication, the client hosts A and B
collaborate with the help of server S to learn each other's public
AND private endpoints, and then each of the two client hosts initate
"approximately simultaneous" connection attempts from their existing
primary local endpoints (the same local endpoints they used
previously for the connection to S), and directed at all of the known
endpoints (public and private) for the other host. In the scenario
illustrated above, A's connection attempt to B's public endpoint is
interpreted by NAT A as a legitimate, outgoing session whose private
source endpoint (10.0.0.1:1234) is the same as that of A's existing
session with S, but whose public destination endpoint
(138.76.29.7:31000) is different. If NAT A is BEHAVE-compliant, it
will translate A's private source endpoint for this new session in
the same way that it did for A's existing session with S, so that the
new session appears on the public Internet to be a session between
A's public endpoint, 155.99.25.11:62000, and B's public endpoint,
138.76.29.7:31000.
In similar fashion, B's "approximately simultaneous" connection
attempt from its private endpoint, 10.1.1.3:1234, to A's public
endpoint, 155.99.25.11:62000, results in NAT B opening a new
translation session that reuses the existing public endpoint for B,
138.76.29.7:31000, which NAT B previously assigned to B's session
with S. NAT B is now set up to allow communication between A's
public endpoint and B's private endpoint, and on the public Internet
this session has the endpoints 155.99.25.11:62000 and
138.76.29.7:31000, the same as the endpoints of the session that A
initiated above toward B's public endpoint. Both NATs are thus set
up to permit communication between these two public endpoints,
translating and forwarding the traffic comprising this session to the
respective client hosts on the private networks as appropriate.
This traversal technique relies on certain aspects of NAT behavior
described fully in the companion documents [BEH-GEN, BEH-TCP, BEH-
UDP]. The technique also relies on the transport protocol allowing a
connection to be initiated actively by two endpoints, rather than
asymmetrically in traditional client/server fashion. Fortunately
both of the two ubiquitous transports, TCP and UDP, allow symmetric
connection initiation in this way.
REQ-3 Application hosts wishing to establish peer-to-peer
communication with the help of a mutually accessible registry
or "rendezvous server", MUST support traversal of NATs that
may be in the paths of one or both hosts, by implementing the
"approximately simultaneous connection attempts" technique
Ford [Page 8]
draft-ford-behave-app-00.txt February 2005
described above.
2.3. Short-Circuiting Sessions on Private Networks
Although the network topology illustrated in the figure above is
typical of the situation seen by P2P applications, it is by no means
the only possible scenario. Only one of the client hosts may be
behind, or one or more of the clients may be located behind two or
more levels of NATs, any number of which may be shared between the
two clients. The general NAT traversal algorithm described above
will work reliably in all of the common topological scenarios
provided that the NATs involved are BEHAVE-compliant. One other
particularly common scenario is worth special consideration, however:
the situation illustrated below, in which the two clients (probably
unknowingly) happen to reside behind the same NAT, and are therefore
located in the same private IP address space.
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
In this scenario, client A has established a session with well-known
server S as before, to which the common NAT has assigned public port
number 62000. Client B has similarly established a session with S,
to which the NAT has assigned public port number 62001. Suppose that
A and B use the NAT traversal technique outlined above to establish a
communication channel using server S as an introducer. If A and B
only attempt simultaneous connections to each other's public
endpoints, 155.99.25.11:62001 and 155.99.25.11:62000 respectively,
then their connection attempts will succeed only if the NAT supports
hairpin translation, as described in [BEH-STATE, BEH-TOP]. Although
hairpin translation is required for a NAT to be considered fully
BEHAVE-compliant, this feature is not yet widely supported by
commonly deployed NATs at the time of this writing. Additionally,
the resulting connection between A and B will be sub-optimal in this
case because all traffic will unnecessarily pass through and be
translated by the NAT, even though the two endpoint hosts are
perfectly capable of communicating directly on their common IP
network.
Ford [Page 9]
draft-ford-behave-app-00.txt February 2005
To address this problem, it is recommended that P2P applications make
simultaneous connection attempts both to the private endpoints and
the public endpoints of the desired peer, and use whichever
connection succeeds first in establishing bidirectional communication
between the correct peers. If the two client hosts happen to be
located on the same private network, their connection attempt using
each others' private endpoints is likely to succeed first because it
follows a shorter network path not involving the NAT. If the NAT
does not support hairpin translation, the connection attempts using
the hosts' private endpoints will be the only one to succeed.
REQ-4 Applications implementing NAT traversal MUST exchange both
their IP addresses and transport-level port numbers as known
to themselves, and their IP addresses and port numbers as
known to the common rendezvous server, and make "approximately
simultaneous" connection attempts to each other using both
sets of communication endpoints. Applications SHOULD
additionally be able to exchange and make connection attempts
to more than two endpoint addresses for each peer, in case the
hosts have multiple IP addresses or are registered with
multiple rendezvous servers at different locations in the
network topology.
2.4. Authenticating Peer-to-Peer Connections
It is extremely important not only for security but also for general
robustness that applications implementing a NAT traversal protocol
authenticate any peer-to-peer connections they establish, using some
higher-level application-specific notion of host or user identity.
To operate reliably and securely, applications MUST consider any IP
addresses and port numbers they use for communication with other
hosts to be merely "locators" for hosts, serving as hints indicating
how the desired host might be reached, and not as a reliable
"identifier" for the target host.
Applications MUST NOT in particular merely assume that the first
communication attempt that establishes transport-level connectivity
and elicits a response from a particular target endpoint (IP address
and port number) necessarily represents a connection to the desired
host. Consider the following topological scenario, for example,
which is in fact extremely common in today's Internet:
Ford [Page 10]
draft-ford-behave-app-00.txt February 2005
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
| |
+---------------+ |
| | |
Client X Client A Client B
10.1.1.10:1234 10.1.1.11:1234 10.1.1.10:1234
In this scenario, suppose that NAT A and NAT B are both "off-the-
shelf" consumer NAT routers from the same vendor, which the vendor
has configured by default to act as DHCP servers that hand out
private IP addresses starting at 10.1.1.10. (Most users of such
devices know little or nothing about IP addresses, and therefore are
very unlikely to reconfigure their NATs any more than is necessary to
get them to connect to the Internet.) As before, Client A wishes to
establish a peer-to-peer connection with Client B with the help of
Server S. Client A happened to receive private IP address 10.1.1.11
on NAT A's private network, after Client X had already been assigned
private IP address 10.1.1.10. Client B happens to be the only host
on NAT B's private network, and thus received the first available
private IP address, 10.1.1.10. Client X happens to be running the
same P2P application as is running on clients A and B, and thus has
port 1234 allocated and ready to initiate and accept peer-to-peer
connections.
Suppose Client A follows the NAT traversal approach described above
to establish a peer-to-peer session with Client B. As per the
suggested protocol, A and B each make approximately simultaneous
connection attempts both to each other's public and private
endpoints. B's connection attempt to A's private endpoint,
10.1.1.11:1234, will of course fail because there is no host
10.1.1.11 on NAT B's private network and that IP address is not
globally routable. A's connection attempt to B's public endpoint and
B's connection attempt to A's public endpoint will eventually succeed
in establishing the desired peer-to-peer connection if the two NATs
are BEHAVE-compliant. However, A's connection attempt to B's private
endpoint, 10.1.1.10:1234, will succeed at the transport layer but
connect to the wrong host: namely client X, the host on NAT A's
private network that happens to have the same private IP address as B
does on NAT B's network. Furthermore, this bogus connection to
client X is likely to succeed much more quickly than the actually
desired connection to client B, because X is on the same private
Ford [Page 11]
draft-ford-behave-app-00.txt February 2005
network as A. If the application running on client A does not
properly authenticate its peer-to-peer connections using some higher-
level notion of identity that is independent of IP address, then
client A is likely to assume that its transport-level connection to X
is the desired peer-to-peer connection, cancel its attempt to connect
to B's public endpoint, and subsequently become very confused when
the peer it connected to fails to behave like client B.
Given the prevalence of NAT routers that are pre-configured by their
vendors to hand out private IP addresses via DHCP in more-or-less
deterministic fashion from a standard private IP address block,
different hosts on different private networks are very likely to have
the same private IP addresses, making the above scenerio extremely
likely for P2P applications to encounter. P2P applications therefore
MUST authenticate their transport-layer connections before assuming
they have successfully connected to the desired host. Strong
cryptographic authentication using standard algorithms is of course
preferred.
REQ-5 Applications making peer-to-peer connections MUST authenticate
each other using some higher-level application-specific notion
of identity, before concluding that a successfully-established
transport-level connection has actually reached the intended
host.
2.5. NAT Behavior Detection
In many existing NAT traversal protocols for both TCP and UDP, each
client attempts to determine experimentally certain properties of any
NATs it is located behind before attempting to establish peer-to-peer
connections with other clients. For example, even when a NAT does
not re-use the same public endpoint for all sessions involving a
given private endpoint as required for BEHAVE compliance, it is
sometimes possible to predict which port the NAT will assign to a new
session.
Extensive testing of various existing NATs, however, has revealed
that there is no truly robust way a client can predict how a legacy
NAT will behave in the future based on such experimental tests. Some
legacy NATs behave differently depending on the local port number the
application is using on the client, and can even switch behaviors
dynamically depending on unpredictable timing and network conditions.
Therefore, while applications MAY use such experimental tests in an
attempt to make peer-to-peer connections work across a wider variety
of legacy NATs, they MUST ensure that such methods do not interfere
with the performance or reliability of the application over BEHAVE-
compliant NATs.
Ford [Page 12]
draft-ford-behave-app-00.txt February 2005
REQ-6 Applications SHOULD NOT attempt to predict the future behavior
of NATs in the path through empirical tests. If they do,
applications MUST ensure that any such tests do not delay or
otherwise impede the efficiency of NAT traversal over BEHAVE-
compliant NATs.
3. NAT Traversal for UDP
NAT traversal for UDP, also commonly known as UDP "hole punching",
was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and
first publicly documented informally on the Internet [KEGEL].
Because of UDP's simplicity and its connectionless nature, NAT
traversal for UDP is somewhat simpler, more well-understood, and
hence more universally supported by NATs and applications than is NAT
traversal for TCP, though the principles are the same for both
transports. NAT traversal for UDP has been used in several recent
experimental Internet protocols [TEREDO, ICE] along with various
proprietary or non-standardized protocols. The NAT traversal
approach recommended in this document is also described informally in
[P2PNAT], and other variations of hole punching are explored more
thoroughly in other recent research papers [NUTSS, NATBLASTER,
NATTRAV].
To set up a peer-to-peer UDP session between two clients A and B, we
assume that the clients have each bound to a particular primary local
UDP port, and that the clients have each initiated a UDP session from
this primary local port to a well-known rendezvous server S, as
described earlier. Each client then learns the other's public and
private UDP endpoints from the server S, and simply begins sending
UDP datagrams, from their respective primary local ports (the same
ports they used to contact S), to all of the other client's known
endpoints. If one or both of the clients is behind a BEHAVE-
compliant NAT, the outgoing datagrams from each client will "open a
hole" through the firewall and/or establish a translation session
through the NAT, causing the NAT to forward subsequent incoming
datagrams from the opposite client as desired.
3.1. UDP Idle Timeouts
Because of its inherently connectionless nature, NATs have no fully
reliable way to determine when a UDP communication session crossing
the NAT has terminated, other than simply by assuming the session is
over if it observes a sufficiently long idle period. Applications
whose UDP communication sessions may experience long idle periods
must therefore account for this idle timeout.
As specified in [BEH-UDP], any BEHAVE-compliant NAT is required to
have an idle timeout of at least two minutes, but idle timeouts as
Ford [Page 13]
draft-ford-behave-app-00.txt February 2005
small as 30 seconds have been observed in existing NATs.
Additionally, BEHAVE-compliant NATs are only required to reset the
idle timer on the observance of outgoing traffic leaving the private
network; the NAT may ignore incoming traffic for this purpose, in
order to prevent external hosts from being able to hold UDP sessions
open unilaterally and thus consume NAT resources indefinitely.
Finally, although BEHAVE-compliant NATs are required to reset the
idle timer for ALL sessions for a particular binding (i.e., involving
a particular private port) whenever outbound traffic is seen from
that private port on ANY such session, many existing NATs maintain
UDP idle timers independently on each session.
A NAT's UDP idle timeouts affects P2P applications implementing NAT
traversal in two main ways:
Rendezvous Server Registration Sessions:
Client hosts implementing UDP hole punching typically register
with one or more well-known rendezvous servers, S in the above
scenarios, and expect to be notified by S when a second client
wishes to open a peer-to-peer connection to the first. If a NAT's
UDP idle timer times out while the first client is waiting for
incoming connections, however, then the client will not receive
the notification from S of the second client's desire to connect.
The client therefore MUST send regular outbound "keep-alive"
packets in order to ensure that the registration session remains
open.
If a UDP application merely desires to be compatible with BEHAVE-
compliant NATs, then its outbound keep-alive packets need not
elicit a response from the server unless the application is
concerned about detecting if the server disappears. Also, if a
UDP application maintains active registration sessions with more
than one well-known rendezvous server simultaneously, then it is
sufficient for the application to send outbound keep-alive packets
on only one of these registration sessions as long as all of them
were initiated from the same local UDP port.
If the application desires to function reliably over a broader
range of existing NATs, however, then it may wish to send periodic
outbound keep-alives to each of the rendezvous servers it is
registered with, and ensure that these keep-alives elicit
responses from those servers. This behavior increases
compatibility at the expense of consuming additional network
bandwith, of course.
REQ-7 Applications wishing to accept connections from other peers
after registering via UDP with one or more rendezvous servers
Ford [Page 14]
draft-ford-behave-app-00.txt February 2005
MUST send periodic outgoing UDP "keep-alive" packets to at
least one rendezvous server, at least once every XX seconds.
Peer-to-Peer Sessions:
Once two client hosts have used a rendezvous server to set up a
peer-to-peer UDP communication session between them, this peer-to-
peer session is similarly vulnerable to being closed by any of the
NATs along the path if it goes idle for too long. If the
application is only concerned about compatibility with BEHAVE-
compliant NATs and already sends regular outbound keep-alives to a
registration server as described above, then those keep-alives are
generally sufficient also to maintain the peer-to-peer sessions
the application has opened, as long as those peer-to-peer sessions
involve the same local UDP endpoint.
If an application desires to be more broadly compatible with
existing NATs, however, and tends to have only a few peer-to-peer
sessions active at once, then the application may use keep-alives
to keep peer-to-peer sessions open as well. If an application may
have many idle peer-to-peer sessions at once, however, then it is
recommended that the application NOT use keep-alives on peer-to-
peer sessions, but instead simply be prepared to re-establish
peer-to-peer sessions as needed after an idle period, by simply
re-running the NAT traversal protocol via the original rendezvous
server.
REQ-8 Applications whose peer-to-peer UDP sessions may go idle for
more than XX seconds at a time, SHOULD re-run the original NAT
traversal protocol in an attempt to re-establish the peer-to-
peer session, if they detect that connectivity has been lost.
4. NAT Traversal for TCP
NAT traversal for TCP, or "TCP hole punching," is not yet as well-
understood or widely supported as is UDP hole punching.
Nevertheless, the general technique described in section 2 above
works for TCP as well as UDP, as long as any NATs in the path are
well-behaved. The recommended NAT traversal algorithm for TCP,
described here, makes use of the symmetric TCP connection initiation
feature of TCP as specified in RFC 793 [TCP] and RFC 1122 [REQ-COMM].
This algorithm is guaranteed to work reliably as long as all NATs in
the path are BEHAVE-compliant [BEH-TCP], and as long as the end-hosts
correctly implement the TCP protocol.
Other more complex TCP hole punching algorithms have been developed
and explored elsewhere [NUTSS, NATBLAST, NATTRAV]. These algorithms
use various tricks to work around the nonstandard behaviors of many
Ford [Page 15]
draft-ford-behave-app-00.txt February 2005
existing NATs, and/or to work around bugs in the TCP implementations
of certain existing operating systems. Applications MAY implement
more complex algorithms such as these in order to achieve broader
compatibility with existing NATs and hosts, but applications MUST
ensure that any such alternative algorithm still works reliably and
efficiently over BEHAVE-compliant NATs without substantially
burdening the network and any NATs on the path.
To prepare for TCP NAT traversal, a P2P client application first
binds to an arbitrary local port, which becomes the application's
primary local port, and then uses that port both to listen for
incoming peer-to-peer connections, and to initiate outgoing
connections to rendezvous servers and other peers. Because standard
sockets APIs usually associate TCP sockets with individual TCP
sessions rather than with a local port as with UDP, the application
must typically open multiple TCP sockets - one listen socket and one
or more connect-sockets - and explicitly bind them to the same local
port, using a special socket option usually named SO_REUSEADDR or
SO_REUSEPORT.
Once the TCP application has bound to its primary local port, started
listening on it, and opened connections to one or more rendezvous
servers, it can initiate or accept peer-to-peer connections as
follows. If two clients, A and B, wish to establish a peer-to-peer
connection with the help of a common rendezvous server S, they first
exchange their public and private TCP endpoints through S as
described earlier in section 2. Each client then simultaneously
attempts to initiate outgoing TCP connections from its primary local
port to each of the opposite client's known TCP endpoints (public and
private). As long as any NATs in the path are well-behaved, each
client's outgoing TCP connection attempt will open firewall and/or
translation sessions through any NATs it is located behind,
eventually resulting in a working bidirectional TCP connection
through all intervening NATs on the path, in the same way as for UDP.
Because of timing dependencies and differences in TCP
implementations, applications may observe slightly different (but
functionally equivalent) results when a P2P connection is
successfully established using this method. If client B is not
actually located behind a firewall or NAT, for example, and client
A's first attempt to connect directly to B reaches B before its peer-
to-peer connection request relayed through S reaches B, then B will
accept A's connection via its outstanding listen socket, in
traditional client/server fashion. Even if A's connection request
(SYN packet) to B crosses B's corresponding request to A, resulting
in a TCP simultaneous open at the protocol level, some end-host
operating systems may still "deliver" the resulting connection to the
application via the application's outstanding listen socket for its
Ford [Page 16]
draft-ford-behave-app-00.txt February 2005
primary local port, rather than via the socket by which the
application explicitly initiated a connection to the opposite client.
The application must be prepared to handle all such possible cases
gracefully.
REQ-9 Application hosts implementing peer-to-peer communication via
TCP SHOULD simultaneously listen for incoming peer-to-peer
connections and open connections to rendezvous servers and
other peers from the same primary port.
REQ-10 Applications SHOULD establish peer-to-peer TCP connections by
making "approximately simultaneous" connection attempts from
each peer to all of the known endpoint addresses (both
original and translated) for the opposite peer's primary port.
Applications MAY alternatively establish peer-to-peer TCP
connections via other, asymmetric methods if one or both
endpoint hosts does not correctly support simultaneous TCP
open.
4.1. Ensuring Robustness
Some existing NATs actively reject an apparently-unsolicited incoming
TCP connection by sending back TCP RST or ICMP error packets to the
connection initiator, rather than simply by dropping the incoming
SYN. This behavior can cause one of the clients to observe bogus
timing-dependent connection failures. While this NAT behavior is
deprecated and not allowed for BEHAVE-compliant NATs, P2P
applications can fairly easily make themselves robust against this
behavior. If a client's attempt to initiate a peer-to-peer
connection fails with a "Connection Refused" or "Network Unreachable"
or similar network-related error before some application-defined
peer-to-peer connection timeout has expired, the application SHOULD
simply retry the same outgoing connection attempt. The application
MUST ensure that at least one second has passed between each such
retry, however, in order to avoid accidentally flooding the network
with SYNs if the cause of the error is close to the client and is
thus reported very quickly after each attempt.
REQ-11 Applications SHOULD re-try peer-to-peer TCP connection
attempts that fail due to network conditions other than
timeout, but MUST NOT re-try connecting to a given peer more
than once per second.
5. Summary of Requirements
An application that supports all of the mandatory requirements of this
specification (the "MUST" requirements), is "compliant with this
specification" or "BEHAVE-compliant". An application that supports all
Ford [Page 17]
draft-ford-behave-app-00.txt February 2005
of the mandatory and optional recommendations of this specification
(including the "SHOULD" or "RECOMMENDED" ones) is "fully compliant with
all the mandatory and recommended requirements of this specification."
REQ-1 Applications MUST be designed to operate reliably over BEHAVE-
compliant NATs. New applications are RECOMMENDED to assume
that all NATs in the path are BEHAVE-compliant.
REQ-2 Applications that make use of peer-to-peer-style communication
MUST implement NAT the traversal practices specified here when
operating over IPv4, and SHOULD also support NAT traversal
when operating over IPv6.
REQ-3 Application hosts wishing to establish peer-to-peer
communication with the help of a mutually accessible registry
or "rendezvous server", MUST support traversal of NATs that
may be in the paths of one or both hosts, by implementing the
"approximately simultaneous connection attempts" technique
described above.
REQ-4 Applications implementing NAT traversal MUST exchange both
their IP addresses and transport-level port numbers as known
to themselves, and their IP addresses and port numbers as
known to the common rendezvous server, and make "approximately
simultaneous" connection attempts to each other using both
sets of communication endpoints. Applications SHOULD
additionally be able to exchange and make connection attempts
to more than two endpoints for each peer, in case the hosts
have multiple IP addresses or are registered with multiple
rendezvous servers at different locations in the network
topology.
REQ-5 Applications making peer-to-peer connections MUST authenticate
each other using some higher-level application-specific notion
of identity, before concluding that a successfully-established
transport-level connection has actually reached the intended
host.
REQ-6 Applications SHOULD NOT attempt to predict the future behavior
of NATs in the path through empirical tests. If they do,
applications MUST ensure that any such tests do not delay or
otherwise impede the efficiency of NAT traversal over BEHAVE-
compliant NATs.
REQ-7 Applications wishing to accept connections from other peers
after registering via UDP with one or more rendezvous servers
MUST send periodic outgoing UDP "keep-alive" packets to at
least one rendezvous server, at least once every XX seconds.
Ford [Page 18]
draft-ford-behave-app-00.txt February 2005
REQ-8 Applications whose peer-to-peer UDP sessions may go idle for
more than XX seconds at a time, SHOULD re-run the original NAT
traversal protocol in an attempt to re-establish the peer-to-
peer session, if they detect that connectivity has been lost.
REQ-9 Application hosts implementing peer-to-peer communication via
TCP SHOULD simultaneously listen for incoming peer-to-peer
connections and open connections to rendezvous servers and
other peers from the same primary port.
REQ-10 Applications SHOULD establish peer-to-peer TCP connections by
making "approximately simultaneous" connection attempts from
each peer to all of the known endpoint addresses (both
original and translated) for the opposite peer's primary port.
Applications MAY alternatively establish peer-to-peer TCP
connections via other, asymmetric methods if one or both
endpoint hosts does not correctly support simultaneous TCP
open.
REQ-11 Applications SHOULD re-try peer-to-peer TCP connection
attempts that fail due to network conditions other than
timeout, but MUST NOT re-try connecting to a given peer more
than once per second.
6. Security Considerations
XXX Should some of the "Security Considerations" from the old draft,
which currently appear in the "State of P2P" draft, be moved and/or
copied here?
References
[BEH-GEN] B. Ford and P. Srisuresh, "Design Principles and General
Behavioral Requirements for Network Address Translators",
Internet-Draft (Work In Progress), February 2005.
[BEH-IGMP] D. Wing, "IGMP Proxy Behavior", Internet-Draft (Work In
Progress), October 2004.
[BEH-STATE] P. Srisuresh, B. Ford, and D. Kegel, "State of Peer-to-Peer
(P2P) communication across Network Address Translators
(NATs)", Internet-Draft (Work In Progress), December 2004.
[BEH-TOP] B. Ford and P. Srisuresh, "Topological Complications from
Network Address Translation (NAT-TOP)", Internet-Draft (Work
In Progress), February 2005.
Ford [Page 19]
draft-ford-behave-app-00.txt February 2005
[BEH-TCP] S. Sivakumar, K. Biswas, and B. Ford, "NAT Behavioral
Requirements for TCP", Internet-Draft (Work In Progress),
January 2005.
[BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", Internet-Draft (Work In Progress), January
2005.
[H.323] "Packet-based Multimedia Communications Systems", ITU-T
Recommendation H.323, July 2003.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE):
A Methodology for Network Address Translator (NAT) Traversal
for the Session Initiation Protocol (SIP)", draft-rosenberg-
sipping-ice-00 (Work In Progress), February 2003.
[KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.
http://www.alumni.caltech.edu/~dank/peer-nat.html
[MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A.
Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications with
the IP Network Address Translator", RFC 3027, January 2001.
[NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NATBLAST] Andrew Biggadike and Daniel Ferullo and Geoffrey Wilson and
Adrian Perrig, "NATBLASTER: Establishing TCP Connections
Between Hosts Behind NATs", ACM SIGCOMM Asia Workshop, April
2005.
[NUTSS] Saikat Guha and Yutaka Takeday and Paul Francis, "NUTSS: A
SIP-based Approach to UDP and TCP Network Connectivity",
SIGCOMM 2004 Workshops, August 2004.
[NATTRAV] Jeffrey L. Eppinger, "TCP Connections for P2P Apps: A
Software Approach to Solving the NAT Problem", Carnegie
Mellon Tech Report CMU-ISRI-05-104, January 2005.
[P2PNAT] Bryan Ford, Pyda Srisuresh, and Dan Kegel, "Peer-to-Peer
Communication Across Network Address Translators", USENIX
Annual Technical Conference, April 2005.
Ford [Page 20]
draft-ford-behave-app-00.txt February 2005
[REQ-COMM] R. Braden, Editor, "Requirements for Internet Hosts -
Communication Layers", RFC 1122, October 1989.
[RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L.
Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[TCP] "Transmission Control Protocol", RFC 793, September 1981.
[TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs",
draft-ietf-ngtrans-shipworm-08.txt (Work In Progress),
September 2002.
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001.
http://www.upnp.org/standardizeddcps/igd.asp
Author's Address
Bryan Ford
Computer Science and Artificial Intelligence Laboratory
Massachusetts Institute of Technology
77 Massachusetts Ave.
Cambridge, MA 02139
U.S.A.
Phone: (617) 253-5261
E-mail: baford@mit.edu
Web: http://www.brynosaurus.com/
Pyda Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
U.S.A.
Phone: (707)283-5063
E-mail: srisuresh@yahoo.com
Dan Kegel
Kegel.com
901 S. Sycamore Ave.
Los Angeles, CA 90036
Ford [Page 21]
draft-ford-behave-app-00.txt February 2005
Phone: (323) 931-6717
E-mail: dank@kegel.com
Web: http://www.kegel.com/
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ford [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 09:49:46 |