idnits 2.17.1 draft-matthews-p2psip-nats-and-overlays-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6256 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 P2PSIP WG E. Cooper 2 Internet Draft P. Matthews 3 Intended status: Informational Avaya 4 Expires: September 2007 March 4, 2007 6 The Effect of NATs on P2PSIP Overlay Architecture 7 draft-matthews-p2psip-nats-and-overlays-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 4, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This paper explains the problems created by Network Address 42 Translators (NATs) in Peer-to-Peer (P2P) overlays and recommends some 43 NAT traversal techniques appropriate for P2PSIP networks. Two P2PSIP 44 overlay architectures that accommodate the presence of NATs are 45 described and analyzed. The first is the super-peer scheme used in a 46 number of p2p file-sharing systems today. The second is a scheme 47 where all peers play an equal role in the overlay. 49 Table of Contents 51 1. Introduction...................................................2 52 2. IP Network Structure...........................................3 53 2.1. NAT-Induced Problems in Overlay Networks..................4 54 2.2. NAT Traversal Techniques for P2PSIP Overlays..............5 55 3. Super-Peer Overlay Networks....................................6 56 3.1. NAT-Induced Problems in P2PSIP Super-Peer Overlays........6 57 4. Fully-Distributed Overlay Networks.............................7 58 4.1.1. Aligning the Search and Routing Structures...........8 59 4.1.2. NAT-Induced Problems in Fully-Distributed Overlays..11 60 5. Comparing Super-Peer and Fully-Distributed Overlay Networks...11 61 6. Other Hierarchical Overlay Network Topologies.................11 62 6.1. Modified Super-Peer Overlays.............................11 63 6.2. Representative Overlays..................................12 64 7. Conclusions...................................................13 65 8. Security Considerations.......................................14 66 9. IANA Considerations...........................................14 67 10. Acknowledgments..............................................14 68 APPENDIX A: Other NAT Traversal Techniques.......................15 69 11. References...................................................16 70 11.1. Normative References....................................16 71 11.2. Informative References..................................16 72 Author's Addresses...............................................18 73 Full Copyright Statement.........................................18 74 Intellectual Property............................................19 75 Acknowledgment...................................................19 77 1. Introduction 79 P2P overlay networks have emerged as a popular, scalable and 80 efficient mechanism for sharing music and video files amongst 81 millions of computers. Early P2P file-sharing systems used a 82 combination of highly distributed content storage and a centralized 83 index of the available content to provide easy access to vast amounts 84 of data. Napster was one such system. Due to the legal implications 85 of its unauthorized content distribution, Napster was ordered to 86 cease operations. As soon as the centralized content index was 87 disabled, the Napster network was effectively shut down. 89 Of course, Napster's demise did nothing to squelch the demand for 90 easy access to vast amounts of content. New P2P file-sharing systems 91 emerged to replace Napster and all of them were designed without a 92 centralized content index. Various schemes were used to locate 93 content in these new networks. Some transmitted content queries 94 randomly amongst nodes, while others would flood the queries 95 throughout the network. Neither of these techniques was particularly 96 effective or efficient at locating content. Then P2P overlays adopted 97 a distributed hash table (DHT) approach for indexing their content. 98 As their name suggests, DHTs distribute the content index across many 99 nodes. DHTs do provide an effective and relatively efficient indexing 100 mechanism. The drawback is that as a result of this distribution, a 101 query into a DHT must be processed by a number of nodes before the 102 result can be determined. 104 As a result of their evolution, current P2P file-sharing overlays use 105 both distributed content storage and distributed context indexing. By 106 eliminating all centralization in the system, these P2P overlays have 107 gained a number of interesting benefits. They are self-organizing, 108 highly scalable, highly reliable and require very little 109 administration. 111 From a structural perspective, today's SIP networks have a lot in 112 common with the Napster file-sharing network. The 'content' in a SIP 113 system is the real-time data that flows directly between the nodes. 114 Although it doesn't need to be stored anywhere, the source addresses 115 of the 'content' must be collected into an index that can be easily 116 accessed. This index is analogous to the contact binding information 117 that is stored by Registrars. Of course, SIP networks do not face the 118 same legal difficulties as P2P file-sharing systems. They do, 119 however, have scalability, reliability and administrative concerns. 121 The P2PSIP working group is investigating how P2P techniques might be 122 used in conjunction with (or as an alternative to) the DNS-based 123 lookup and routing mechanisms of [RFC3261] and [RFC3263]. This paper 124 explores the problems introduced by the presence of NATs in the 125 network topology and discusses their effects on the P2PSIP overlay 126 architecture. 128 Comments on this draft are solicited and should be addressed either 129 to the authors or to the P2P-SIP mailing list at p2psip@ietf.org (see 130 https://www1.ietf.org/mailman/listinfo/p2psip). 132 2. IP Network Structure 134 Overlay networks create a set of virtual links on top of the routes 135 of the underlying IP network. These virtual links are usually 136 structured to optimize the overlay for a particular purpose, such as 137 content indexing. 139 ,-------. 140 ,' P P `. Subnet 1 ,-----. Subnet 2 141 ( P ) ( P ) 142 `. P P ,' `-----' 143 `-------' NAT 144 NAT 145 _.------------. 146 ,--'' `---. 147 ,-' `-. 148 / \ 149 / \ 150 ( Internet ) 151 \ / 152 \ / 153 `-. ,-' 154 `---. _.--' 155 N A T `------------'' 156 ,-. ,-. ,-----. 157 / P \ ( P ) Subnet 4 ,' P `. Subnet 5 158 ( P ) `-' ( P P ) 159 \ P/ `. P ,' 160 `-' Subnet 3 `-----' 162 Legend 163 P - Peer node 164 NAT - NAT box 166 Figure 1 Example IP Network Topology 168 Figure 1 shows a set of peers (denoted by Ps) that want to create an 169 overlay on top of an IP network. In this figure we see six clouds. 170 Five represent IP subnets containing peers and one represents the 171 Internet. One of the subnets uses public IP addresses, while the 172 other subnets have NATs between them and the Internet and thus use 173 private addresses. Two of the subnets are sitting behind the same 174 NAT. More complex network topologies are not depicted, but it would 175 not be uncommon for an overlay network to include peers that were 176 separated from the Internet by two or more NATs. 178 2.1. NAT-Induced Problems in Overlay Networks 180 Some P2P overlays assume that all participating nodes are linked by 181 unimpeded IP connectivity. Unfortunately, the use of NATs is very 182 common, which means that a great many IP networks span multiple 183 addressing spaces. 185 Straightforward deployment of P2P overlays on IP networks involving 186 NATs would cause the overlay's mechanisms to fail because: 188 . The private IP addresses of some peers would be considered un- 189 deliverable by the routers in the public Internet. This would 190 cause messages to be discarded. 192 . The IP addresses of some peers could conflict if the overlay 193 included multiple private address spaces. This would cause 194 messages to be delivered to the wrong peer. 196 . NATs perform mapping and filtering functions at the borders 197 between two addressing realms, and will frequently discard 198 packets they consider "unsolicited". From a NAT's perspective, 199 a message must be sent from a peer on its "private" side to a 200 peer on its "public" side before a message can travel in the 201 opposite direction. 203 All these mis-directed and dropped messages will cause overlay 204 services to fail and may prevent the participating peers from 205 constructing or maintaining overlay correctly. 207 2.2. NAT Traversal Techniques for P2PSIP Overlays 209 NAT traversal is a well-known problem for SIP networks and much 210 effort has been devoted to solving it. [p2p-comm] discusses some 211 popular mechanisms for P2P systems and recommends a combination of 212 "NAT hole-punching" and "relay" techniques to establish 213 communications between peers in NATed networks. 215 Based upon the arguments for an UNSAF approach presented in [nat- 216 consider], [ice] defines a mechanism for employing these two 217 techniques in SIP networks to route media streams between two NATed 218 endpoints. The use of ICE and other SIP NAT traversal techniques, 219 such as "symmetric signaling response" and "connection re-use", is 220 encouraged by [nat-scenarios]. 222 Since NATs create similar (and perhaps more severe) problems for 223 P2PSIP overlays, all of these mechanisms will need to be adopted for 224 P2PSIP overlay signaling protocols. Other SIP techniques, such as 225 [outbound], may also prove useful for P2PSIP systems. 227 The applicability of some other NAT traversal techniques is discussed 228 in APPENDIX A: 230 3. Super-Peer Overlay Networks 232 One way to organize a P2P overlay is to create an overlay topology in 233 which the publicly addressable peers (dubbed "super-peers") act as 234 relay points for the NATed peers. This structure essentially creates 235 a hierarchy in the overlay network. The super-peers (at the top 236 level) supply the content indexing function and provide message 237 routing to/from NATed peers. NATed peers are at a lower level. They 238 may advertise their content and query for content via their 239 associated super-peer, but do not process any queries or store any of 240 the content index data. 242 __,,.O.,------------.....__ 243 ,,-'' Super-Peer `'--.. 244 '' Super-Peer`O 245 `O Super-Peer / NAT 246 `.._ Super-Peer __.-' \ 247 `'--O....._ Super-Peer.---'' \ 248 NAT `----------O-'' O 249 /\ NAT NATed Peer 250 / \ /\ 251 O O NATed Peers O O 253 Figure 2 P2P Overlay with Super-Peers 255 3.1. NAT-Induced Problems in P2PSIP Super-Peer Overlays 257 The super-peer overlay network organization provides a simple and 258 efficient model for NAT traversal in P2PSIP networks. Its routing 259 structure has the advantage that a message sent from one peer to 260 another traverses at most 3 hops. 262 The main drawback of this approach is that it requires a sufficient 263 number of publicly addressable nodes to act as super-peers. In 264 addition, the super-peers must bear the entire load associated with 265 message routing. 267 Several P2PSIP use case scenarios are described in [use-cases]. 268 Referring back to Figure 1, one example of a P2PSIP "Managed Private 269 Network" scenario could include peers from subnets 1-4, but no peers 270 with public addresses. In such a network, a super-peer routing 271 topology is simply not possible. 273 Other use cases, including the "Public P2P VoIP Service Providers" 274 and "Open Global P2P VoIP Network" scenarios do include peers from 275 all five subnets. These overlay networks will have some percentage of 276 publicly addressable peers. One measurement has found that 74% of 277 web-browsing clients are behind NATs [illuminati]. If a similar 278 percentage of P2PSIP peers are NATed, a super-peer overlay topology 279 will be able to utilize only 1/4 of the resources available. 281 The bandwidth available at the super-peers is of particular concern. 282 Since every message in the overlay must traverse the IP links to the 283 super-peers, it's possible that super-peers with low-bandwidth links 284 will be overwhelmed, while high-bandwidth links to NATed peers will 285 be almost completely unused. 287 Further, the use of a super-peer routing structure requires that each 288 NATed peer must establish a long-lived association to a super-peer. 289 [behave-udp] and [behave-tcp] require the use of periodic "keep- 290 alive" traffic to ensure connectivity across the intervening NAT. It 291 follows that the amount of keep-alive traffic arriving at a given 292 super-peer will be proportional to the number of NATed peers it 293 serves. Thus, in super-peer overlays, it is important to assign NATed 294 peers to super-peers such that only a reasonably small fraction of 295 the super-peer's bandwidth is consumed by keep-alive traffic. In 296 other words, the routing structure should be constructed such that 297 the super-peer's bandwidth is not overwhelmed. A mechanism for 298 distributing the load across super-peers will need to be created. 300 Another consequence of the super-peer routing structure is that the 301 amount of keep-alive traffic crossing a given NAT will be 302 proportional to the number of peers behind that NAT (regardless of 303 how those peers are distributed across super-peers). 305 Due to its connectionless nature, the bandwidth considerations are 306 considerably more pronounced for UDP than for TCP. However, TCP 307 connections require more state information to be maintained at the 308 super-peer. Both protocols require state information to be maintained 309 at the NAT. 311 4. Fully Distributed Overlay Networks 313 As an alternative to the hierarchy created by super-peer overlays, it 314 is also possible to use the techniques of section 2.2. to create a 315 completely flat overlay network in which all peers are equal 316 participants. Such fully-distributed overlays also avoid the problems 317 created by NATs in the search algorithm (discussed in section 2.1. 318 and the problems in the super-peer routing topology (discussed in 319 section 3.1. 321 This approach does not place special emphasis on nodes with publicly 322 reachable addresses and can be deployed over any IP network topology. 324 Since all peers participate in the search scheme and in message 325 routing, all of the available resources can be utilized. 327 [dSIP-nat] is one example of a fully distributed overlay that uses 328 SIP-based messaging to implement a DHT search algorithm. Fully 329 distributed P2PSIP overlay networks could also be built using other 330 protocols and/or other search algorithms. 332 4.1.1. Aligning the Search and Routing Structures 334 Many DHTs route queries amongst peers such that any query can reach 335 the appropriate (authoritative for that query) peer in O(log N) hops. 336 As previously mentioned, the problem is that these searching 337 structures do not account for impediments in IP routing. Creating a 338 routing structure that mirrors the search algorithm will preserve the 339 efficiency of the search algorithm as much as possible. 341 To determine the specifics of the routing structure, we examine the 342 search algorithm in a bit more detail. Chord is used as an example. 343 To process queries, peers participating in a chord overlay maintain 344 tables of other peers that will assist in routing queries to their 345 destinations. These tables form a good starting point for the 346 routing topology. 348 In Chord, some unique peer attribute is hashed using SHA-1 and the 349 result (called a peer identifier) is used to place peers on a 350 conceptual ring. Each peer then maintains connections to peers 351 located at exponentially increasing locations going clockwise around 352 the ring. For example, a peer P, with ID 0 might have a table 353 consisting of addresses for peers with IDs 2^0, 2^1, 2^2,..., 2^(n/2) 354 (where n=# of output bits for SHA-1). 356 In this routing structure, a message to peer Q can be addressed to 357 Q's location in the ring, and any intermediate peer R can forward the 358 message by selecting the peer from its connection table that is that 359 is closest to Q without overshooting Q. 361 Many other connection structures exist. For example, structured 362 routing topologies can be created using the ideas contained in any 363 one of a number of DHT schemes. The important point is that the 364 structure of the routing topology matches the message flow required 365 by the search algorithm. 367 4.1.1.1. Symmetric Interest 369 When considering connection topologies, there is a property we have 370 dubbed "symmetric interest". A connection structure exhibits 371 "symmetric interest" if, when peer P desires a connection to peer Q, 372 then peer Q also desires a connection to peer P. 374 A routing structure based on peers randomly selecting other peers to 375 connect to does NOT exhibit symmetric interest because peer P can 376 select peer Q without peer Q selecting peer P. Similarly, a Chord- 377 based connection structure (depicted in Figure 3) also does NOT 378 exhibit symmetric interest because a given peer P in the ring desires 379 connections to peers in the clockwise half-circle but not in the 380 counter-clockwise half-circle. 382 O 383 O | O 384 O | O 385 | 386 O | O 387 | 388 | 389 O------ | O 390 \ | 391 \ | 392 O \ | O 393 \ | 394 O-------\ | O 395 \ | 396 O----\| O 397 O Peer Q 398 Peer P 400 Figure 3 Chord-based Connection Structure 1 402 Figure 3 depicts a connection topology from the perspective of a 403 single peer P. As described in section 4.1.1. if P's ID were 0, it 404 might have a table consisting of addresses for peers with IDs 2^0, 405 2^1, 2^2,..., 2^(n/2). Peer P would never include Peer Q in its 406 connection table, since Q's ID is greater 2^(n/2). However, Peer Q's 407 connection table may include Peer P, since P's ID is contained in the 408 clockwise half-circle starting at Q's ID. Figure 4 illustrates the 409 same connection topology from the perspective of Peer Q. 411 O 412 O O 413 \ 414 \ 415 O \ O 416 \ 417 \ 418 O \ O 419 /---------\ 420 / \ 421 O \ O 422 \ 423 O /-----\ O 424 / \ 425 O /---O 426 O Peer Q 427 Peer P 429 Figure 4 Chord-based Connection Structure 2 431 One topology that does exhibit symmetric interest has each peer 432 maintaining connections to peers located an exponentially increasing 433 distances going both clockwise AND counter-clockwise around the ring. 435 O 436 O | O 437 O | O 438 | 439 O | O 440 | 441 | 442 O------ | ------O 443 \ | / 444 \ | / 445 O \ | / O 446 \ | / 447 O-------\ | /--------O 448 \ | / 449 O----\|/----O 450 O Peer Q 451 Peer P 453 Figure 5 Symmetric Partial Mesh 455 "Symmetric interest" seems a desirable property for routing 456 topologies because connections through NATs, by their nature, are bi- 457 directional and because both peers incur the overhead of sending 458 keep-alives to maintain the connection. 460 4.1.2. NAT-Induced Problems in Fully Distributed Overlays 462 As mentioned in section 3.1. each routing connection that crosses a 463 NAT must be maintained by P2PSIP peers. This applies to the fully 464 distributed overlay network too. 466 There is a possibility that the number of viable connections in a 467 peer's table might be constrained by the number of 'pinhole' mapping 468 and filtering entries that can be supported by a peer's local NAT. 469 Unfortunately, NAT behaviour is notoriously variable, so it is 470 difficult to predict the achievable size for a peer's connection 471 table. If the number of entries in this table is reduced below the 472 DHT's prescribed size, the message routing efficiency may be reduced, 473 or fail completely. For example, under a Chord-based routing 474 topology, the connection to the peer's immediate successor is 475 critically important. Without that link, messages may fail to reach 476 their destination. The other connections in a Chord-based structure 477 are used to improve routing efficiency, but some may be removed 478 without jeopardizing routing correctness. 480 So in a fully distributed overlay, peers may need to reduce the size 481 of their connection tables to accommodate limitations in their local 482 NATs. This can reduce the search algorithm's efficiency. 484 Interestingly, when large numbers of peers are operating behind the 485 same NAT, DHT-based search algorithms is likely to create many 486 connections that do not need to cross the NAT. 488 5. Comparing Super-Peer and Fully Distributed Overlay Networks 490 << [concepts] describes three modes of operation under which P2PSIP 491 peers can register and make calls. These modes are variations on 492 how user contact information in stored, retrieved and used by peers 493 in the overlay network. A future version of this paper will compare 494 the performance of the super-peer and fully distributed overlays 495 under each mode. >> 497 6. Other Hierarchical Overlay Network Topologies 499 6.1. Modified Super-Peer Overlays 501 As discussed in section 3.1. super-peer routing topologies can 502 encounter difficulties when many peers are behind the same NAT. The 503 resources (bandwidth, state-information) required for NAT traversal 504 could be reduced if a single "Representative" peer were elected to 505 proxy all the traffic between the NATed peers and the super-peer. An 506 overlay utilizing both super-peers and representatives is depicted in 507 Figure 6. 509 __,,.O.,------------.....__ 510 ,,-'' Super-Peer `'--.. 511 '' Super-Peer`O 512 `O Super-Peer / NAT 513 `.._ Super-Peer __.-' \ 514 `'--O...._ Super-Peer.---'' \ 515 NAT `-----------O-'' O 516 | NAT Representative Peer 517 | | 518 O Representatives O 519 / \ / \ 520 O O NATed Peers O O 522 Figure 6 Overlay Network with Super-Peers and Representatives 524 The network shown in Figure 6 minimizes the amount of effort that 525 needs to be expended for NAT pinhole maintenance, but introduces 526 another level of hierarchy into the overlay and thus increases 527 message hop counts. Further, it requires some new mechanism to allow 528 NATed peers to discover each other and elect a representative. 530 In this topology, both the super-peer and the representative are 531 assumed to be servicing large numbers of NATed peers, so their 532 performance and availability are a concern. 534 6.2. Representative Overlays 536 It's worth noting that the super-peer and representative concepts are 537 independent of each other. It is possible to construct an overlay 538 network in which representative peers (residing behind NATs) use ICE 539 NAT traversal techniques to create connections to other peers in the 540 overlay. No super-peers (publicly addressable peers) need be present 541 in such a network. 543 This is a similar type of hierarchy to the super-peer hierarchy in 544 that representative peers connected in such a way would have overlay 545 IDs and implement the search algorithm and NATed peers would not. 546 This type of overlay topology would increase the number of 547 connections crossing the NAT above the bare minimum required in 548 Figure 6, but instead of being proportional to the number of super- 549 peers serving nodes behind a NAT, it would instead be related to the 550 number of connections the representative had to other peers. 552 As with the super-peer overlay, representatives are assumed to be 553 serving large numbers of NATed peers, so performance and availability 554 are concerns. 556 Introducing hierarchy into an overlay network, either through super- 557 peers or representatives, is a relatively effective NAT traversal 558 technique. However, it requires that super-peers and/or 559 representatives must perform two distinct routing operations: one to 560 direct search queries to other super-peers and another one to allow 561 NATed peers to access the overlay. 563 The inclusion of a hierarchy also requires the creation of new 564 techniques to distribute the load appropriately and recover from 565 failures. These mechanisms are generally independent from similar 566 mechanisms already present in search algorithms like DHTs. 568 7. Conclusions 570 The presence of NATs in IP networks present several challenges for 571 P2PSIP overlays. A super-peer overlay architecture is easy-to- 572 understand and provides effective NAT traversal. However, it 573 concentrates the network load on a small percentage of the 574 participating nodes and cannot be used in networks that have no 575 publicly addressable peers. 577 Fully distributed overlays traverse NATs equally well and share the 578 load evenly across participating peers, which results in greater 579 performance and scalability. Since they do not require any nodes to 580 have public IP addresses, these architectures can be applied to more 581 IP network topologies. 583 Fully distributed networks implicitly determine (based upon their 584 search algorithm) how many connections will cross a peer's local NAT. 585 Depending on the search algorithm, it may be possible to adjust the 586 number of connections so no single NAT is overwhelmed by the keep- 587 alive traffic or number of mappings it needs to maintain. 589 Super-peer overlays have no inherent mechanism for associating NATed 590 peers with super-peers, so one must be created. In creating this 591 mechanism special consideration must be given to the resources 592 available at both the super-peer and in the NAT. Due to their role as 593 routers for overlay messages, super-peers that serve many NATed peers 594 must be highly available and have high-bandwidth Internet links. 596 In fully distributed networks the connections required for message 597 routing are the same ones used by the search algorithm. Since the 598 routing topology in a super-peer overlay is separate from the 599 searching mechanism, a super-peer overlay will devote extra resources 600 to NAT traversal. 602 8. Security Considerations 604 Security Considerations will be covered in a later version of this 605 paper. 607 9. IANA Considerations 609 IANA considerations will be covered in a later version of this paper. 611 10. Acknowledgments 612 APPENDIX A: Other NAT Traversal Techniques 614 In addition to the techniques discussed in section 2.2. other 615 addition to those, some other mechanisms for NAT traversal are: UPnP, 616 ALGs, SBCs, and manual configuration. 618 Universal Plug-n-Play (UPnP) is a NAT configuration scheme developed 619 by Microsoft. This HTTP/XML based protocol allows applications to 620 dynamically create forwarding rules in the NAT as needed. Many 621 consumer-grade NATs support the UPnP protocol, which makes this seem 622 quite promising for P2P applications targeted only at the consumer 623 market. However, most corporate-grade NATs do not support UPnP. Even 624 in the consumer market space, the user would be required to provide 625 the administrative password for the NAT. Further, even if 626 administrative access to the NAT is possible, UPnP cannot provide a 627 complete solution if there are multiple NATs between the P2PSIP 628 device and the public Internet. 630 Many NATs contain one or more Application Level Gateways (ALGs). An 631 ALG is special code within the NAT that recognizes packets of a 632 particular application-level protocol and treats the packets 633 specially. ALG support for the File Transfer Protocol (FTP) is almost 634 universal in NATs, and ALG support for SIP is becoming more common. 635 However, ALG support requires that the application protocol not be 636 encrypted end-to-end, and end-to-end encryption of both SIP and P2P 637 messages is likely to be desirable for security reasons. 639 Session Border Controllers (SBCs) are boxes that are deployed in the 640 network, sometimes by the customer but more commonly by the SIP 641 service provider, to enable NAT traversal for standard client-server 642 SIP. SBCs are becoming more common, but typically sit on the border 643 of a "trusted" SIP service provider network and an "untrusted" 644 network (usually the public Internet). In a distributed network of 645 P2PSIP peers, there is no single boundary where an SBC would be 646 appropriate. Furthermore, SBCs are typically designed to work in 647 client-server deployments, and even then only with the SIP proxy 648 servers of a specific SIP service provider. Thus they are not well 649 suited as a NAT traversal option for P2PSIP networks. 651 NAT traversal is often much easier if the user can manually configure 652 the NAT. The user can open up pinholes in the NAT and/or modify the 653 NAT's behavior. However, this requires that the user have the 654 knowledge and interest to do the configuration (non-technical users 655 often do not), have a NAT that is configurable (some low-end NATs are 656 not configurable), and have permission to configure the NAT 657 (problematic in corporate environments or when there are NATs in the 658 ISP's network). Like UPnP, manual configuration cannot provide a 659 complete solution if there are multiple NATs between the P2PSIP 660 device and the public Internet. 662 11. References 664 11.1. Normative References 666 11.2. Informative References 668 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 669 A., Peterson, J., Sparks, R., Handley, M., and E. 670 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 671 http://www.ietf.org/rfc/rfc3261.txt, June 2002. 673 [RFC3263] Rosenberg, J., and Schulzrinne, H., "Session Initiation 674 Protocol (SIP): Locating SIP Servers", RFC 3263, 675 http://www.ietf.org/rfc/rfc3263.txt, June 2002. 677 [p2p-comm] Ford, B., Srisuresh, P., and Kegel, D., "State of Peer-to- 678 Peer (P2P) Communication Across Network Address Translators 679 (NATs)", draft-ietf-behave-p2p-state-02 (work in progress), 680 http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p- 681 state-02.txt, February 2007. 683 [nat-consider] Rosenberg, J., "Considerations for Selection of 684 Techniques for NAT Traversal", draft-iab-nat-traversal- 685 considerations-00 (expired), 686 http://tools.ietf.org/html/draft-iab-nat-traversal- 687 considerations-00. 689 [ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 690 Methodology for Network Address Translator (NAT) Traversal 691 for Offer/Answer Protocols," draft-ietf-mmusic-ice-13 (work 692 in progress), http://www.ietf.org/internet-drafts/draft- 693 ietf-mmusic-ice-13.txt. 695 [nat-scenarios] Boulton, C., Rosenberg, J. and Camarillo, G., "Best 696 Current Practices for NAT Traversal for SIP", draft-ietf- 697 sipping-nat-scenarios-06 (work in progress), 698 http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- 699 scenarios-06.txt, March 2007. 701 [outbound] Jennings, C. and Mahy, R., "Managing Client Initiated 702 Connections in the Session Initiation Protocol (SIP)", 703 draft-ietf-sip-outbound-07 (work in progress), 704 http://www.ietf.org/internet-drafts/draft-ietf-sip- 705 outbound-07.txt, January 2007. 707 [chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., 708 Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A 709 Scalable Peer-to-peer Lookup Service for Internet 710 Applications" article(s) available at 711 http://pdos.csail.mit.edu/chord/pubs.html. 713 [use-cases] Bryan, D. A., Shim, E. and Lowekamp, B. B., "Use Cases 714 for Peer-to-Peer Session Initiation Protocol (P2P SIP)", 715 draft-bryan-sipping-p2p-usecases-00 (expired), 716 http://tools.ietf.org/id/draft-bryan-sipping-p2p-usecases- 717 00.txt. 719 [illuminati] Cadaco, M. and Freedman, M., "Illuminati - Opportunistic 720 Network and Web Measurement", 721 http://illuminati.coralcdn.org/stats, February 2007. 723 [concepts] Bryan, D., Matthews, P., Shim, E. and Willis, D., 724 "Concepts and Terminology for Peer to Peer SIP", draft- 725 willis-p2psip-concepts-03 (work in progress), 726 http://www.ietf.org/internet-drafts/draft-willis-p2psip- 727 concepts-04.txt, March 2007. 729 [behave-udp] Audet, F. and C. Jennings, "Network Address Translation 730 (NAT) Behavioral Requirements for Unicast UDP", 731 RFC4787/BCP127, http://www.ietf.org/rfc/rfc4787.txt, 732 January 2007. 734 [behave-tcp] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 735 Srisuresh, P., "NAT Behavioral Requirements for TCP", 736 draft-ietf-behave-tcp-05 (work in progress), 737 http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp- 738 05.txt, February 2007. 740 [dSIP-nat] Cooper, E., Matthews, P., Bryan, D. and Lowekamp, B., "NAT 741 Traversal for dSIP", draft-matthews-p2psip-dsip-nat- 742 traversal-00 (work in progress), 743 http://www.ietf.org/internet-drafts/draft-matthews-p2psip- 744 dsip-nat-traversal-00.txt, February 2007. 746 [stun] Rosenberg, J., Huitema, C., Mahy, R., and Wing, D., "Simple 747 Traversal Underneath Network Address Translators (NAT) 748 (STUN)", draft-ietf-behave-rfc3489bis-05 (work in 749 progress), http://www.ietf.org/internet-drafts/draft-ietf- 750 behave-rfc3489bis-05.txt, October 2006. 752 Author's Addresses 754 Eric Cooper 755 Avaya 756 1135 Innovation Dr. 757 Ottawa, Ontario K2K 3G7 758 Canada 760 Phone: +1 613 592 4343 x228 761 Email: ecooper@avaya.com 763 Philip Matthews 764 Avaya 765 1135 Innovation Dr. 766 Ottawa, Ontario K2K 3G7 767 Canada 769 Phone: +1 613 592 4343 x224 770 Email: philip_matthews@magma.ca 772 Full Copyright Statement 774 Copyright (C) The IETF Trust (2007). 776 This document is subject to the rights, licenses and restrictions 777 contained in BCP 78, and except as set forth therein, the authors 778 retain all their rights. 780 This document and the information contained herein are provided on an 781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 783 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 784 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 785 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Intellectual Property 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Acknowledgment 814 Funding for the RFC Editor function is provided by the IETF 815 Administrative Support Activity (IASA).