idnits 2.17.1 draft-matthews-p2psip-id-loc-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. 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 (February 25, 2008) is 5904 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: 'I-D.ietf-mmusic-ice' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-01 -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group E. Cooper 3 Internet-Draft A. Johnston 4 Intended status: Standards Track P. Matthews 5 Expires: August 28, 2008 Avaya 6 February 25, 2008 8 An ID/Locator Architecture for P2PSIP 9 draft-matthews-p2psip-id-loc-01 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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes an architecture where peers in an peer-to- 43 peer overlay use special IP addresses to identify other peers. Two 44 of the advantages of this approach are that (a) most existing 45 applications can run in an overlay without needing any changes and 46 (b) peer mobility and NAT traversal are handled in a way that is 47 transparent to most applications. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview/Example . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. LSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 7 60 4.3. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 9. Appendix: Discussion of Design Choices . . . . . . . . . . . . 12 71 9.1. LSIs have Local Significance . . . . . . . . . . . . . . . 12 73 10. Relationship to HIP . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 Intellectual Property and Copyright Statements . . . . . . . . . . 15 82 1. Introduction 84 This document describes a scheme whereby the applications running on 85 a peer can use a special IP addresses, called "LSIs" (Locally 86 Significant Identifiers), to identify other peers in the peer-to-peer 87 overlay, rather than using real IP addresses or peer IDs. Using 88 these LSIs brings the following advantages: 90 o An LSI is unique, unlike the real IP address of most peers (which 91 is often a private IP address); 93 o An LSI can be used in the Socket API without change, unlike 160- 94 bit peer IDs; 96 o Applications using LSIs do not have to worry about NAT traversal, 97 mobility, or multi-homing, since these are handled by a helper 98 application. 100 The scheme effectively turns the overlay into a VPN. Like other 101 VPNs, it can be implemented so that most applications are unaware 102 that they are using the VPN. Only applications that want to take 103 advantage of the special properties of the overlay need to be aware. 105 Though not discussed further in the document, this scheme can be 106 trivially extended to handle clients as well. 108 This scheme is not a Peer Protocol in itself. Rather, it is an 109 enhancement to a Peer Protocol. 111 This approach can be compared with the approach taken by many of the 112 other proposals in P2PSIP (e.g., RELOAD, ASP, P2PP, and XPP/PCAN). 113 In these proposals, peers are identified with bitstrings that do not 114 look like addresses, forcing applications that want to run in an 115 overlay to use a new (as yet unspecified) API, rather than the 116 existing Socket API. Furthermore, though these proposals handle NAT 117 traversal for the Peer protocol, they do not handle NAT traversal for 118 applications, forcing each application to invent its own ICE 119 variation. None of these proposals currently consider mobility at 120 all. All of this means that any application that wants to run in an 121 overlay requires significant modification. 123 This scheme grew out of the authors' previous efforts to adapt HIP to 124 peer-to-peer overlays. More details on the relationship of this work 125 to HIP is given in Section 10. 127 2. Overview/Example 129 This section gives an overview of how the scheme works. It is non- 130 normative. 132 This overview is in the form of an extended example and assume a 133 particular implementation approach. While not fully general, 134 experience has shown that this is a good way to explain the concepts. 136 Consider a peer-to-peer overlay. This overlay is assigned a domain 137 name by the peer that created it; say it is "example.com". This 138 overlay has a number of peers, of which there are three of interest, 139 called "venus", "earth", and "mars". Each peer in the overlay is 140 assigned a domain name underneith the "example.com" domain; for 141 example "mars.example.com". The domain names of peers are NOT stored 142 in DNS. Instead, each peer stores a mapping between its domain name 143 and its peer ID in the overlay's Distributed Database. 145 The machines Venus and Mars are using popular commercial operating 146 systems. To allow them to join the overlay, a user named Wilma has 147 installed some peer-to-peer software. This software has two parts. 148 One part an implementation of the Peer Protocol with some ID-LOC 149 extensions, the other part is a TAP device driver 150 . This is shown in the 151 following figure. 152 _______________ _________________ 153 | | | Peer Protocol | 154 | Application | | with ID-LOC | 155 |_______________| |_________________| Userspace 156 _______+_________________________+________+_______ ------------- 157 | + | Kernel 158 | TCP/IP stack + | 159 |______________________+___________________________| 160 _______+___________+ __________+______ 161 | | | Ethernet | 162 | TAP Device Driver | | Device Driver | 163 |___________________| |_________________| 164 + 165 + 167 Figure 1 169 The "+" signs show the typical path of an application data packet 170 traveling to/from a remote peer. Packets sent by the application 171 pass down through the kernel's TCP/IP stack. Packets satisfying 172 certain criteria are intercepted by the TAP driver and passed to the 173 Peer Protocol, which modifies them before sending them back down 174 through the kernel's TCP/IP stack and out through the Ethernet device 175 driver. In the reverse direction, incoming packets arrive at the 176 Ethernet device driver and pass up through the TCP/IP stack and are 177 delivered to the Peer Protocol. There they are modified and then 178 passed to the TAP driver which reinjects them into the bottom of the 179 TCP/IP stack. They then pass up through the TCP/IP stack and are 180 delivered to the application. 182 Wilma wishes to view a website on the machine Mars. To do this, she 183 opens a popular web brower and enters "http://mars.example.com" into 184 the address bar. This causes the web browser to do gethostbyname() 185 on "mars.example.com", which in turn causes a DNS query packet to be 186 formed and sent down the TCP/IP stack. It is important to note that 187 this web browser has not been modified in any way, and thus has no 188 knowledge that it is operating in a peer-to-peer overlay. 190 The DNS query packet is intercepted by the TAP driver, which passes 191 it to the Peer Protocol process. The Peer Protocol notices that the 192 domain name is in the "example.com" overlay which Venus is currently 193 a member of. So the Peer Protocol does a Distributed Database query 194 for "mars.example.com" and gets back the 160-bit peer ID of Mars. 196 The Peer Protocol process stores the peer ID of Mars and assigns it 197 an LSI (call it Y). The Peer Protocol process then creates a DNS 198 response packet indicating that "mars.example.com" maps to Y. This 199 packet is passed to the TAP driver, which injects it into the bottom 200 of the TCP/IP stack. 202 The result is that the Wilma's web browser gets back the LSI "Y" as 203 the address of Mars. 205 Wilma's web browser then issues a connect() call to create a TCP 206 connection to "Y". This causes the TCP/IP stack to send a SYN packet 207 with destination "Y". This packet is intercepted by the TAP driver 208 and passed to the Peer Protocol process. 210 The Peer Protocol stores the TCP SYN while it sets up a UDP 211 connection between Venus and Mars. This UDP connection is 212 established using the connection establishment procedures of the peer 213 protocol and uses ICE to traverse any NATs between Venus and Mars. 214 This UDP connection is then uses as a "pipe" to carry all traffic 215 between Venus and Mars encapsulated inside it. 217 This approach is known as the "Outer UDP encapsulation". An 218 alternative approach, known as the "Null encapsulation" is 219 described in the normative text below. 221 ___________ ___________ 222 | | | | 223 | | -------- outer UDP pipe ---------- | | 224 | | | | 225 | Venus | === web browser TCP connection == | Mars | 226 | | ===== other TCP connection ====== | | 227 | | -------- outer UDP pipe ---------- | | 228 |___________| |___________| 230 Once this UDP pipe is established, the Peer Protocol process on Venus 231 then modifies the TCP SYN so that it will travel inside the "UDP 232 pipe" to the machine Mars. By doing this, the web browser and the 233 web server do not need to run ICE or deal with peer IDs. 235 At Mars, the UDP header is removed and the TCP SYN is then passed to 236 the TAP driver on Mars, which passes it up through the TCP/IP stack. 238 Subsequent TCP packets between Venus and Mars are also encapsulated 239 inside UDP and sent along the pipe. 241 3. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in RFC 2119 [RFC2119]. 247 Readers are expected to be familar with [I-D.ietf-p2psip-concepts] 248 and the terms defined there. 250 This document defines the following terms: 252 LSI: An IP address uses to identify a peer in the overlay. 254 Outer UDP Encapsulation An encapsulation scheme for packets 255 travelling between two peers in the overlay that insert a UDP 256 header and a demux header between the IP header and the existing 257 transport header. 259 Null Encapsulation An excapsulation scheme for packets travelling 260 between two peers in the overlay that does not insert any extra 261 headers, but instead modifies fields in the existing IP and 262 transport headers. 264 4. Details 266 Figure X shows the conceptual relationship between the parts 267 discussed in this section. 268 _______________ _______________ 269 | | | 270 | Peer Protocol | SIP | Other Apps ... 271 |_______________|_______________|_________________ 272 | | 273 | TCP, UDP, etc | 274 |_________________________________________________| 275 | | 276 | Shim layer | 277 |_________________________________________________| 278 | | 279 | IP (v4 or v6) | 280 |_________________________________________________| 282 In this architecture, the Peer Protocol is responsible for creating 283 the mapping between LSIs and real addresses, while the Shim layer is 284 responsible for doing the translation on a packet-by-packet basis as 285 well as adding any necessary encapsulation. More details on these 286 roles can be found below. 288 4.1. LSI 290 An LSI is either: 292 o An IPv4 address selected from a range to be allocated by IANA 293 (likely a /16), or 295 o An IPv6 address selected from a range to be determined (perhaps 296 the ORCHID range [RFC4843]). 298 An LSI has local significance only. 300 Applications can freely intermix LSIs with ordinary ("real") 301 addresses. For example, an application can use LSIs to identify 302 nodes in the overlay, and real addresses to identify nodes off the 303 overlay. 305 4.2. Peer Protocol 307 The job of the Peer Protocol in this scheme (in addition to its other 308 duties of managing the overlay and implementing the Distributed 309 Database [I-D.ietf-p2psip-concepts]) is to establish connections 310 between peers and to manage the mappings between LSIs and real 311 addresses. To do this, the Peer Protocol does an ICE exchange with 312 the destination peer to negotiate a set of addresses and ports to use 313 for the data traffic. 315 The stimulus for doing this ICE exchange is an indication from the 316 Shim layer saying that is has no set of real addresses to use for a 317 given destination LSI (cf. an ARP cache miss). The Peer Protocol 318 then does an ICE exchange with the destination peer, routing the 319 Offer/Answer though other peers in the overlay. Once the exchange 320 has completed, the Peer Protocol installs the appropriate mapping 321 entry into the Shim layer. 323 4.3. Shim Layer 325 The shim layer is a new layer introduced between the IP layer and the 326 transport layer. It has two functions: translating LSIs to/from real 327 addresses, and adding any necessary encapsulation. 329 There are two forms of encapsulation: null encapsulation and outer- 330 UDP encapsulation. 331 _____________________________ ___________________________ 332 | | | | 333 | Application data | | Application data | 334 |_____________________________| |___________________________| 335 | | | | 336 | Transport (TCP or UDP only) | | Transport header | 337 |_____________________________| |___________________________| 338 | | | | 339 | Demux header | | IP header (v4 or v6) | 340 |_____________________________| |___________________________| 341 | | 342 | UDP header | Null Encapsulation 343 |_____________________________| 344 | | 345 | IP header (v4 or v6) | 346 |_____________________________| 348 Outer-UDP Encapsulation 350 The Demux header looks like: 351 0 1 2 3 352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Protocol | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Here the protocol field indicates which transport (or other) protocol 358 follows, and uses the same codepoints as used for the 'protocol' 359 field in the IPv4/IPv6 header. 361 The null encapsulation adds no extra bytes but simply translates LSIs 362 to real addresses and modifies port numbers as necessary to traverse 363 NATs. The null encapsulation is very similar to existing protocol 364 stacks, but requires more work to set up and maintain because each 365 connection requires its own set of ICE connectivity checks. 367 By contrast, the Outer-UDP encapsulation adds a UDP header plus a 368 4-byte demux header between the IP header and the transport header. 369 The Outer-UDP encapsulation multiplexes all connections between two 370 given nodes inside a single UDP "pipe". Because intervening NATs see 371 only the outer UDP header, this encapsulation requires only one ICE 372 exchange (to set up the outer pipe), regardless of how many 373 connections there are inside the pipe. 375 The Outer-UDP encapsulation can be used with all transport protocols, 376 while the null encapsulation can only be used with UDP and TCP. 378 To explain the mapping and encapsulations in more detail, consider a 379 transport layer PDU is sent from X:x to Y:y, where X is the LSI of 380 the local host, Y is the LSI of the remote host, and x and y are the 381 port numbers allocated off of these identifiers. For both 382 encapsulations, the Peer Protocol will have used ICE to determine a 383 corresponding set of real addresses and ports. 385 For the null encapsulation, each transport layer 5-tuple (transport 386 protocol,X,x,Y,y) will have a corresponding set of real addresses and 387 ports (X',x',Y',y'). When sending, the port numbers x and y in the 388 transport header are replaced with x' and y', and an IP header is 389 added containing addresses X' and Y' is added. (TBD: Are the 390 addresses in the transport layer pseudo-header also replaced?). The 391 reverse replacement is done when receiving a PDU. 393 If either X or Y change their real address, then an ICE exchange is 394 required to determine a new 5-tuple for each connection. For UDP, 395 this new 5-tuple is simply used in place of the old. 397 OPEN ISSUE: For TCP, this doesn't work, since generating the new 398 5-tuple requires a new TCP handshake. This seems to imply that 399 the TCP layer has to be aware of the change in address. So what 400 do we do? Do we just say "don't use null encapsulation for TCP if 401 you want mobility to work"? Or do we figure out how to make this 402 work? 404 For the outer-UDP encapsulation, there is a single 5-tuple 405 (UDP,X',x',Y',y') for each (X,Y) pair. When sending, the transport 406 header is not modified, instead a demux header and a outer UDP header 407 is added. Ports x' and y' are inserted in the outer UDP header, and 408 an IP header containing addresses X' and Y' is added. 410 Mobility is simpler with the Outer-UDP encapsulation. In this case, 411 only a single ICE exchange is required, and the new 5-tuple is simply 412 used in place of the old. There are no TCP concerns in this case, 413 since the TCP header is never modified. 415 5. Domain Names 417 Each overlay is assigned a domain name by the peer that creates the 418 overlay. This can be any domain name that the peer has authority 419 over. 421 Each peer is assigned a unique domain name underneith the overlay's 422 domain name. This document does not specify how this assignment is 423 done, but one option might be to use the peer's machine name as the 424 label in front of the overlay domain name, and then use some scheme 425 to break ties. 427 Each peer MUST store a mapping between its domain name and its peer 428 ID in the Distributed Database. The peer's domain name MAY be stored 429 in DNS as well. 431 6. Example 433 In this section, we show a SIP call between two UAs in an overlay. 435 This example illustrates how this scheme allows applications to work 436 in an overlay without being aware of that fact. The two SIP UAs in 437 this example use standard client-server SIP to communicate, without 438 needing any SIP extensions. 440 IMPORTANT NOTE: Without extensions to SIP, there is no way to do an 441 AOR to contact URI lookup using the Distributed Database. So in this 442 example, Wilma calls Fred by specifying Fred's machine name, using 443 the domain name scheme described in the previous section. With this 444 caveat, everything works with SIP as it is today. 446 The figure below shows the call flow for this example. 448 Wilma Fred 449 Venus Earth Mars 450 | | | 451 |-- DD query for mars.example.com ---->| | 452 |<--------------- DD response ----------| | 453 | | | 454 |----------- Msg w/ICE Offer ---------->| | 455 | |----- Msg w/ICE Offer ---->| 456 | |<---- Msg w/ICE Ans -------| 457 |<---------- Msg w/ ICE Ans ------------| | 458 | | 459 |<=================== ICE Connectivity Checks =====================>| 460 | | 461 |<-------------------- TCP and TLS handshake ---------------------->| 462 | | 463 |<------------- SIP transaction over TLS connection --------------->| 464 | | 466 This example shows three machines, named "Venus", "Earth", and "Mars" 467 which are part of a larger overlay named "example.com". Wilma is on 468 Venus, and Fred is on Mars. 470 Wilma initiates the call by typing in "sips:fred@mars.example.com" 471 into her UA. Wilma's UA does a gethostbyname() call to resolve 472 "mars.example.com" and this is resolved by doing a Distributed 473 Database lookup. In this example, it turns out that the 474 corresponding resource record is stored on the machine "Earth". As a 475 result, an LSI for the peer Mars is returned from the gethostbyname() 476 call to Wilma's UA. 478 NOTE: The Peer Protocol allocates an LSI and remembers that it 479 maps to the machine named "mars.solar-system.p2p" which has the 480 peer id learned from the response. 482 Wilma's UA then issues a connect() to this LSI. This causes TCP to 483 send a SYN to this LSI. Since there is currently no direct 484 connection between Venus and Mars, the Shim layer finds no mapping 485 for this LSI and thus generates an indication to the Peer Protocol. 487 The Peer Protocol layer on Venus now does an ICE offer/answer 488 exchange with the Peer Protocol layer on Mars. The Offer is sent on 489 the existing connection to Earth, which forwards it to Mars, and the 490 Answer is returned in the same way. ICE connectivity checks are then 491 done, and the result is a tuple of real addresses and ports for the 492 connection. 494 If null encapsulation is used, then the TCP connection was 495 established as part of the ICE connectivity checks. This new 496 connection is used only for SIP signaling, and subsequent connections 497 require a new offer/answer exchange. 499 But if Outer-UDP encapsulation is used, then all the ICE connectivity 500 checks do is establish a UDP "pipe" between the two peers, and the 501 TCP and TLS handshakes must still be done inside that pipe (as shown 502 above). However, this UDP pipe can be used for all traffic between 503 Venus and Mars, including subsequent RTP packets) without the need of 504 subsequent offer/answer exchanges. 506 7. IANA Considerations 508 TBD. 510 8. Security Considerations 512 TBD. 514 9. Appendix: Discussion of Design Choices 516 This appendix discusses the thinking around some of the design 517 choices made. 519 9.1. LSIs have Local Significance 521 In the design presented here, the LSIs presented to applications have 522 local significance only. For IPv4, this seems to be the only 523 reasonable choice, as it would be difficult to get an IPv4 block of 524 addresses large enough to be of wider significance. However, for 525 IPv6, a wider scope would be possible, and that option was 526 considered. In particular, it would have been possible to use a 527 globally scoped identifier, like the HIT of HIP. At first blush, it 528 seems that using a globally scoped identifier would allow an 529 applications to send the identifier (embedded in protocol messages) 530 to an application on other nodes and have that identifier make sense. 532 However, an examination of the details shows that there are problems 533 with this approach. Say a node X has an indentifier for node Z 534 (e.g., a HIT) and sends its to node Y. For Y to be able to use this 535 identifier, it must know how to establish a connection with node Z. 536 If node Y is in multiple overlays, then Y has no idea which overlay 537 to search to find node Z. It is this difficulty that led us to the 538 decision to make LSI have local significance only. 540 10. Relationship to HIP 542 The fundamental concept in this document, that of an identifier for a 543 node which is distinct from the node's real addresses, has been 544 adopted from HIP. In HIP, this identifier (known as a HIT 545 [I-D.ietf-hip-base]) is always an IPv6 identifier, and has global 546 scope and cryptographic properties, making it computationally hard 547 for an second node to steal a node's identity. (Current HIP 548 implementations also implement an IPv4 identifier as a local 549 identifier, but the properties of this IPv4 identifier are not 550 currently specified anywhere). 552 11. References 554 11.1. Normative References 556 [I-D.ietf-mmusic-ice] 557 Rosenberg, J., "Interactive Connectivity Establishment 558 (ICE): A Protocol for Network Address Translator (NAT) 559 Traversal for Offer/Answer Protocols", 560 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 11.2. Informative References 567 [I-D.ietf-hip-base] 568 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 569 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 570 progress), October 2007. 572 [I-D.ietf-p2psip-concepts] 573 Bryan, D., Matthews, P., Shim, E., and D. Willis, 574 "Concepts and Terminology for Peer to Peer SIP", 575 draft-ietf-p2psip-concepts-01 (work in progress), 576 November 2007. 578 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 579 for Overlay Routable Cryptographic Hash Identifiers 580 (ORCHID)", RFC 4843, April 2007. 582 Authors' Addresses 584 Eric Cooper 585 Avaya 586 1135 Innovation Drive 587 Ottawa, Ontario K2K 3G7 588 Canada 590 Phone: +1 613 592 4343 x228 591 Email: ecooper@avaya.com 593 Alan Johnston 594 Avaya 595 St. Louis, MO 63124 596 USA 598 Email: alan@sipstation.com 600 Philip Matthews 601 Avaya 602 100 Innovation Drive 603 Ottawa, Ontario K2K 3G7 604 Canada 606 Phone: +1 613 592 4343 x224 607 Email: philip_matthews@magma.ca 609 Full Copyright Statement 611 Copyright (C) The IETF Trust (2008). 613 This document is subject to the rights, licenses and restrictions 614 contained in BCP 78, and except as set forth therein, the authors 615 retain all their rights. 617 This document and the information contained herein are provided on an 618 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 619 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 620 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 621 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 622 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Intellectual Property 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the procedures with respect to rights in RFC documents can be 634 found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 Acknowledgment 651 Funding for the RFC Editor function is provided by the IETF 652 Administrative Support Activity (IASA).