P2PSIP WG E. Cooper
Internet Draft P. Matthews
Intended status: Informational Avaya
Expires: September 2007 March 4, 2007
The Effect of NATs on P2PSIP Overlay Architecture
draft-matthews-p2psip-nats-and-overlays-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This paper explains the problems created by Network Address
Translators (NATs) in Peer-to-Peer (P2P) overlays and recommends some
NAT traversal techniques appropriate for P2PSIP networks. Two P2PSIP
overlay architectures that accommodate the presence of NATs are
described and analyzed. The first is the super-peer scheme used in a
Cooper & Matthews Expires September 4, 2007 [Page 1]
Internet-Draft NATs and Overlays March 2007
number of p2p file-sharing systems today. The second is a scheme
where all peers play an equal role in the overlay.
Table of Contents
1. Introduction...................................................2
2. IP Network Structure...........................................3
2.1. NAT-Induced Problems in Overlay Networks..................4
2.2. NAT Traversal Techniques for P2PSIP Overlays..............5
3. Super-Peer Overlay Networks....................................6
3.1. NAT-Induced Problems in P2PSIP Super-Peer Overlays........6
4. Fully-Distributed Overlay Networks.............................7
4.1.1. Aligning the Search and Routing Structures...........8
4.1.2. NAT-Induced Problems in Fully-Distributed Overlays..11
5. Comparing Super-Peer and Fully-Distributed Overlay Networks...11
6. Other Hierarchical Overlay Network Topologies.................11
6.1. Modified Super-Peer Overlays.............................11
6.2. Representative Overlays..................................12
7. Conclusions...................................................13
8. Security Considerations.......................................14
9. IANA Considerations...........................................14
10. Acknowledgments..............................................14
APPENDIX A: Other NAT Traversal Techniques.......................15
11. References...................................................16
11.1. Normative References....................................16
11.2. Informative References..................................16
Author's Addresses...............................................18
Full Copyright Statement.........................................18
Intellectual Property............................................19
Acknowledgment...................................................19
1. Introduction
P2P overlay networks have emerged as a popular, scalable and
efficient mechanism for sharing music and video files amongst
millions of computers. Early P2P file-sharing systems used a
combination of highly distributed content storage and a centralized
index of the available content to provide easy access to vast amounts
of data. Napster was one such system. Due to the legal implications
of its unauthorized content distribution, Napster was ordered to
cease operations. As soon as the centralized content index was
disabled, the Napster network was effectively shut down.
Of course, Napster's demise did nothing to squelch the demand for
easy access to vast amounts of content. New P2P file-sharing systems
emerged to replace Napster and all of them were designed without a
centralized content index. Various schemes were used to locate
Cooper & Matthews Expires September 4, 2007 [Page 2]
Internet-Draft NATs and Overlays March 2007
content in these new networks. Some transmitted content queries
randomly amongst nodes, while others would flood the queries
throughout the network. Neither of these techniques was particularly
effective or efficient at locating content. Then P2P overlays adopted
a distributed hash table (DHT) approach for indexing their content.
As their name suggests, DHTs distribute the content index across many
nodes. DHTs do provide an effective and relatively efficient indexing
mechanism. The drawback is that as a result of this distribution, a
query into a DHT must be processed by a number of nodes before the
result can be determined.
As a result of their evolution, current P2P file-sharing overlays use
both distributed content storage and distributed context indexing. By
eliminating all centralization in the system, these P2P overlays have
gained a number of interesting benefits. They are self-organizing,
highly scalable, highly reliable and require very little
administration.
From a structural perspective, today's SIP networks have a lot in
common with the Napster file-sharing network. The 'content' in a SIP
system is the real-time data that flows directly between the nodes.
Although it doesn't need to be stored anywhere, the source addresses
of the 'content' must be collected into an index that can be easily
accessed. This index is analogous to the contact binding information
that is stored by Registrars. Of course, SIP networks do not face the
same legal difficulties as P2P file-sharing systems. They do,
however, have scalability, reliability and administrative concerns.
The P2PSIP working group is investigating how P2P techniques might be
used in conjunction with (or as an alternative to) the DNS-based
lookup and routing mechanisms of [RFC3261] and [RFC3263]. This paper
explores the problems introduced by the presence of NATs in the
network topology and discusses their effects on the P2PSIP overlay
architecture.
Comments on this draft are solicited and should be addressed either
to the authors or to the P2P-SIP mailing list at p2psip@ietf.org (see
https://www1.ietf.org/mailman/listinfo/p2psip).
2. IP Network Structure
Overlay networks create a set of virtual links on top of the routes
of the underlying IP network. These virtual links are usually
structured to optimize the overlay for a particular purpose, such as
content indexing.
Cooper & Matthews Expires September 4, 2007 [Page 3]
Internet-Draft NATs and Overlays March 2007
,-------.
,' P P `. Subnet 1 ,-----. Subnet 2
( P ) ( P )
`. P P ,' `-----'
`-------' NAT
NAT
_.------------.
,--'' `---.
,-' `-.
/ \
/ \
( Internet )
\ /
\ /
`-. ,-'
`---. _.--'
N A T `------------''
,-. ,-. ,-----.
/ P \ ( P ) Subnet 4 ,' P `. Subnet 5
( P ) `-' ( P P )
\ P/ `. P ,'
`-' Subnet 3 `-----'
Legend
P - Peer node
NAT - NAT box
Figure 1 Example IP Network Topology
Figure 1 shows a set of peers (denoted by Ps) that want to create an
overlay on top of an IP network. In this figure we see six clouds.
Five represent IP subnets containing peers and one represents the
Internet. One of the subnets uses public IP addresses, while the
other subnets have NATs between them and the Internet and thus use
private addresses. Two of the subnets are sitting behind the same
NAT. More complex network topologies are not depicted, but it would
not be uncommon for an overlay network to include peers that were
separated from the Internet by two or more NATs.
2.1. NAT-Induced Problems in Overlay Networks
Some P2P overlays assume that all participating nodes are linked by
unimpeded IP connectivity. Unfortunately, the use of NATs is very
common, which means that a great many IP networks span multiple
addressing spaces.
Cooper & Matthews Expires September 4, 2007 [Page 4]
Internet-Draft NATs and Overlays March 2007
Straightforward deployment of P2P overlays on IP networks involving
NATs would cause the overlay's mechanisms to fail because:
. The private IP addresses of some peers would be considered un-
deliverable by the routers in the public Internet. This would
cause messages to be discarded.
. The IP addresses of some peers could conflict if the overlay
included multiple private address spaces. This would cause
messages to be delivered to the wrong peer.
. NATs perform mapping and filtering functions at the borders
between two addressing realms, and will frequently discard
packets they consider "unsolicited". From a NAT's perspective,
a message must be sent from a peer on its "private" side to a
peer on its "public" side before a message can travel in the
opposite direction.
All these mis-directed and dropped messages will cause overlay
services to fail and may prevent the participating peers from
constructing or maintaining overlay correctly.
2.2. NAT Traversal Techniques for P2PSIP Overlays
NAT traversal is a well-known problem for SIP networks and much
effort has been devoted to solving it. [p2p-comm] discusses some
popular mechanisms for P2P systems and recommends a combination of
"NAT hole-punching" and "relay" techniques to establish
communications between peers in NATed networks.
Based upon the arguments for an UNSAF approach presented in [nat-
consider], [ice] defines a mechanism for employing these two
techniques in SIP networks to route media streams between two NATed
endpoints. The use of ICE and other SIP NAT traversal techniques,
such as "symmetric signaling response" and "connection re-use", is
encouraged by [nat-scenarios].
Since NATs create similar (and perhaps more severe) problems for
P2PSIP overlays, all of these mechanisms will need to be adopted for
P2PSIP overlay signaling protocols. Other SIP techniques, such as
[outbound], may also prove useful for P2PSIP systems.
The applicability of some other NAT traversal techniques is discussed
in APPENDIX A:
Cooper & Matthews Expires September 4, 2007 [Page 5]
Internet-Draft NATs and Overlays March 2007
3. Super-Peer Overlay Networks
One way to organize a P2P overlay is to create an overlay topology in
which the publicly addressable peers (dubbed "super-peers") act as
relay points for the NATed peers. This structure essentially creates
a hierarchy in the overlay network. The super-peers (at the top
level) supply the content indexing function and provide message
routing to/from NATed peers. NATed peers are at a lower level. They
may advertise their content and query for content via their
associated super-peer, but do not process any queries or store any of
the content index data.
__,,.O.,------------.....__
,,-'' Super-Peer `'--..
'' Super-Peer`O
`O Super-Peer / NAT
`.._ Super-Peer __.-' \
`'--O....._ Super-Peer.---'' \
NAT `----------O-'' O
/\ NAT NATed Peer
/ \ /\
O O NATed Peers O O
Figure 2 P2P Overlay with Super-Peers
3.1. NAT-Induced Problems in P2PSIP Super-Peer Overlays
The super-peer overlay network organization provides a simple and
efficient model for NAT traversal in P2PSIP networks. Its routing
structure has the advantage that a message sent from one peer to
another traverses at most 3 hops.
The main drawback of this approach is that it requires a sufficient
number of publicly addressable nodes to act as super-peers. In
addition, the super-peers must bear the entire load associated with
message routing.
Several P2PSIP use case scenarios are described in [use-cases].
Referring back to Figure 1, one example of a P2PSIP "Managed Private
Network" scenario could include peers from subnets 1-4, but no peers
with public addresses. In such a network, a super-peer routing
topology is simply not possible.
Other use cases, including the "Public P2P VoIP Service Providers"
and "Open Global P2P VoIP Network" scenarios do include peers from
all five subnets. These overlay networks will have some percentage of
publicly addressable peers. One measurement has found that 74% of
Cooper & Matthews Expires September 4, 2007 [Page 6]
Internet-Draft NATs and Overlays March 2007
web-browsing clients are behind NATs [illuminati]. If a similar
percentage of P2PSIP peers are NATed, a super-peer overlay topology
will be able to utilize only 1/4 of the resources available.
The bandwidth available at the super-peers is of particular concern.
Since every message in the overlay must traverse the IP links to the
super-peers, it's possible that super-peers with low-bandwidth links
will be overwhelmed, while high-bandwidth links to NATed peers will
be almost completely unused.
Further, the use of a super-peer routing structure requires that each
NATed peer must establish a long-lived association to a super-peer.
[behave-udp] and [behave-tcp] require the use of periodic "keep-
alive" traffic to ensure connectivity across the intervening NAT. It
follows that the amount of keep-alive traffic arriving at a given
super-peer will be proportional to the number of NATed peers it
serves. Thus, in super-peer overlays, it is important to assign NATed
peers to super-peers such that only a reasonably small fraction of
the super-peer's bandwidth is consumed by keep-alive traffic. In
other words, the routing structure should be constructed such that
the super-peer's bandwidth is not overwhelmed. A mechanism for
distributing the load across super-peers will need to be created.
Another consequence of the super-peer routing structure is that the
amount of keep-alive traffic crossing a given NAT will be
proportional to the number of peers behind that NAT (regardless of
how those peers are distributed across super-peers).
Due to its connectionless nature, the bandwidth considerations are
considerably more pronounced for UDP than for TCP. However, TCP
connections require more state information to be maintained at the
super-peer. Both protocols require state information to be maintained
at the NAT.
4. Fully Distributed Overlay Networks
As an alternative to the hierarchy created by super-peer overlays, it
is also possible to use the techniques of section 2.2. to create a
completely flat overlay network in which all peers are equal
participants. Such fully-distributed overlays also avoid the problems
created by NATs in the search algorithm (discussed in section 2.1.
and the problems in the super-peer routing topology (discussed in
section 3.1.
This approach does not place special emphasis on nodes with publicly
reachable addresses and can be deployed over any IP network topology.
Cooper & Matthews Expires September 4, 2007 [Page 7]
Internet-Draft NATs and Overlays March 2007
Since all peers participate in the search scheme and in message
routing, all of the available resources can be utilized.
[dSIP-nat] is one example of a fully distributed overlay that uses
SIP-based messaging to implement a DHT search algorithm. Fully
distributed P2PSIP overlay networks could also be built using other
protocols and/or other search algorithms.
4.1.1. Aligning the Search and Routing Structures
Many DHTs route queries amongst peers such that any query can reach
the appropriate (authoritative for that query) peer in O(log N) hops.
As previously mentioned, the problem is that these searching
structures do not account for impediments in IP routing. Creating a
routing structure that mirrors the search algorithm will preserve the
efficiency of the search algorithm as much as possible.
To determine the specifics of the routing structure, we examine the
search algorithm in a bit more detail. Chord is used as an example.
To process queries, peers participating in a chord overlay maintain
tables of other peers that will assist in routing queries to their
destinations. These tables form a good starting point for the
routing topology.
In Chord, some unique peer attribute is hashed using SHA-1 and the
result (called a peer identifier) is used to place peers on a
conceptual ring. Each peer then maintains connections to peers
located at exponentially increasing locations going clockwise around
the ring. For example, a peer P, with ID 0 might have a table
consisting of addresses for peers with IDs 2^0, 2^1, 2^2,..., 2^(n/2)
(where n=# of output bits for SHA-1).
In this routing structure, a message to peer Q can be addressed to
Q's location in the ring, and any intermediate peer R can forward the
message by selecting the peer from its connection table that is that
is closest to Q without overshooting Q.
Many other connection structures exist. For example, structured
routing topologies can be created using the ideas contained in any
one of a number of DHT schemes. The important point is that the
structure of the routing topology matches the message flow required
by the search algorithm.
4.1.1.1. Symmetric Interest
When considering connection topologies, there is a property we have
dubbed "symmetric interest". A connection structure exhibits
Cooper & Matthews Expires September 4, 2007 [Page 8]
Internet-Draft NATs and Overlays March 2007
"symmetric interest" if, when peer P desires a connection to peer Q,
then peer Q also desires a connection to peer P.
A routing structure based on peers randomly selecting other peers to
connect to does NOT exhibit symmetric interest because peer P can
select peer Q without peer Q selecting peer P. Similarly, a Chord-
based connection structure (depicted in Figure 3) also does NOT
exhibit symmetric interest because a given peer P in the ring desires
connections to peers in the clockwise half-circle but not in the
counter-clockwise half-circle.
O
O | O
O | O
|
O | O
|
|
O------ | O
\ |
\ |
O \ | O
\ |
O-------\ | O
\ |
O----\| O
O Peer Q
Peer P
Figure 3 Chord-based Connection Structure 1
Figure 3 depicts a connection topology from the perspective of a
single peer P. As described in section 4.1.1. if P's ID were 0, it
might have a table consisting of addresses for peers with IDs 2^0,
2^1, 2^2,..., 2^(n/2). Peer P would never include Peer Q in its
connection table, since Q's ID is greater 2^(n/2). However, Peer Q's
connection table may include Peer P, since P's ID is contained in the
clockwise half-circle starting at Q's ID. Figure 4 illustrates the
same connection topology from the perspective of Peer Q.
Cooper & Matthews Expires September 4, 2007 [Page 9]
Internet-Draft NATs and Overlays March 2007
O
O O
\
\
O \ O
\
\
O \ O
/---------\
/ \
O \ O
\
O /-----\ O
/ \
O /---O
O Peer Q
Peer P
Figure 4 Chord-based Connection Structure 2
One topology that does exhibit symmetric interest has each peer
maintaining connections to peers located an exponentially increasing
distances going both clockwise AND counter-clockwise around the ring.
O
O | O
O | O
|
O | O
|
|
O------ | ------O
\ | /
\ | /
O \ | / O
\ | /
O-------\ | /--------O
\ | /
O----\|/----O
O Peer Q
Peer P
Figure 5 Symmetric Partial Mesh
"Symmetric interest" seems a desirable property for routing
topologies because connections through NATs, by their nature, are bi-
Cooper & Matthews Expires September 4, 2007 [Page 10]
Internet-Draft NATs and Overlays March 2007
directional and because both peers incur the overhead of sending
keep-alives to maintain the connection.
4.1.2. NAT-Induced Problems in Fully Distributed Overlays
As mentioned in section 3.1. each routing connection that crosses a
NAT must be maintained by P2PSIP peers. This applies to the fully
distributed overlay network too.
There is a possibility that the number of viable connections in a
peer's table might be constrained by the number of 'pinhole' mapping
and filtering entries that can be supported by a peer's local NAT.
Unfortunately, NAT behaviour is notoriously variable, so it is
difficult to predict the achievable size for a peer's connection
table. If the number of entries in this table is reduced below the
DHT's prescribed size, the message routing efficiency may be reduced,
or fail completely. For example, under a Chord-based routing
topology, the connection to the peer's immediate successor is
critically important. Without that link, messages may fail to reach
their destination. The other connections in a Chord-based structure
are used to improve routing efficiency, but some may be removed
without jeopardizing routing correctness.
So in a fully distributed overlay, peers may need to reduce the size
of their connection tables to accommodate limitations in their local
NATs. This can reduce the search algorithm's efficiency.
Interestingly, when large numbers of peers are operating behind the
same NAT, DHT-based search algorithms is likely to create many
connections that do not need to cross the NAT.
5. Comparing Super-Peer and Fully Distributed Overlay Networks
<< [concepts] describes three modes of operation under which P2PSIP
peers can register and make calls. These modes are variations on
how user contact information in stored, retrieved and used by peers
in the overlay network. A future version of this paper will compare
the performance of the super-peer and fully distributed overlays
under each mode. >>
6. Other Hierarchical Overlay Network Topologies
6.1. Modified Super-Peer Overlays
As discussed in section 3.1. super-peer routing topologies can
encounter difficulties when many peers are behind the same NAT. The
resources (bandwidth, state-information) required for NAT traversal
Cooper & Matthews Expires September 4, 2007 [Page 11]
Internet-Draft NATs and Overlays March 2007
could be reduced if a single "Representative" peer were elected to
proxy all the traffic between the NATed peers and the super-peer. An
overlay utilizing both super-peers and representatives is depicted in
Figure 6.
__,,.O.,------------.....__
,,-'' Super-Peer `'--..
'' Super-Peer`O
`O Super-Peer / NAT
`.._ Super-Peer __.-' \
`'--O...._ Super-Peer.---'' \
NAT `-----------O-'' O
| NAT Representative Peer
| |
O Representatives O
/ \ / \
O O NATed Peers O O
Figure 6 Overlay Network with Super-Peers and Representatives
The network shown in Figure 6 minimizes the amount of effort that
needs to be expended for NAT pinhole maintenance, but introduces
another level of hierarchy into the overlay and thus increases
message hop counts. Further, it requires some new mechanism to allow
NATed peers to discover each other and elect a representative.
In this topology, both the super-peer and the representative are
assumed to be servicing large numbers of NATed peers, so their
performance and availability are a concern.
6.2. Representative Overlays
It's worth noting that the super-peer and representative concepts are
independent of each other. It is possible to construct an overlay
network in which representative peers (residing behind NATs) use ICE
NAT traversal techniques to create connections to other peers in the
overlay. No super-peers (publicly addressable peers) need be present
in such a network.
This is a similar type of hierarchy to the super-peer hierarchy in
that representative peers connected in such a way would have overlay
IDs and implement the search algorithm and NATed peers would not.
This type of overlay topology would increase the number of
connections crossing the NAT above the bare minimum required in
Figure 6, but instead of being proportional to the number of super-
peers serving nodes behind a NAT, it would instead be related to the
number of connections the representative had to other peers.
Cooper & Matthews Expires September 4, 2007 [Page 12]
Internet-Draft NATs and Overlays March 2007
As with the super-peer overlay, representatives are assumed to be
serving large numbers of NATed peers, so performance and availability
are concerns.
Introducing hierarchy into an overlay network, either through super-
peers or representatives, is a relatively effective NAT traversal
technique. However, it requires that super-peers and/or
representatives must perform two distinct routing operations: one to
direct search queries to other super-peers and another one to allow
NATed peers to access the overlay.
The inclusion of a hierarchy also requires the creation of new
techniques to distribute the load appropriately and recover from
failures. These mechanisms are generally independent from similar
mechanisms already present in search algorithms like DHTs.
7. Conclusions
The presence of NATs in IP networks present several challenges for
P2PSIP overlays. A super-peer overlay architecture is easy-to-
understand and provides effective NAT traversal. However, it
concentrates the network load on a small percentage of the
participating nodes and cannot be used in networks that have no
publicly addressable peers.
Fully distributed overlays traverse NATs equally well and share the
load evenly across participating peers, which results in greater
performance and scalability. Since they do not require any nodes to
have public IP addresses, these architectures can be applied to more
IP network topologies.
Fully distributed networks implicitly determine (based upon their
search algorithm) how many connections will cross a peer's local NAT.
Depending on the search algorithm, it may be possible to adjust the
number of connections so no single NAT is overwhelmed by the keep-
alive traffic or number of mappings it needs to maintain.
Super-peer overlays have no inherent mechanism for associating NATed
peers with super-peers, so one must be created. In creating this
mechanism special consideration must be given to the resources
available at both the super-peer and in the NAT. Due to their role as
routers for overlay messages, super-peers that serve many NATed peers
must be highly available and have high-bandwidth Internet links.
In fully distributed networks the connections required for message
routing are the same ones used by the search algorithm. Since the
routing topology in a super-peer overlay is separate from the
Cooper & Matthews Expires September 4, 2007 [Page 13]
Internet-Draft NATs and Overlays March 2007
searching mechanism, a super-peer overlay will devote extra resources
to NAT traversal.
8. Security Considerations
Security Considerations will be covered in a later version of this
paper.
9. IANA Considerations
IANA considerations will be covered in a later version of this paper.
10. Acknowledgments
Cooper & Matthews Expires September 4, 2007 [Page 14]
Internet-Draft NATs and Overlays March 2007
APPENDIX A: Other NAT Traversal Techniques
In addition to the techniques discussed in section 2.2. other
addition to those, some other mechanisms for NAT traversal are: UPnP,
ALGs, SBCs, and manual configuration.
Universal Plug-n-Play (UPnP) is a NAT configuration scheme developed
by Microsoft. This HTTP/XML based protocol allows applications to
dynamically create forwarding rules in the NAT as needed. Many
consumer-grade NATs support the UPnP protocol, which makes this seem
quite promising for P2P applications targeted only at the consumer
market. However, most corporate-grade NATs do not support UPnP. Even
in the consumer market space, the user would be required to provide
the administrative password for the NAT. Further, even if
administrative access to the NAT is possible, UPnP cannot provide a
complete solution if there are multiple NATs between the P2PSIP
device and the public Internet.
Many NATs contain one or more Application Level Gateways (ALGs). An
ALG is special code within the NAT that recognizes packets of a
particular application-level protocol and treats the packets
specially. ALG support for the File Transfer Protocol (FTP) is almost
universal in NATs, and ALG support for SIP is becoming more common.
However, ALG support requires that the application protocol not be
encrypted end-to-end, and end-to-end encryption of both SIP and P2P
messages is likely to be desirable for security reasons.
Session Border Controllers (SBCs) are boxes that are deployed in the
network, sometimes by the customer but more commonly by the SIP
service provider, to enable NAT traversal for standard client-server
SIP. SBCs are becoming more common, but typically sit on the border
of a "trusted" SIP service provider network and an "untrusted"
network (usually the public Internet). In a distributed network of
P2PSIP peers, there is no single boundary where an SBC would be
appropriate. Furthermore, SBCs are typically designed to work in
client-server deployments, and even then only with the SIP proxy
servers of a specific SIP service provider. Thus they are not well
suited as a NAT traversal option for P2PSIP networks.
NAT traversal is often much easier if the user can manually configure
the NAT. The user can open up pinholes in the NAT and/or modify the
NAT's behavior. However, this requires that the user have the
knowledge and interest to do the configuration (non-technical users
often do not), have a NAT that is configurable (some low-end NATs are
not configurable), and have permission to configure the NAT
(problematic in corporate environments or when there are NATs in the
ISP's network). Like UPnP, manual configuration cannot provide a
Cooper & Matthews Expires September 4, 2007 [Page 15]
Internet-Draft NATs and Overlays March 2007
complete solution if there are multiple NATs between the P2PSIP
device and the public Internet.
11. References
11.1. Normative References
11.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
http://www.ietf.org/rfc/rfc3261.txt, June 2002.
[RFC3263] Rosenberg, J., and Schulzrinne, H., "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
http://www.ietf.org/rfc/rfc3263.txt, June 2002.
[p2p-comm] Ford, B., Srisuresh, P., and Kegel, D., "State of Peer-to-
Peer (P2P) Communication Across Network Address Translators
(NATs)", draft-ietf-behave-p2p-state-02 (work in progress),
http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-
state-02.txt, February 2007.
[nat-consider] Rosenberg, J., "Considerations for Selection of
Techniques for NAT Traversal", draft-iab-nat-traversal-
considerations-00 (expired),
http://tools.ietf.org/html/draft-iab-nat-traversal-
considerations-00.
[ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal
for Offer/Answer Protocols," draft-ietf-mmusic-ice-13 (work
in progress), http://www.ietf.org/internet-drafts/draft-
ietf-mmusic-ice-13.txt.
[nat-scenarios] Boulton, C., Rosenberg, J. and Camarillo, G., "Best
Current Practices for NAT Traversal for SIP", draft-ietf-
sipping-nat-scenarios-06 (work in progress),
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-
scenarios-06.txt, March 2007.
Cooper & Matthews Expires September 4, 2007 [Page 16]
Internet-Draft NATs and Overlays March 2007
[outbound] Jennings, C. and Mahy, R., "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-07 (work in progress),
http://www.ietf.org/internet-drafts/draft-ietf-sip-
outbound-07.txt, January 2007.
[chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
Scalable Peer-to-peer Lookup Service for Internet
Applications" article(s) available at
http://pdos.csail.mit.edu/chord/pubs.html.
[use-cases] Bryan, D. A., Shim, E. and Lowekamp, B. B., "Use Cases
for Peer-to-Peer Session Initiation Protocol (P2P SIP)",
draft-bryan-sipping-p2p-usecases-00 (expired),
http://tools.ietf.org/id/draft-bryan-sipping-p2p-usecases-
00.txt.
[illuminati] Cadaco, M. and Freedman, M., "Illuminati - Opportunistic
Network and Web Measurement",
http://illuminati.coralcdn.org/stats, February 2007.
[concepts] Bryan, D., Matthews, P., Shim, E. and Willis, D.,
"Concepts and Terminology for Peer to Peer SIP", draft-
willis-p2psip-concepts-03 (work in progress),
http://www.ietf.org/internet-drafts/draft-willis-p2psip-
concepts-04.txt, March 2007.
[behave-udp] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP",
RFC4787/BCP127, http://www.ietf.org/rfc/rfc4787.txt,
January 2007.
[behave-tcp] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
Srisuresh, P., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-05 (work in progress),
http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-
05.txt, February 2007.
[dSIP-nat] Cooper, E., Matthews, P., Bryan, D. and Lowekamp, B., "NAT
Traversal for dSIP", draft-matthews-p2psip-dsip-nat-
traversal-00 (work in progress),
http://www.ietf.org/internet-drafts/draft-matthews-p2psip-
dsip-nat-traversal-00.txt, February 2007.
Cooper & Matthews Expires September 4, 2007 [Page 17]
Internet-Draft NATs and Overlays March 2007
[stun] Rosenberg, J., Huitema, C., Mahy, R., and Wing, D., "Simple
Traversal Underneath Network Address Translators (NAT)
(STUN)", draft-ietf-behave-rfc3489bis-05 (work in
progress), http://www.ietf.org/internet-drafts/draft-ietf-
behave-rfc3489bis-05.txt, October 2006.
Author's Addresses
Eric Cooper
Avaya
1135 Innovation Dr.
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x228
Email: ecooper@avaya.com
Philip Matthews
Avaya
1135 Innovation Dr.
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x224
Email: philip_matthews@magma.ca
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Cooper & Matthews Expires September 4, 2007 [Page 18]
Internet-Draft NATs and Overlays March 2007
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cooper & Matthews Expires September 4, 2007 [Page 19]