Internet Draft B. Ford
Document: draft-ford-midcom-p2p-00.txt M.I.T.
Expires: March 29, 2004 P. Srisuresh
Caymas Systems
D. Kegel
kegel.com
September 2003
Peer-to-Peer communication across Middleboxes
Status of this Memo
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 (2003). All Rights Reserved.
Abstract
This memo documents the methods which the current peer-to-peer
(P2P) applications use to communicate in the presence of
middleboxes such as firewalls and network address translators
(NAT). Further, the document proposes a new middlebox IP option
to allow deployment of P2P applications more effectively without
significant rework on the middleboxes or the applications. The
goal of this document is to enable immediate, wider deployment
of P2P applications without requiring the use of special proxy,
relay or midcom protocols, while not precluding their use.
Ford, Srisuresh & Kegel [Page 1]
Internet-Draft P2P communication across middleboxes September 2003
Table of Contents
1. Introduction .................................................
2. Terminology ..................................................
3. Techniques for P2P Communication over Middleboxes ............
3.1. Relaying ...............................................
3.2. Connection Reversal ....................................
3.3. UDP Hole Punching ......................................
3.3.1. Clients Behind Different NATs ..................
3.3.2. Clients Behind the Same NAT ....................
3.3.3. Twice NAT and Loopback Translation .............
3.3.4. Consistent Port bindings .......................
3.4. UDP Port Number Prediction .............................
3.5. Simultaneous TCP Open ..................................
4. The Middlebox IP Option ............................
4.1. Option Format ..........................................
4.1.1. Source Check Field .............................
4.1.2. TCP P2P Port Field .............................
4.1.3. UDP P2P Port Field .............................
4.2. Communication modes
5. Application Design Guidelines ................................
6. NAT Design Guidelines ........................................
6.1. Maintaining Consistent port bindings for UDP Ports .....
6.1.1. Preserving Port Numbers ........................
6.2. Maintaining Consistent port bindings for TCP Ports .....
6.3. Proxy Protocols ........................................
7. Security Considerations ......................................
1. Introduction
Present-day Internet has seen ubiquitous deployment of
"middleboxes" such as network address translators(NAT), driven
primarily by the ongoing depletion of the IPv4 address space. The
asymmetric addressing and connectivity regimes established by these
middleboxes, however, have created unique problems for peer-to-peer
(P2P) applications and protocols, such as teleconferencing and
multiplayer on-line gaming. These issues are likely to persist even
into the IPv6 world, where NAT is often used as an IPv4 compatibility
mechanism [NAT-PT], and firewalls will still be commonplace even
after NAT is no longer required.
Currently deployed middleboxes are designed primarily around the
client/server paradigm, in which relatively anonymous client machines
actively initiate connections to well-connected servers having stable
IP addresses and DNS names. Most middleboxes implement an asymmetric
Ford, Srisuresh & Kegel [Page 2]
Internet-Draft P2P communication across middleboxes September 2003
communication model in which hosts on the private internal network
can initiate outgoing connections to hosts on the public network, but
external hosts cannot initiate connections to internal hosts except
as specifically configured by the middlebox's administrator. In the
common case of NAPT, a client on the internal network does not have
a unique IP address on the public Internet, but instead must share
a single public IP address, managed by the NAPT, with other hosts
on the same private network. The anonymity and inaccessibility of
the internal hosts behind a middlebox is not a problem for client
software such as web browsers, which only need to initiate outgoing
connections. This inaccessibility is sometimes seen as a privacy
benefit.
In the peer-to-peer paradigm, however, Internet hosts that would
normally be considered "clients" need to establish communication
sessions directly with each other. The initiator and the responder
might lie behind different middleboxes with neither endpoint
having any permanent IP address or other form of public
network presence. A common on-line gaming architecture, for example,
is for the participating application hosts to contact a well-known
server for initialization and administration purposes. Subsequent
to this, the hosts establish direct connections with each other for
fast and efficient propagation of updates during game play.
Similarly, a file sharing application might contact a well-known
server for resource discovery or searching, but establish direct
connections with peer hosts for data transfer. Middleboxes create
problems for peer-to-peer connections because hosts behind a
middlebox normally have no permanently usable public ports on the
Internet to which incoming TCP or UDP connections from other peers
can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue,
but does not offer any general solutions.
In this document we address the P2P/middlebox problem in three ways.
First, we summarize known methods by which P2P applications can work
around the presence of middleboxes, and provide a set of application
design guidelines based on these practices to make P2P applications
operate more robustly over currently-deployed middleboxes. Second,
we specify a new middlebox IP option with which P2P applications can
indicate their communication behavior and requirements to future P2P-
aware middleboxes. Finally, we provide design guidelines for future
middleboxes to allow them to support P2P applications more
effectively. Our focus is to enable immediate and wide deployment of
P2P applications requiring to traverse middleboxes.
2. Terminology
In this section we first summarize some middlebox terms. We focus here
on the two kinds of middleboxes that commonly cause problems for P2P
Ford, Srisuresh & Kegel [Page 3]
Internet-Draft P2P communication across middleboxes September 2003
applications.
Firewall
A firewall restricts communication between a private internal
network and the public Internet, typically by dropping packets
that are deemed unauthorized. A firewall examines but does
not modify the IP address and TCP/UDP port information in
packets crossing the boundary.
Network Address Translator (NAT)
A network address translator not only examines but also modifies
the header information in packets flowing across the boundary,
allowing many hosts behind the NAT to share the use of a smaller
number of public IP addresses (often one).
Network address translators in turn have two main varieties:
Basic NAT
A Basic NAT maps an internal host's private IP address to a
public IP address without changing the TCP/UDP port
numbers in packets crossing the boundary. Basic NAT is generally
only useful when the NAT has a pool of public IP addresses from
which to make address bindings on behalf of internal hosts.
Network Address/Port Translator (NAPT)
By far the most common, a Network Address/Port Translator examines
and modifies both the IP address and the TCP/UDP port number
fields of packets crossing the boundary, allowing multiple
internal hosts to share a single public IP address simultaneously.
Refer to [NAT-TRAD] and [NAT-TERM] for more general information on
NAT taxonomy and terminology. Additional terms that further classify
NAPT are defined in more recent work [STUN]. When an internal host
opens an outgoing TCP or UDP session through a network address/port
translator, the NAPT assigns the session a public IP address and
port number so that subsequent response packets from the external
endpoint can be received by the NAPT, translated, and forwarded
to the internal host. The effect is that the NAPT establishes a
port binding between (private IP address, private port number) and
(public IP address, public port number). The port binding
defines the address translation the NAPT will perform for the
duration of the session. An issue of relevance to P2P
applications is how the NAT behaves when an internal host initiates
multiple simultaneous sessions from a single (private IP, private
port) pair to multiple distinct endpoints on the external network.
Cone NAT
After establishing a port binding between a (private IP, private
Ford, Srisuresh & Kegel [Page 4]
Internet-Draft P2P communication across middleboxes September 2003
port) tuple and a (public IP, public port) tuple, a cone NAT will
re-use this port binding for subsequent sessions the
application may initiate from the same private IP address and
port number, for as long as at least one session using the port
binding remains active.
For example, suppose Client A in the diagram below initiates two
simultaneous outgoing sessions through a cone NAT, from the same
internal endpoint (10.0.0.1:1234) to two different
external servers, S1 and S2. The cone NAT assigns just one public
endpoint tuple, 155.99.25.11:62000, to both of these sessions,
ensuring that the "identity" of the client's port is maintained
across address translation. Since Basic NATs and firewalls do
not modify port numbers as packets flow across
the middlebox, these types of middleboxes can be viewed as a
degenerate form of Cone NAT.
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
Ford, Srisuresh & Kegel [Page 5]
Internet-Draft P2P communication across middleboxes September 2003
Symmetric NAT
A symmetric NAT, in contrast, does not maintain a consistent
port binding between (private IP, private port) and (public IP,
public port) across all sessions. Instead, it assigns a new
public port to each new session. For example, suppose Client A
initiates two outgoing sessions from the same port as above, one
with S1 and one with S2. A symmetric NAT might allocate the
public endpoint 155.99.25.11:62000 to session 1, and then allocate
a different public endpoint 155.99.25.11:62001, when the
application initiates session 2. The NAT is able to differentiate
between the two sessions for translation purposes because the
external endpoints involved in the sessions (those of S1
and S2) differ, even as the endpoint identity of the client
application is lost across the address translation boundary.
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62001 v
|
Symmetric NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
The issue of cone versus symmetric NAT behavior applies equally
to TCP and UDP traffic.
Cone NAT is further classified according to how liberally the NAT
accepts incoming traffic directed to an already-established (public
IP, public port) pair. This classification generally applies only to
UDP traffic, since NATs and firewalls reject incoming TCP
connection attempts unconditionally unless specifically configured to
do otherwise.
Full Cone NAT
Ford, Srisuresh & Kegel [Page 6]
Internet-Draft P2P communication across middleboxes September 2003
After establishing a public/private port binding for a new
outgoing session, a full cone NAT will subsequently accept
incoming traffic to the corresponding public port from ANY
external endpoint on the public network. Full cone NAT is
also sometimes called "promiscuous" NAT.
Restricted Cone NAT
A restricted cone NAT only forwards an incoming packet directed to
a public port if its external (source) IP address matches the
address of a node to which the internal host has previously sent
one or more outgoing packets. A restricted cone NAT effectively
refines the firewall principle of rejecting unsolicited incoming
traffic, by restricting incoming traffic to a set of "known"
external IP addresses.
Port-Restricted Cone NAT
A port-restricted cone NAT, in turn, only forwards an incoming
packet if its external IP address AND port number match those of
an external endpoint to which the internal host has previously
sent outgoing packets. A port-restricted cone NAT provides
internal nodes the same level of protection against unsolicited
incoming traffic that a symmetric NAT does, while maintaining a
private port's identity across translation.
Finally, in this document we define new terms for classifying
the P2P-relevant behavior of middleboxes:
P2P-Application
P2P-application as used in this document is an application in
which each P2P participant registers with a public
registration server, and subsequently uses either its
private endpoint, or public endpoint, or both, to establish
peering sessions.
P2P-Middlebox
A P2P-Middlebox is middlebox that permits the traversal of
P2P applications.
P2P-firewall
A P2P-firewall is a P2P-Middlebox that provides firewall
functionality but performs no address translation.
P2P-NAT
A P2P-NAT is a P2P-Middlebox that provides NAT functionality, and
may also provide firewall functionality. At minimum, a
P2P-Middlebox must implement Cone NAT behavior for UDP traffic,
allowing applications to establish robust P2P connectivity using
the UDP hole punching technique. Ideally, a P2P-Middlebox should
Ford, Srisuresh & Kegel [Page 7]
Internet-Draft P2P communication across middleboxes September 2003
also understand the Middlebox IP Option and allow applications to
make P2P connections via both TCP and UDP.
3. Techniques for P2P Communication over Middleboxes
This section reviews in detail the currently known techniques for
implementing peer-to-peer communication over existing middleboxes,
from the perspective of the application or protocol designer.
3.1. Relaying
The most reliable, but least efficient, method of implementing peer-
to-peer communication in the presence of a middlebox is to make the
peer-to-peer communication look to the network like client/server
communication through relaying. For example, suppose two client
hosts, A and B, have each initiated TCP or UDP connections with a
well-known server S having a permanent IP address. The clients
reside on separate private networks, however, and their respective
middleboxes prevent either client from directly initiating a
connection to the other.
Server S
|
|
+----------------------+----------------------+
| |
NAT A NAT B
| |
| |
Client A Client B
Instead of attempting a direct connection, the two clients can simply
use the server S to relay messages between them. For example, to
send a message to client B, client A simply sends the message to
server S along its already-established client/server connection, and
server S then sends the message on to client B using its existing
client/server connection with B.
This method has the advantage that it will always work as long as
both clients have connectivity to the server. Its obvious
disadvantages are that it consumes the server's processing power and
network bandwidth unnecessarily, and communication latency between
the two clients is likely to be increased even if the server is well-
connected. The TURN protocol [TURN] defines a method of implementing
relaying in a relatively secure fashion.
Ford, Srisuresh & Kegel [Page 8]
Internet-Draft P2P communication across middleboxes September 2003
3.2. Connection Reversal
The second technique works if only one of the clients is behind a
middlebox. For example, suppose client A is behind a NAT but client
B has a globally routable IP address, as in the following diagram:
Server S
18.181.0.31:1235
|
|
+----------------------+----------------------+
| |
NAT A |
155.99.25.11:62000 |
| |
| |
Client A Client B
10.0.0.1:1234 138.76.29.7:1234
Client A has private IP address 10.0.0.1, and the application is
using TCP port 1234. This client has established a connection with
server S at public IP address 18.181.0.31 and port 1235. NAT A has
assigned TCP port 62000, at its own public IP address 155.99.25.11,
to serve as the temporary public endpoint address for A's session
with S: therefore, server S believes that client A is at IP address
155.99.25.11 using port 62000. Client B, however, has its own
permanent IP address, 138.76.29.7, and the peer-to-peer application
on B is accepting TCP connections at port 1234.
Now suppose client B would like to initiate a peer-to-peer
communication session with client A. B might first attempt to
contact client A either at the address client A believes itself to
have, namely 10.0.0.1:1234, or at the address of A as observed by
server S, namely 155.99.25.11:62000. In either case, however, the
connection will fail. In the first case, traffic directed to IP
address 10.0.0.1 will simply be dropped by the network because
10.0.0.1 is not a publicly routable IP address. In the second case,
the TCP SYN request from B will arrive at NAT A directed to port
62000, but NAT A will reject the connection request because only
outgoing connections are allowed.
After attempting and failing to establish a direct connection to A,
client B can use server S to relay a request to client A to initiate
a "reversed" connection to client B. Client A, upon receiving this
relayed request through S, opens a TCP connection to client B at B's
public IP address and port number. NAT A allows the connection to
proceed because it is originating inside the firewall, and client B
can receive the connection because it is not behind a middlebox.
Ford, Srisuresh & Kegel [Page 9]
Internet-Draft P2P communication across middleboxes September 2003
A variety of current peer-to-peer systems implement this technique.
Its main limitation, of course, is that it only works as long as only
one of the communicating peers is behind a NAT: in the increasingly
common case where both peers are behind NATs, the method fails.
Because connection reversal is not a general solution to the problem,
it is NOT recommended as a primary strategy. Applications may choose
to attempt connection reversal, but should be able to fall back
automatically on another mechanism such as relaying if neither a
"forward" nor a "reverse" connection can be established.
3.3. UDP Hole Punching
The third technique, and the one of primary interest in this
document, is widely known as "UDP Hole Punching." UDP hole punching
relies on the properties of common firewalls and cone NATs to allow
appropriately designed peer-to-peer applications to "punch holes"
through the middlebox and establish direct connectivity with each
other, even when both communicating hosts may lie behind middleboxes.
This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-
PROT], and has been informally described elsewhere on the Internet
[KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name
implies, unfortunately, this technique works reliably only with UDP.
We will consider two specific scenarios, and how applications can be
designed to handle both of them gracefully. In the first situation,
representing the common case, two clients desiring direct peer-to-
peer communication reside behind two different NATs. In the second,
the two clients actually reside behind the same NAT, but do not
necessarily know that they do.
3.3.1. Clients Behind Different NATs
Suppose clients A and B both have private IP addresses and lie behind
different network address translators. The peer-to-peer application
running on clients A and B and on server S each use UDP port 1234. A
and B have each initiated UDP communication sessions with server S,
causing NAT A to assign its own public UDP port 62000 for A's session
with S, and causing NAT B to assign its port 31000 to B's session
with S, respectively.
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
Ford, Srisuresh & Kegel [Page 10]
Internet-Draft P2P communication across middleboxes September 2003
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Now suppose that client A wants to establish a UDP communication
session directly with client B. If A simply starts sending UDP
messages to B's public address, 138.76.29.7:31000, then NAT B will
typically discard these incoming messages (unless it is a full cone
NAT), because the source address and port number does not match those
of S, with which the original outgoing session was established.
Similarly, if B simply starts sending UDP messages to A's public
address, then NAT A will typically discard these messages.
Suppose A starts sending UDP messages to B's public address, however,
and simultaneously relays a request through server S to B, asking B
to start sending UDP messages to A's public address. A's outgoing
messages directed to B's public address (138.76.29.7:31000) cause NAT
A to open up a new communication session between A's private address
and B's public address. At the same time, B's messages to A's public
address (155.99.25.11:62000) cause NAT B to open up a new
communication session between B's private address and A's public
address. Once the new UDP sessions have been opened up in each
direction, client A and B can communicate with each other directly
without further burden on the "introduction" server S.
The UDP hole punching technique has several useful properties. Once
a direct peer-to-peer UDP connection has been established between two
clients behind middleboxes, either party on that connection can in
turn take over the role of "introducer" and help the other party
establish peer-to-peer connections with additional peers, minimizing
the load on the initial introduction server S. The application does
not need to attempt to detect explicitly what kind of middlebox it is
behind, if any [STUN], since the procedure above will establish peer-
to-peer communication channels equally well if either or both clients
do not happen to be behind a middlebox. The hole punching technique
even works automatically under "Twice NAT", where one or both clients
are removed from the public Internet via two or more levels of
address translation.
3.3.2. Clients Behind the Same NAT
Now consider the scenario 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. Client A has
established a UDP session with server S, to which the common NAT has
assigned public port number 62000. Client B has similarly
Ford, Srisuresh & Kegel [Page 11]
Internet-Draft P2P communication across middleboxes September 2003
established a session with S, to which the NAT has assigned public
port number 62001.
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
Suppose that A and B use the UDP hole punching technique as outlined
above to establish a communication channel using server S as an
introducer. Then A and B will learn each other's public IP addresses
and port numbers as observed by server S, and start sending each
other messages at those public addresses. The two clients will be
able to communicate with each other this way as long as the NAT
allows hosts on the internal network to open translated UDP sessions
with other internal hosts and not just with external hosts. We refer
to this situation as "loopback translation," because packets arriving
at the NAT from the private network are translated and then "looped
back" to the private network rather than being passed through to the
public network. For example, when A sends a UDP packet to B's public
address, the packet initially has a source IP address and port number
of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT
receives this packet, translates it to have a source of
155.99.25.11:62000 (A's public address) and a destination of
10.1.1.3:1234, and then forwards it on to B. Even if loopback
translation is supported by the NAT, this translation and forwarding
step is obviously unnecessary in this situation, and is likely to add
latency to the dialog between A and B as well as burdening the NAT.
The solution to this problem is straightforward, however. When A and
B initially exchange address information through server S, they
should include their own IP addresses and port numbers as "observed"
by themselves, as well as their addresses as observed by S. The
clients then simultaneously start sending packets to each other at
each of the alternative addresses they know about, and use the first
address that leads to successful communication. If the two clients
are behind the same NAT, then the packets directed to their private
addresses are likely to arrive first, resulting in a direct
communication channel not involving the NAT. If the two clients are
behind different NATs, then the packets directed to their private
Ford, Srisuresh & Kegel [Page 12]
Internet-Draft P2P communication across middleboxes September 2003
addresses will fail to reach each other at all, but the clients will
hopefully establish connectivity using their respective public
addresses. It is important that these packets be authenticated in
some way, however, since in the case of different NATs it is entirely
possible for A's messages directed at B's private address to reach
some other, unrelated node on A's private network, or vice versa.
3.3.3. Twice NAT and Loopback Translation
In some topologies involving multiple levels of NAT, it is not
possible for two clients to establish an "optimal" P2P route between
them without specific knowledge of the topology. Consider for
example the following situation.
Server S
18.181.0.31:1234
|
|
NAT X
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
|
+----------------------+----------------------+
| |
NAT A NAT B
192.168.1.1:30000 192.168.1.2:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Suppose NAT X is a large industrial NAT deployed by an internet
service provider (ISP) to multiplex many customers onto a few public
IP addresses, and NATs A and B are small consumer NAT gateways
deployed independently by two of the ISP's customers to multiplex
their private home networks onto their respective ISP-provided IP
addresses. Only server S and NAT X have globally routable IP
addresses; the "public" IP addresses used by NAT A and NAT B are
actually private to the ISP's addressing realm, while client A's and
B's addresses in turn are private to the addressing realms of NAT A
and B, respectively. Each client initiates an outgoing connection to
server S as before, causing NATs A and B each to create a single
public/private translation, and causing NAT X to establish a
public/private translation for each session.
Now suppose clients A and B attempt to establish a direct peer-to-
Ford, Srisuresh & Kegel [Page 13]
Internet-Draft P2P communication across middleboxes September 2003
peer UDP connection. The optimal method would be for client A to
send messages to client B's public address at NAT B,
192.168.1.2:31000 in the ISP's addressing realm, and for client B to
send messages to A's public address at NAT B, namely
192.168.1.1:30000. Unfortunately, A and B have no way to learn these
addresses, because server S only sees the "global" public addresses
of the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if A
and B had some way to learn these addresses, there is still no
guarantee that they would be usable because the address assignments
in the ISP's private addressing realm might conflict with unrelated
address assignments in the clients' private realms. The clients
therefore have no choice but to use their global public addresses as
seen by S for their P2P communication, and rely on NAT X to provide
loopback translation.
3.3.4. Consistent Port bindings
The hole punching technique has one main caveat: it works only if
both NATs are cone NATs (or non-NAT firewalls), which maintain a
consistent port binding between a given (private IP, private UDP)
pair and a (public IP, public UDP) pair for as long as that UDP port
is in use. Assigning a new public port for each new session, as a
symmetric NAT does, makes it impossible for a UDP application to
reuse an already-established translation for communication with
different external destinations. Since cone NATs are the most
widespread, the UDP hole punching technique is fairly broadly
applicable; nevertheless a substantial fraction of deployed NATs are
symmetric and do not support the technique.
Since UDP hole punching is the most efficient existing method of
establishing direct peer-to-peer communication between two nodes that
are both behind NATs, and it works with a wide variety of existing
NATs, it is recommended that applications use this technique if
efficient peer-to-peer communication is required, but be prepared to
fall back on simple relaying when direct communication cannot be
established. XXX move this to application guidelines?
3.4. UDP Port Number Prediction
A variant of the UDP hole punching technique discussed above exists
that allows peer-to-peer UDP sessions to be created in the presence
of some symmetric NATs. This method is sometimes called the "N+1"
technique [BIDIR] and is explored in detail by Takeda [SYM-STUN].
The method works by analyzing the behavior of the NAT and attempting
to predict the public port numbers it will assign to future sessions.
Consider again the situation in which two clients, A and B, each
behind a separate NAT, have each established UDP connections with a
permanently addressable server S:
Ford, Srisuresh & Kegel [Page 14]
Internet-Draft P2P communication across middleboxes September 2003
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
Symmetric NAT A Symmetric NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
NAT A has assigned its own UDP port 62000 to the communication
session between A and S, and NAT B has assigned its port 31000 to the
session between B and S. By communicating through server S, A and B
learn each other's public IP addresses and port numbers as observed
by S. Client A now starts sending UDP messages to port 31001 at
address 138.76.29.7 (note the port number increment), and client B
simultaneously starts sending messages to port 62001 at address
155.99.25.11. If NATs A and B assign port numbers to new sessions
sequentially, and if not much time has passed since the A-S and B-S
sessions were initiated, then a working bi-directional communication
channel between A and B should result. A's messages to B cause NAT A
to open up a new session, to which NAT A will (hopefully) assign
public port number 62001, because 62001 is next in sequence after the
port number 62000 it previously assigned to the session between A and
S. Similarly, B's messages to A will cause NAT B to open a new
session, to which it will (hopefully) assign port number 31001. If
both clients have correctly guessed the port numbers each NAT assigns
to the new sessions, then a bi-directional UDP communication channel
will have been established as shown below.
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
A-B 155.99.25.11:62001 B-A 138.76.29.7:31001
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Ford, Srisuresh & Kegel [Page 15]
Internet-Draft P2P communication across middleboxes September 2003
Obviously there are many things that can cause this trick to fail.
If the predicted port number at either NAT already happens to be in
use by an unrelated session, then the NAT will skip over that port
number and the connection attempt will fail. If either NAT sometimes
or always chooses port numbers non-sequentially, then the trick will
fail. If a different client behind NAT A (or B respectively) opens
up a new outgoing UDP connection to any external destination after A
(B) establishes its connection with S but before sending its first
message to B (A), then the unrelated client will inadvertently
"steal" the desired port number. This trick is therefore much less
likely to work when either NAT involved is under load.
Since in practice a P2P application implementing this trick would
still need to work if the NATs are cone NATs, or if one is a cone NAT
and the other is a symmetric NAT, the application would need to
detect beforehand what kind of NAT is involved on either end [STUN]
and modify its behavior accordingly, increasing the complexity of the
algorithm and the general brittleness of the network. Finally, port
number prediction has no chance of working if either client is behind
two or more levels of NAT and the NAT(s) closest to the client are
symmetric. For all of these reasons, it is NOT recommended that new
applications implement this trick; it is mentioned here for
historical and informational purposes.
3.5. Simultaneous TCP Open
There is a method that can be used in some cases to establish direct
peer-to-peer TCP connections between a pair of nodes that are both
behind existing middleboxes. Most TCP sessions start with one
endpoint sending a SYN packet, to which the other party responds with
a SYN-ACK packet. It is possible and legal, however, for two
endpoints to start a TCP session by simultaneously sending each other
SYN packets, to which each party subsequently responds with a
separate ACK. This procedure is known as a "simultaneous open."
If a middlebox receives a TCP SYN packet from outside the private
network attempting to initiate an incoming TCP connection, the
middlebox will normally reject the connection attempt by either
dropping the SYN packet or sending back a TCP RST (connection reset)
packet. If, however, the SYN packet arrives with source and
destination addresses and port numbers that correspond to a TCP
session that the middlebox believes is already active, then the
middlebox will allow the packet to pass through. In particular, if
the middlebox has just recently seen and transmitted an outgoing SYN
packet with the same addresses and port numbers, then it will
consider the session active and allow the incoming SYN through. If
clients A and B can each correctly predict the public port number
that its respective middlebox will assign the next outgoing TCP
Ford, Srisuresh & Kegel [Page 16]
Internet-Draft P2P communication across middleboxes September 2003
connection, and if each client initiates an outgoing TCP connection
with the other client timed so that each client's outgoing SYN passes
through its local middlebox before either SYN reaches the opposite
middlebox, then a working peer-to-peer TCP connection will result.
Unfortunately, this trick may be even more fragile and timing-
sensitive than the UDP port number prediction trick described above.
First, unless both middleboxes are simple firewalls or implement cone
NAT behavior on their TCP traffic, all the same things can go wrong
with each side's attempt to predict the public port numbers that the
respective NATs will assign to the new sessions. In addition, if
either client's SYN arrives at the opposite middlebox too quickly,
then the remote middlebox may reject the SYN with a RST packet,
causing the local middlebox in turn to close the new session and make
future SYN retransmission attempts using the same port numbers
futile. Finally, even though support for simultaneous open is
technically a mandatory part of the TCP specification [TCP], it is
not implemented correctly in some common operating systems. For this
reason, this trick is likewise mentioned here only for historical
reasons; it is NOT recommended for use by applications. Applications
that require efficient, direct peer-to-peer communication over
existing NATs should use UDP.
4. The Middlebox IP Option
Most middleboxes, particularly consumer-level units deployed
by home users, are not intended to constrain applications running on
the private network, but to provide IP address sharing and protect
against outside attackers. The fact that NAT/firewalls do constrain
or break internal applications is a side-effect of their inability to
distinguish between legitimate traffic initiated internally and
unsolicited traffic initiated externally, particularly when
applications exhibit peer-to-peer communication patterns. This
problem in turn stems from the fact that the network and transport
layers provide no application-independent information about the
communication behavior of higher-level protocols and applications
that the NAT/firewall might use to make this distinction reliably.
This section defines a new middlebox IP option, which applications
can use to indicate their communication behavior to any middleboxes
that exist in their communication path.
The middlebox IP option we define is useful not only with the
P2P-applications discussed here, but also to other types of
applications. The use of this option by applications, and its
correct interpretation by middleboxes, should allow the latter
to perform their functions reliably and transparently across a
wider variety of applications. This option does not require
applications, NATs, or firewalls to implement any new protocols.
Ford, Srisuresh & Kegel [Page 17]
Internet-Draft P2P communication across middleboxes September 2003
The option works even when there are multiple middleboxes in a
communication path. Lastly, the middlebox IP option enables
reliable peer-to-peer communication for TCP as well as UDP
based applications.
4.1. Option Format
The middlebox IP option is defined for both IPv4 and IPv6
packets. While the option's primary initial target is IPv4-IPv4 NATs
and firewalls, its use could also help make NAT-based IPv6 transition
mechanisms operate more transparently [NAT-PT]. Even in future pure-
IPv6 environments in which NAT is not required, firewalls will still
be commonly deployed for their security benefits, and this option can
help non-NAT firewalls as well as NATs. When included in IPv6
packets, the Communication Mode option must be contained in the
Destination Options Header.
The option has no alignment requirements, and has the following
format:
Communication Mode Option, IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+-+
|0 0 0 -TBD- | Length |Mod|Res| Check | MaxIdleTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+-+
Type=TBD
Communication Mode Option, IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+-+
|0 0 0 -TBD- | Data-Length |Mod|Res| Check | MaxIdleTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+-+
Type=TBD
The Length field in the IPv4 option must be at least 3, and the Data-
Length field in the IPv6 option must be at least 2. The first octet
of the data portion of the option, following the type and length
fields, contains the following bit fields:
Mod (bits 7-6): P2P mode
This bit field indicates the requirements of the sending
transport-level endpoint, as defined below.
Res (bits 5-4): Reserved
These bits are reserved for future extensions to this option, and
should be set to zero by the sending application and ignored by
receivers.
Check (bits 3-0): Check
Bits 3-0 of the first data octet must be set by the sender to the
Ford, Srisuresh & Kegel [Page 18]
Internet-Draft P2P communication across middleboxes September 2003
bit-wise complement of bits 7-4. Receivers must ignore the entire
Communication Mode option, behaving as if it was not present at
all, if the Check field is incorrect.
MaxIdleTime
This is used to specify the MaxIdleTime (in increments of 30
seconds) for the enforcement of the specified mode on a port
binding. A value of 0 will require the middlebox to use a default
MaxIdletime of 300 seconds (5 minutes) for the device.
4.2. Communication modes
The Mode field defined above pertains specifically to the transport
endpoint from which this packet originated, identified by the
packet's (source IP address, source TCP/UDP port number) tuple. The
field therefore cannot be interpreted meaningfully in IP fragments
that do not contain a transport-level header. This is not a
problem in practice, since NATs and firewalls often reassemble
fragmented IP datagrams in order to perform their functions
correctly. Because of this transport-level dependency, it
is appropriate to think of the Communication Mode option as a
transport-layer rather than a network-layer facility; it must be
defined as an IP option merely because UDP contains no support for
transport-layer extensions.
The Mode field takes on one of the following values, indicating the
communication pattern in which the sender operates:
00: One-to-One Session, Outgoing Only
This mode indicates that the packet is part of a one-to-one
session, and that this session is independent of any other
sessions that may share the same endpoint tuple (source IP,
source port). The application does not expect to receive any
incoming connections related to this endpoint tuple.
Transmission of an outgoing packet in this mode does not cause
a P2P-NAT or P2P-firewall to open its filters to any incoming
traffic other than traffic that is specifically part of the
outgoing session. In other words, a P2P-NAT should behave as
either a symmetric NAT or a port-restricted cone NAT with
respect to this session, and any "filtering hole" a
P2P-firewall creates should only allow incoming traffic from
the same external endpoint that the original triggering packet
was directed to.
01: One-to-Many Communication, Outgoing Only
Ford, Srisuresh & Kegel [Page 19]
Internet-Draft P2P communication across middleboxes September 2003
This mode indicates that the sending application expects to use
its source endpoint (source IP, source port) for multiple
outgoing sessions, and it is important that its source endpoint
be mapped consistently across all of these sessions. The
application does not expect and does not need to receive any
incoming connections, however. A P2P-NAT should behave as a
port-restricted cone NAT for sessions in this mode, and a
P2P-firewall should behave in the same way as for mode 00.
10: One-to-Many Communication, Reverse Connections Allowed
This mode indicates that the sender's source endpoint may be used
not only to establish multiple outgoing sessions, but also
subsequently to receive new incoming connections from any of the
remote IP addresses to which these outgoing sessions were
directed. This mode is appropriate for applications that behave
like FTP, in which an initial "control" connection is used to
negotiate and establish one or more subsequent "data" connections
in the reverse direction between the same pair of hosts. A P2P-
NAT should behave as a restricted cone NAT for sessions in this
mode, and a P2P-firewall should widen its incoming traffic "hole"
only enough to allow incoming TCP or UDP connections.
11: One-to-Many Communication, Arbitrary Incoming Connections Allowed
This mode indicates that the sender's source endpoint may be used
for arbitrary peer-to-peer communication involving incoming and
outgoing sessions with any remote endpoint. Once an initial
outgoing session has been established in this mode from a given
(source IP, source port) pair, a P2P-NAT should behave as a full
cone NAT for all other traffic in this mode sharing the same
internal endpoint, and a P2P-firewall should similarly filter
subsequent incoming traffic based only on its destination IP
address and destination port.
Note, this mode permits incoming and outgoing sessions to any
peer destination from/to the same endpoint of the originating
host's (IP address, port) endpoint.
Applications that use the middlebox IP option MAY include the
option in all packets transmitted as part of any given session
and all related incoming and outgoing sessions. At a minimum, the
middlebox IP option MUST be used until traffic is exchanged in
both directions for the source endpoint (This will cover the
cases where one or more of the first few packets may be dropped
along the network). Further, applications MUST use the same
value for the Mode field in all of these related packets. In
Ford, Srisuresh & Kegel [Page 20]
Internet-Draft P2P communication across middleboxes September 2003
practice. this means that an application should set the option
in every transport-layer socket it creates before starting to
use that socket for communication.
In case of a P2P-NAT, given that the source endpoint is going
to be an element of port binding, the mode will essentially
become an attribute of the port binding.
A NAT or firewall must have a way to determine when a communication
session is no longer in use so that it can free its address
translation or filtering resources for other purposes. For TCP
connections, the usual method is to track the TCP state machine for
each session, freeing the NAT/firewall state after the TCP connection
has been observed to be closed or reset. For connectionless UDP
traffic, however, the method often used is to employ an activity
timer. For one-to-one traffic in mode 00, a P2P-NAT or P2P-firewall
should treat every UDP session independently for purposes of
determining its lifetime. In other words, if a client
establishes two outgoing mode 00 sessions originating from a single
internal UDP endpoint, an intermediary should maintain a separate
activity timer for each session, and close each session independently
when its timeout expires. For the other three modes, however, a P2P-
NAT or P2P-firewall should associate the port-binding activity timer
with transport endpoints rather than with individual sessions. For
example, after an application opens an outgoing session in mode 11
from a given (private IP, private port) to establish peer-to-peer
sessions, allowing incoming connections, any subsequent mode 11
traffic between that private endpoint and any external entity should
cause intermediaries to reset their timers for that private endpoint.
This behavior allows peer-to-peer applications that communicate
sporadically with many remote nodes to maintain connectivity without
requiring an excessive amount of keepalive traffic. In any case, all
port-binding activity timeouts MUST be at least thirty seconds.
5. Application Design Guidelines
5.1. Applications behind the same NAT
In practice there may be a fairly large number of users who
have not two IP addresses, but three or more. In these cases,
it is hard or impossible to tell which addresses to send to
the registration server. The applications should send all its
addresses, in such a case.
5.2. Peer discovery
Applications sending packets to several addresses to discover
which one is best to use for a given peer may become a
Ford, Srisuresh & Kegel [Page 21]
Internet-Draft P2P communication across middleboxes September 2003
significant source of 'space junk' littering the net, as the
peer may have chosen to use routable addresses improperly as
an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD).
Thus applications should exercise caution when sending the
speculative hello packets.
6. NAT Design Guidelines
This section discusses considerations in the design of network
address translators, as they affect peer-to-peer applications.
A P2P-NAT may support mode 00 for certain applications and other
modes for certain other applications. One way for a P2P-NAT to
support multiple modes of operations would be to divide its
assignable port namespace statically, reserving a portion of
its ports for one-to-one sessions and a different set of ports
for one-to-many sessions.
Alternately, a P2P-NAT may also be explicitly configured with
applications that need the P2P feature in one of the 4 modes.
This would alleviate the need for application to communicate
using the IP middlebox option. The P2P-NAT might set aside
blocks of ports for the pre-configured applications, so it can
automagically pick the required P2P ports from the right port
block.
6.1. Maintaining Consistent port bindings for UDP Ports
The primary and most important recommendation of this document for
NAT designers is that the NAT maintain a consistent and stable
port binding between a given (internal IP address, internal UDP port)
pair and a corresponding (public IP address, public UDP port) pair
for as long as any active sessions exist using that port binding.
The NAT may filter incoming traffic on a per-session basis, by
examining both the source and destination IP addresses and port
numbers in each packet. When a node on the private network initiates
connection to a new external destination, using the same source IP
address and UDP port as an existing translated UDP session, the
NAT should ensure that the new UDP session is given the same public
IP address and UDP port numbers as the existing session.
6.1.1. Preserving Port Numbers
Some NATs, when establishing a new UDP session, attempt to assign the
same public port number as the corresponding private port number, if
that port number happens to be available. For example, if client A
at address 10.0.0.1 initiates an outgoing UDP session with a datagram
from port number 1234, and the NAT's public port number 1234 happens
Ford, Srisuresh & Kegel [Page 22]
Internet-Draft P2P communication across middleboxes September 2003
to be available, then the NAT uses port number 1234 at the NAT's
public IP address as the translated endpoint address for the session.
This behavior might be beneficial to some legacy UDP applications
that expect to communicate only using specific UDP port numbers, but
it is not recommended that applications depend on this behavior since
it is only possible for a NAT to preserve the port number if at most
one node on the internal network is using that port number.
In addition, a NAT should NOT try to preserve the port number in a
new session if doing so would conflict with the goal of maintaining a
consistent binding between public and private endpoint addresses.
For example, suppose client A at internal port 1234 has established a
session with external server S, and NAT A has assigned public port
62000 to this session because port number 1234 on the NAT was not
available at the time. Now suppose port number 1234 on the NAT
subsequently becomes available, and while the session between A and S
is still active, client A initiates a new session from its same
internal port (1234) to a different external node B. In this case,
because a port binding has already been established between client
A's port 1234 and the NAT's public port 62000, this binding should be
maintained and the new session should also use port 62000 as the
public port corresponding to client A's port 1234. The NAT should
NOT assign public port 1234 to this new session just because port
1234 has become available: that behavior would not be likely to
benefit the application in any way since the application has already
been operating with a translated port number, and it would break any
attempts the application might make to establish peer-to-peer
connections using the UDP hole punching technique.
6.2. Maintaining Consistent port bindings for TCP Ports
For consistency with the behavior of UDP translation, it is suggested
that NATs also maintain a consistent binding between private and
public (IP address, TCP port number) pairs for TCP connections, in
the same way as described above for UDP. Maintaining TCP endpoint
mappings consistently may also increase the NAT's compatibility with
other applications that initiate multiple TCP connections from the
same source port. More importantly, maintaining consistent port
bindings for TCP will enable middleboxes to support TCP P2P
applications in conjunction with P2P middlebox IP option.
6.3. Proxy Protocols
Besides adopting the above recommendations to make a NAT's basic
"transparent-mode" operation as peer-to-peer friendly as possible, it
is helpful for NATs also to support proxy protocols that allow
applications to request an explicitly managed presence on the public
Ford, Srisuresh & Kegel [Page 23]
Internet-Draft P2P communication across middleboxes September 2003
side of the NAT. Unfortunately, several alternative protocols have
been proposed with varying characteristics [SOCKS, RSIP, MIDCOM,
UPNP], and as of this writing none of them have achieved clear
acceptance or dominance in the Internet community. Furthermore, it
is not clear yet how well these protocols will work in the
increasingly common "Twice NAT" situation where clients are located
behind multiple levels of NAT, especially if the NATs are from
different vendors, support different features and policies, and are
under different administrative domains. (In the common case, one is
owned and managed by the ISP and the other by the end user.) For
these reasons, this document makes no attempt to explore this issue
in detail or to recommend specific proxy protocols for NATs to
implement.
6.4. Large timeout for P2P applications
We recommend the middlebox implementers to use a minimum timeout
of, say, 5 minutes (300 seconds) for P2P applications, i.e.,
applications that use the IP middlebox option. Middlebox
implementers are often tempted to ignore the timeout field
specified in the option, and use a shorter one, as they are
accustomed to doing currently. But, short timeouts are
problematic. Consider a P2P application that involved 16 peers.
They will flood the network with keepalive packets every 10
seconds to avoid NAT timeouts. This is so because one might
send them 5 times as often as the middlebox's timeout just in
case the keepalives are dropped in the network.
7. Security Considerations
XXX attacks based on forging source addresses
Using the UDP hole punching technique in peer-to-peer applications
and supporting it in NATs should not create any new security issues.
In particular, the technique does not require a firewall to be
"promiscuous" in any way about accepting incoming UDP traffic. As
long as outgoing UDP sessions are enabled and the firewall maintains
consistent mappings between internal and external UDP ports, the
firewall can still filter out all incoming UDP packets except those
with (source IP, source port, destination IP, destination port)
tuples that exactly match those of active sessions initiated from
within the enclave. Filtering incoming traffic aggressively while
maintaining consistent mappings thus allows a firewall to be "peer-
to-peer friendly" without compromising the standard firewall security
principle of rejecting all unsolicited incoming traffic.
XXX security issues of relaying or NAT discovery protocols
Ford, Srisuresh & Kegel [Page 24]
Internet-Draft P2P communication across middleboxes September 2003
It can be argued that maintaining a consistent internal/external port
binding increases the predictability of traffic crossing the
firewall, by revealing the relationships between different UDP
sessions and hence about the behavior of applications running within
the enclave. This predictability could conceivably be useful to an
attacker in exploiting network- or application-level vulnerabilities.
If the security requirements are so critical that such subtle
information channels are of concern, however, then the firewall
almost certainly should not be configured to allow unrestricted
outgoing UDP traffic in the first place. Such a firewall should only
allow communication originating from specific applications at
specific ports, or via tightly-controlled application-level gateways.
In this situation there is no hope of generic, transparent peer-to-
peer connectivity across the firewall (or transparent client/server
connectivity for that matter); the firewall must either implement
appropriate application-specific behavior or disallow communication
entirely.
XXX related to Middlebox IP option: forgery
Acknowledgments
XXX Dan, Henrik, Dave, ...
References
Normative references
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee,
"Bidirectional Peer-to-Peer Communication with Interposing
Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/
[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.
Ford, Srisuresh & Kegel [Page 25]
Internet-Draft P2P communication across middleboxes September 2003
[NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
Informational references
[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.
[RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN",
draft-takeda-symmetric-nat-traversal-00.txt (Work In
Progress), June 2003.
[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.
[TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema,
"Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (Work In Progress),
March 2003.
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Ford, Srisuresh & Kegel [Page 26]
Internet-Draft P2P communication across middleboxes September 2003
Device Control Protocol V 1.0", November 2001.
http://www.upnp.org/standardizeddcps/igd.asp
Author's Address
Bryan Ford
Laboratory for Computer Science
Massachusetts Institute of Technology
77 Massachusetts Ave.
Cambridge, MA 02139
Phone: (617) 253-5261
E-mail: baford@mit.edu
Web: http://www.brynosaurus.com/
Pyda Srisuresh
Caymas Systems, Inc.
11799-A North McDowell Blvd.
Petaluma, CA 94954
Phone: (707) 283-5063
E-mail: srisuresh@yahoo.com
Dan Kegel
Kegel.com
901 S. Sycamore Ave.
Los Angeles, CA 90036
Phone: 323 931-6717
Email: dank@kegel.com
Web: http://www.kegel.com/
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Ford, Srisuresh & Kegel [Page 27]
Internet-Draft P2P communication across middleboxes September 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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, Srisuresh & Kegel [Page 28]