idnits 2.17.1 draft-johnston-sipping-p2p-ipcom-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 608. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 5, 2006) is 6625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 534, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-01 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group A. Johnston 3 Internet-Draft SIPStation 4 Expires: September 6, 2006 H. Sinnreich 5 pulver.com 6 March 5, 2006 8 SIP, P2P, and Internet Communications 9 draft-johnston-sipping-p2p-ipcom-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This draft discusses issues related to the application of peer to 43 peer (P2P) technologies to SIP in particular, and Internet 44 communications in general. After an analysis of the P2P and non-P2P 45 capabilities of SIP, this draft proposes that a P2P protocol be 46 standardized in the IETF as a protocol used between a Registrar/ 47 Proxy/Redirect server and a Location Service. This allows the 48 operator of a Registrar to decide how much registration state is be 49 stored locally and how much can be distributed using the P2P network 50 to a distributed Location Server. A number of DHT (Distributed Hash 51 Table) P2P protocols that solve some similar functions are given as 52 examples and could be used as input to this work. Finally, existing 53 SIP and P2P work is surveyed with respect to this proposal. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. P2P Capabilities in SIP . . . . . . . . . . . . . . . . . . . 3 59 3. Making SIP a True P2P Protocol . . . . . . . . . . . . . . . . 4 60 4. Operation of a Location Service Protocol . . . . . . . . . . . 7 61 5. Location Service Protocol as a P2P Protocol . . . . . . . . . 8 62 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. P2P Implementation using Distributed Hash Tables . . . . . . . 9 64 8. SIP P2P Implementations . . . . . . . . . . . . . . . . . . . 10 65 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 12. Informative References . . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 P2P technologies have been widely used on the Internet in file 75 sharing and other applications including VoIP, IM, and presence. 76 Other Internet-Drafts have been written which explore some of the 77 requirements [4] and example implementations [3] of P2P SIP. 79 This draft attempts to analyze the current P2P capabilities in SIP, 80 then discusses the non-P2P aspects of SIP. The high level operation 81 of the proposed Location Service Protocol is outline. Some P2P 82 research work using the Chord protocol is then surveyed. Finally, 83 existing SIP and P2P work is compared to this proposal. 85 2. P2P Capabilities in SIP 87 SIP [1] actually already has quite a lot of inherent P2P 88 capabilities, although most deployments of SIP today barely take 89 advantage of them. For instance, all servers in SIP are optional, 90 allowing User Agents (UAs) to directly communicate. Even when a 91 server such as a proxy server is utilized, after the initial 92 exchange, subsequent messaging is routed on a peer to peer basis 93 using the Contact URI. Even presence can be published and retrieved 94 in a peer to peer manner [2]. However, much development in SIP has 95 been in the area of intermediaries. While the standard specification 96 discusses in detail the roles of registrars, proxy servers, and 97 redirect servers, many actual deployments of SIP have instead used 98 B2BUA intermediaries which completely break the P2P properties of SIP 99 by design. 101 Efforts in SIP to make Contact URIs routable outside dialogs seemed 102 to be moving SIP in a P2P direction. However, the current work in 103 this area (i.e. standardizing GRUUs, Globally Routable User Agent 104 URIs [12]) unfortunately mixes the definition of the GRUU and a 105 particular acquisition mechanism. The proposed mechanism actually 106 permanently includes intermediaries in the signaling path. As such, 107 the currently defined GRUU mechanism is not applicable to P2P SIP. 108 Hopefully alternative GRUU mechanisms compatible with P2P will be 109 developed in the future as the full implications of the current 110 approach are realized. 112 As a result, SIP is not yet a true Internet protocol. It is used 113 today in closed networks, within walled gardens, and in mediated- 114 middle networks. Much of its complexity is a side effect of its 115 deployment in these environments. Some of us, however, have used SIP 116 in P2P mode over the Internet for our personal communication for 117 years. 119 For SIP to truly become an Internet protocol, it needs to escape 120 these closed networks and spread in the public Internet. The best 121 way to make this happen is for SIP to take advantage of P2P 122 technology and truly harness the P2P properties of SIP, rendering the 123 closed networks and their intermediaries irrelevant. 125 3. Making SIP a True P2P Protocol 127 As hinted in the previous section, there are a variety of non- 128 technical reasons why the P2P capabilities in SIP have not been 129 widely utilized. In this section, some technical reasons why SIP is 130 currently not truly P2P are discussed. This leads to a proposal to 131 correct this. 133 Consider the typical routing of a SIP request over the SIP Trapezoid 134 introduced in RFC 3261 [1] is reproduced in part in Figure 1 below. 136 atlanta.com . . . biloxi.com 137 . proxy proxy . 138 . . 139 Alice . . . . . . . . . . . . . . . . . . . . Bob 140 sip:alice@atlanta.com sip:bob@biloxi.com 141 | | | | 142 | REQUEST F1 | | | 143 |--------------->| REQUEST F2 | | 144 | |--------------->| REQUEST F3 | 145 | | |--------------->| 147 Figure 1. SIP Request Routing with the Trapezoid 149 An analysis of why this typical interdomain request flow involves 150 multiple proxies provides some useful insights into how SIP can 151 operate in a more P2P manner. 153 Alice wants to send a SIP request to Bob using Bob's Address of 154 Record (AOR) sip:bob@biloxi.com. The request is shown as first 155 routing through the atlanta.com proxy server before being routed to 156 the biloxi.com proxy server. As such, atlanta.com is acting as a 157 "outbound proxy" server. The use of a default outbound proxy server 158 could be required if the UA, for example, does not support the DNS 159 queries necessary to locate the biloxi.com domain. Another reason 160 might be that the outbound proxy server is performing some NAT/ 161 firewall traversal or other services needed to allow Alice to 162 communicate with the outside world. 164 Today, all UAs support DNS queries including SRV, so the DNS argument 165 is no longer valid - Alice is perfectly capable of locating the 166 biloxi.com server without assistance from the atlanta.com server. In 167 addition, since the publication of RFC 3261, we have other NAT 168 traversal techniques such as STUN, TURN, and ICE. As such, it is 169 possible to remove the atlanta.com proxy server from this call flow, 170 collapsing the trapezoid to a triangle. 172 However, the biloxi.com proxy server is not so easy to eliminate. 173 The NAT/firewall traversal services provided can likely be migrated 174 to STUN and TURN as in the outbound proxy case. However, the proxy 175 server can only be bypassed if Alice can discover Bob's Contact URI 176 (sip:bob@192.0.2.4 in this example) which routes directly to Bob's 177 UA. UAs publish this AOR/Contact URI binding using registration, 178 which is then maintained in the network as soft state. 180 Note that a domain can create AORs which utilized non-SIP methods to 181 maintain this soft state. For example, if Bob uses an AOR URI which 182 has a host part which resolves using dynamic DNS, then registrar and 183 proxy servers can be removed from the call flow. This requires Bob's 184 SIP devices to run a dynamic DNS client which sends a message to the 185 dynamic DNS Server to update Bob's DNS A record each time Bob's IP 186 address changes. In this mode, Bob no longer sends REGISTERs - the 187 dynamic DNS updates take the place of registrations. (Note that in 188 this context, dynamic DNS is not DNS Dynamic Updates [5],[6]. For 189 information on dynamic DNS in this context, Google "dynamic DNS"). 191 This dynamic DNS approach works, and has been used by a number of us 192 for many years to successfully run P2P SIP. Note, however, that many 193 SIP clients require a successful registration before permitting 194 outgoing requests, even though this goes explicitly against RFC 3261 195 which makes it clear that a successful registration has no impact on 196 outgoing requests. Note also that this approach is actually not P2P, 197 as there is still a client/server dynamic DNS protocol being used. 199 Assuming that dynamic DNS is not used, let us examine closely the 200 reasons why the biloxi.com proxy must remain in this call flow. 201 Bob's UA generates registration messages which contain all the 202 information needed to perform P2P SIP routing directly to Bob's UA. 203 This registration information is sent by Bob to the registrar for the 204 biloxi.com domain. The information is then stored in the Location 205 Service for the biloxi.com domain. 207 RFC 3261 formally defines a Location Service as: 209 A location service is used by a SIP redirect or 210 proxy server to obtain information about a callee's possible 211 location(s). It contains a list of bindings of address-of- 212 record keys to zero or more contact addresses. The bindings 213 can be created and removed in many ways; this specification 214 defines a REGISTER method that updates the bindings. 216 This information is then generally only available to proxy servers in 217 the biloxi.com domain. Also, note that the protocol between a 218 registrar and a Location Service or a proxy and a Location Service 219 has never been standardized in the IETF. It is the one protocol in 220 the SIP Trapezoid which is not standardized, and it is this lack of 221 standardization that traps the registration data in the biloxi.com 222 domain and precludes true P2P SIP. 224 In giving SIP tutorials, I am often asked why this protocol has not 225 been standardized. There are a number of reasons given in the past: 227 1. There has been no push to standardize this protocol, and the SIP 228 Trapezoid model does not require it to be standardized. 230 2. The IETF typically does not standardize decomposition protocols 231 such as these, although there are notable exceptions such as MEGACO. 233 3. In addition to the AOR/Contact URI binding, the Location Service 234 is often used to store service logic. Since the IETF does not 235 standardize services, a standard protocol to access a Location 236 Service would be difficult to define without also standardizing (and 237 hence limiting) the services. 239 However, I believe that given the desire to make SIP more P2P, these 240 reasons no longer apply. Specifically: 242 1. Standardizing a Location Service Protocol would allow the 243 biloxi.com proxy server to be bypassed, allowing true interdomain P2P 244 communication between Alice and Bob, a goal shared by many of us in 245 the SIP community for a variety of scalability, privacy, and security 246 reasons. 248 2. While this protocol could be used to decompose a SIP Server farm 249 (and this is a very useful thing) within a domain, its use in an 250 interdomain P2P network makes it an Internet protocol and hence of 251 interest to the IETF. 253 3. In the pure P2P model, services are exclusively provided by 254 endpoints, not intermediary servers, reducing the requirements of his 255 protocol to purely AOR/Contact URI binding. The analysis in [4] 256 confirms this view and suggests that even standard telephony services 257 can be provided by peers without resorting to centralized servers. 259 As such, the IETF should standardize this protocol to enable true P2P 260 SIP. 262 As an aside, the IETF has developed TRIP (Telephony Routing over IP) 263 [7] which is an inter-Location Service protocol used to discover PSTN 264 gateway routes. It is possible that TRIP could be extended beyond 265 telephony routing to allow Location Servers to exchange AOR/Contact 266 URI bindings. However, it is fundamentally a routing protocol rather 267 than a URI discovery mechanism and as such not suitable for this 268 application. 270 4. Operation of a Location Service Protocol 272 The new Location Service Protocol (LSP) (Editor's Note: we definitely 273 need a better name so as to be clear that this protocol has nothing 274 to do with GEOPRIV) would be used between a Registrar, Proxy, or 275 Redirect Server and a Location Service. Other Internet Communication 276 Protocols could also utilize this protocol. For example, in a H.323 277 network, the protocol could be used between a RAS Server and its 278 database. 280 The basic functions are publication of AOR/Contact URI binding, and 281 the querying of AOR/Contact URI binding. Publication would be 282 performed by suitably authorized registrars for a domain, while 283 querying could be performed by proxy servers, redirect servers, or 284 even UAs in other domains. 286 In a conventional SIP network, only the SIP servers would need to 287 support this new protocol - UAs would not need to support a new 288 protocol to take advantage. SIP Servers performing lookups using the 289 Location Service Protocol would redirect the results of the query. 291 A Registrar of a domain can decide if it wants to operate a local 292 Location Service. If so, the protocol can be utilized to store and 293 retrieve the information in the local Location Service. Request 294 routing within the domain could consult this local Location Service 295 for routing. DNS SRV records would be populated to point to the 296 Proxy Servers which would query the local Location Service using the 297 protocol. In short, normal SIP operation. 299 In addition, or instead of a local Location Service, the Registrar 300 may opt to publish registration data in a public Location Service. 301 The protocol could then be used by users in other domains to query 302 the public Location Service, discover the Contact URI of a particular 303 user, and route SIP requests directly, bypassing the domain's Proxy 304 Servers. 306 The reasons why a domain might decide to only publish registration 307 information to the public Location Service are obvious - the domain 308 no longer needs to store this state and maintain SIP Proxy or 309 Redirect Servers for incoming requests. 311 The reasons why a domain might decide to publish this information 312 both locally and publicly are similar. If the information is 313 published locally then the domain still has to run SIP Proxy and 314 Redirect Servers - however, the more users that utilize the public 315 Location Service, the lighter the load on the SIP Servers, reducing 316 cost and complexity for the domain. 318 In this hybrid mode, users have the choice of either performing a DNS 319 query and routing though a SIP Server or using the Location Service 320 Protocol 322 The most interesting scenario from a P2P perspective is when the 323 Registrar decides to keep no registration state. In this case, the 324 Registrar would simply statelessly translate a REGISTER request into 325 the corresponding Location Service Protocol message and publish this 326 information into the public Location Service P2P network. 328 Note that if a UA acts as its own Registrar, it can utilize the 329 Location Service Protocol to publish its information directly into 330 the public Location Service. This mode is the "pure" P2P operation. 331 In this way, the Location Service Protocol does not replace DNS or 332 provide conflicting information, as only the registrar authoritative 333 for the domain would publish information. Once a request is sent, 334 normal SIP identity and security mechanisms can be used to verify 335 that the correct destination has been reached. 337 5. Location Service Protocol as a P2P Protocol 339 This proposed Location Service Protocol would not necessarily need to 340 be a P2P protocol. None of the arguments in the previous sections 341 requires the protocol to be P2P. 343 In the case where the protocol is used within a single domain, the 344 protocol need not be P2P. However, the more interesting case where 345 the protocol is used to establish a distributed public Location 346 Service, or a confederation or clearing house Location Service, the 347 scaling requirements point to a P2P protocol. The need for nodes to 348 join and leave, and for distributed storage and retrieval points to a 349 P2P protocol. 351 The protocol should allow a joining peer to learn the scaling size of 352 the P2P network and provide a mechanism to insert itself into the 353 overlay network. 355 6. NAT Traversal 357 In some P2P Internet communications networks, the discovery, 358 rendezvous, and NAT traversal functions are combined into a single 359 network and service. In fact, joining some networks require you to 360 agree to provide all of these functions, despite the disparate 361 resource requirements. 363 Logically, the Location Service Protocol proposed in this draft 364 should be separate from any NAT traversal functions. A node agreeing 365 to participate in a distributed Location Service network should not 366 have to agree to participate in offering NAT traversal. Also, the 367 underlying P2P protocols, optimized for discovery and rendezvous, 368 should not be complicated and burdened with NAT traversal issues. 369 Instead, these protocols should assume that peers manage their own 370 NAT traversal. 372 The discovery of NAT traversal relay services is a useful P2P 373 functionality in itself, however, and is an orthogonal topic. Once a 374 node behind a NAT acquires a relay, it may then participate in the 375 distributed Location Service P2P network. 377 Note: The NAT traversal required is not identical to TURN [17] as it 378 is defined today. The "lock down" property of TURN that limits it to 379 relaying between a pair of hosts is a useful security property in a 380 peer-wise media session. However, this property will block the 381 arbitrary inter-node communication needed for normal P2P 382 communication. As such, a relay acquired for the purposes of 383 allowing a node behind a NAT to participate in a P2P network, for 384 example, will be similar, but not exactly the same as a TURN server. 386 7. P2P Implementation using Distributed Hash Tables 388 Distributed Hash Tables (DHTs) are an active research area in the P2P 389 community that is highly scalable and offers efficient, low latency 390 search and retrieval of data over an overlay network. These 391 algorithms use a hash function to map a search key to a set of node 392 numbers. Data related to that particular search key are then stored 393 and retrieved from this set of nodes. 395 The search key in the distributed Location Service Protocol would be 396 an Address of Record URI. This URI is effectively a name, and would 397 require resolution to a particular device (URL) or Contact performed 398 in real time. 400 As an example set of functions provided by the P2P protocol is: 402 o Lookup of a key. Returns a set of addresses of peer nodes that 403 store information about the key. 405 o Retrieval of the data from a key node or nodes. 407 o Publishing data to key node or nodes. 409 Chord [9] is an example of a distributed hash lookup primitive. 410 There is an active open source research project 411 (http://www.pdos.lcs.mit.edu/chord/) which provides the first of 412 these functions using Remote Procedure Calls (RPCs). With the 413 addition of the other two functions, complete P2P systems can be 414 constructed. 416 As another example, the CFS (Cooperative File System) [10] is a read- 417 only file system built on top of Chord that utilizes P2P techniques 418 to request the retrieval of data. CFS utilizes load balancing 419 techniques to break stored data into chunks and randomly distribute 420 them across a number of nodes. Chord is used to maintain routing 421 tables identifying which node stores which blocks. The second and 422 third functions are provided by DHash which stores the data reliably 423 in a number of nodes. CFS layers on top a file system that puts the 424 retrieved blocks together as a complete data file. In another 425 example, DDNS [13] is a Chord-based approach for providing DNS 426 lookups. 428 Besides DHTs, there are other classes of P2P algorithms including CAN 429 (Content Addressable Network) [14], Pastry [15], and Tapestry [16], 430 The problem statement for each of these algorithms bears a striking 431 similarity to the P2P discovery and rendezvous capability that would 432 be useful in a SIP P2P network. 434 This body of work should be taken as an input to any IETF Location 435 Service Protocol standardization effort. 437 8. SIP P2P Implementations 439 Some preliminary work [3], [8] has been published on the use of SIP 440 and Chord. However, these SIP approaches propose utilizing SIP as a 441 transport, with all P2P messages tunneled over SIP. These 442 implementations are good demonstrations of the use of DHT algorithms 443 and the use of P2P and SIP, but are not a good starting point for the 444 design of the Location Service Protocol. 446 Specifically, the approach of tunneling P2P messages over a SIP 447 REGISTER request has the following issues: 449 - It is SIP specific. A distributed Location Service Protocol would 450 be of use to more protocols than just SIP, and requiring non-SIP 451 protocols to implement the REGISTER method is not likely to be 452 acceptable. 454 - It is not a logical extension of the REGISTER method. REGISTER is 455 only used in SIP between a UA and a Registrar Server. Redirection of 456 REGISTER requests is uncommon, and likely to be interpreted as an 457 attempt at registration hijacking. To interoperate with non-P2P SIP 458 networks, this would require a Registrar Server to initiate REGISTER 459 requests on behalf of a UA - undesirable for a number of 460 architectural and security reasons. 462 - SIP transport has a high overhead and transactional state cost. 463 For large P2P networks, this is likely to translate into long search 464 delays and overloading of the query network. 466 9. Conclusion 468 This draft has discussed the P2P capabilities of SIP and identified 469 P2P limitations in current SIP usage. An analysis of SIP message 470 routing over the SIP Trapezoid was used to motivate the proposal to 471 standardize a protocol to implement a distributed Location Service. 472 The NAT traversal requirements of this protocol were briefly 473 discussed. Finally, the draft included a brief discussion of the 474 applicability of some SIP P2P approaches and this proposal. 476 10. Acknowledgements 478 I'd like to thank the members of the SIP community for their 479 conversations about P2P SIP including Henry Sinnreich, Henning 480 Schulzrinne, Robert Sparks, Cullen Jennings, Jon Peterson, Adam 481 Roach, Adrian Georgescu, David Bryan, and Philip Matthews. In 482 addition, thanks to the Chord developers especially Emil Sit for 483 their feedback. 485 11. Security Considerations 487 SIP utilization of P2P discovery and rendezvous techniques will 488 introduce a number of new security, identity, and privacy 489 considerations that will need to be solved. As a starting point, 490 general P2P security papers such as [18] should be studied, then 491 considerations specific to the Internet communications application 492 should be applied. 494 12. Informative References 496 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 497 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 498 Session Initiation Protocol", RFC 3261, June 2002. 500 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 501 Notification", RFC 3265, June 2002. 503 [3] Bryan, D. and C. Jennings, "A P2P Approach to SIP Registration 504 and Resource Location", draft-bryan-sipping-p2p-01 (work in 505 progress), July 2005. 507 [4] Matthews, P., "Industrial-Strength P2P SIP", 508 draft-matthews-sipping-p2p-industrial-strength-00 (work in 509 progress), February 2005. 511 [5] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 512 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 513 April 1997. 515 [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic 516 Update", RFC 3007, November 2000. 518 [7] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing 519 over IP (TRIP)", RFC 3219, January 2002. 521 [8] Singh, K. and H. Schulzrinne, "Peer-to-peer Internet Telephony 522 using SIP", Columbia University Technical Report CUCS-044-04, 523 New York, NY October 2004. 525 [9] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H. 526 Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service 527 for Internet Applications", ACM SIGCOMM 2001, San Diego, 528 CA August 2001, pp. 149-160. 530 [10] Dabek, F., Kaashoek, M., Karger, D., Morris, R., and I. Stoica, 531 "Wide-area Cooperative Storage with CFS", Proceedings of the 532 18th SOSP 2001. 534 [11] Dabek, F., Kaashoek, M., Li, J., Morris, R., Robertson, J., and 535 E. Sit, "Designing a DHT for Low Latency and High Throughput", 536 NSDI 2004 March 2004. 538 [12] Rosenberg, J., "Obtaining and Using Globally Routable User 539 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 540 (SIP)", draft-ietf-sip-gruu-06 (work in progress), 541 October 2005. 543 [13] Cox, R., Muthitacharoen, A., and R. Morris, "Serving DNS using 544 a Peer-to-Peer Lookup Service", First International Workshop on 545 Peer-to-Peer Systems (Cambridge, MA, Mar. 2002). 547 [14] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S. 548 Shenker, "A scalable content-addressable network", Proc. ACM 549 SIGCOMM, San Diego, CA August 2001, pp. 161-172. 551 [15] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed 552 object location and routing for large-scale peer-to-peer 553 systems", Proceedings of the 18th IFIP/ACM International 554 Conference on Distributed Systems Platforms (Middleware 555 2001) (Nov. 2001), pp. 329-350. 557 [16] Zhao, B., Kubiatowicz, J., and A. Joseph, "Tapestry: An 558 infrastructure for fault-tolerant wide-area location and 559 routing", Tech. Rep. UCB/CSD-01-1141, Computer Science 560 Division, U. C. Berkeley April 2001. 562 [17] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 563 draft-rosenberg-midcom-turn-08 (work in progress), 564 September 2005. 566 [18] Sit, E. and J. Robertson, "Security Considerations for Peer-to- 567 Peer Distributed Hash Tables", First International Workshop on 568 Peer-to-Peer Systems (IPTPS 02) March 2002; Cambridge, MA. 570 Authors' Addresses 572 Alan Johnston 573 SIPStation 574 St. Louis, MO 63124 576 Email: alan@sipstation.com 578 Henry Sinnreich 579 pulver.com 580 115 Broadhollow Rd 581 Suite 225 582 Melville, NY 11747 584 Email: henry@pulver.com 586 Intellectual Property Statement 588 The IETF takes no position regarding the validity or scope of any 589 Intellectual Property Rights or other rights that might be claimed to 590 pertain to the implementation or use of the technology described in 591 this document or the extent to which any license under such rights 592 might or might not be available; nor does it represent that it has 593 made any independent effort to identify any such rights. Information 594 on the procedures with respect to rights in RFC documents can be 595 found in BCP 78 and BCP 79. 597 Copies of IPR disclosures made to the IETF Secretariat and any 598 assurances of licenses to be made available, or the result of an 599 attempt made to obtain a general license or permission for the use of 600 such proprietary rights by implementers or users of this 601 specification can be obtained from the IETF on-line IPR repository at 602 http://www.ietf.org/ipr. 604 The IETF invites any interested party to bring to its attention any 605 copyrights, patents or patent applications, or other proprietary 606 rights that may cover technology that may be required to implement 607 this standard. Please address the information to the IETF at 608 ietf-ipr@ietf.org. 610 Disclaimer of Validity 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Copyright Statement 622 Copyright (C) The Internet Society (2006). This document is subject 623 to the rights, licenses and restrictions contained in BCP 78, and 624 except as set forth therein, the authors retain all their rights. 626 Acknowledgment 628 Funding for the RFC Editor function is currently provided by the 629 Internet Society.