idnits 2.17.1 draft-eggert-hiprg-rr-prob-desc-00.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 10) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (October 18, 2004) is 7102 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) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-stiemerling-hip-nat-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '11') (Obsoleted by RFC 4941) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Host Identity Protocol (HIP) L. Eggert 2 Research Group NEC 3 Internet-Draft J. Laganier 4 Expires: April 18, 2005 LIP / Sun Microsystems 5 October 18, 2004 7 HIP Resolution and Rendezvous Problem Description 8 draft-eggert-hiprg-rr-prob-desc-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. This document may not be modified, and derivative works of 18 it may not be created, except to publish it as an RFC and to 19 translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document investigates the design space for resolution and 46 rendezvous mechanisms for the Host Identity Protocol (HIP.) It 47 identifies and describes specific issues that HIP resolution and 48 rendezvous mechanisms should address. These issues include 49 dependencies on the DNS, lack of support for direct communication 50 based on host identities, lack of a reverse lookup mechanism for host 51 identities, and DNS and node rendezvous. 53 This document does not propose specific resolution and rendezvous 54 mechanisms. Different alternative solutions will be described and 55 discussed in companion documents. These documents should analyze if 56 and to what degree the specific proposals they present address the 57 issues identified here. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. HIP Resolution and Rendezvous . . . . . . . . . . . . . . . . 4 63 2.1 Issue 1: DNS Dependency . . . . . . . . . . . . . . . . . 5 64 2.2 Issue 2: Direct Communication . . . . . . . . . . . . . . 6 65 2.3 Issue 3: Reverse Lookup . . . . . . . . . . . . . . . . . 6 66 2.4 Issue 4: DNS Rendezvous . . . . . . . . . . . . . . . . . 6 67 2.5 Issue 5: Node Rendezvous . . . . . . . . . . . . . . . . . 7 68 2.5.1 Issue 5.1: Middlebox Traversal . . . . . . . . . . . . 7 69 2.5.2 Issue 5.2: Location Privacy . . . . . . . . . . . . . 7 70 2.5.3 Issue 5.3: Mobility and Multihoming . . . . . . . . . 8 71 2.5.4 Issue 5.4: Interoperation with Legacy Nodes . . . . . 8 72 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 77 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 78 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 80 A. Document Revision History . . . . . . . . . . . . . . . . . . 11 81 Intellectual Property and Copyright Statements . . . . . . . . 12 83 1. Introduction 85 The current Internet uses two global namespaces: domain names and IP 86 addresses. The first namespace - domain names - has a single use. 87 Domain names, usually simply called names, are symbolic identifiers 88 for sets of numeric IP addresses, chosen for their mnemonic 89 properties: humans need to interact with them. 91 IP addresses form the Internet's second global namespace. They have 92 two uses. First, they are topological locators for network 93 attachment points, addressing a specific location in the network 94 topology. Their second use is as identifiers for the network 95 interfaces - and thus nodes - that attach to the addressed locations. 96 In this role as identifiers, IP addresses loose their topological 97 meaning and become simple names. Routing and other network-layer 98 mechanisms use the locator aspects of IP addresses. Transport-layer 99 protocols and mechanisms typically use IP addresses in their role as 100 names for communication endpoints. (Saltzer [6] discusses these 101 naming concepts in detail.) 103 This dual use of IP addresses as both names and locators limits the 104 flexibility of the Internet architecture. For example, the use of 105 topology-dependent IP addresses as symbolic names for communication 106 endpoints complicates node mobility. A mobile node changes its 107 points of network attachment and hence its IP addresses dynamically. 108 At the transport layer, this causes the logical endpoints of 109 communication sessions - which are based on IP addresses - to change 110 dynamically as well. Many of the Internet's transport protocols do 111 not support changing the logical endpoints of established 112 communication sessions. Arguably, they should not, because the 113 identities of the communicating nodes have not changed, simply their 114 points of network attachment. 116 The Host Identity Protocol (HIP) architecture defines a third global 117 namespace [1]. The new host identity namespace decouples the name 118 and locator roles currently filled by IP addresses. Host identities 119 take over the naming role, while IP addresses become pure locators. 120 With HIP, transport-layer mechanisms operate on host identities 121 instead of using IP addresses as endpoint names. Network-layer 122 mechanisms continue to use IP addresses as pure locators. 124 Due to the introduction of a new global namespace, HIP also affects 125 the Internet's name resolution services. The Domain Name System 126 (DNS) is currently the Internet's only global resolution service [7]. 127 The DNS provides a two-way lookup service between domain names and 128 their set of corresponding IP addresses. HIP requires an additional 129 resolution step. Domain names now map into sets of host identities, 130 which in turn map into sets of IP addresses. 132 The additional HIP resolution step complicates the rendezvous 133 procedure by which two nodes establish communication, i.e., the steps 134 they need to perform until they obtain a peer's IP addresses. In the 135 current Internet, the DNS maps the domain name of a target remote 136 node directly into its set of IP addresses, which the local node may 137 then use to address packets. The address of each node's DNS server 138 is either manually configured or dynamically discovered (e.g., using 139 DHCP [8]). When no DNS server is configured or has been discovered, 140 nodes can still communicate by using IP addresses directly. 142 With HIP, the rendezvous procedure and resolution mechanisms are 143 becoming more complex. The various alternatives for performing name 144 and identity resolutions lead to rendezvous procedures that offer 145 significantly different characteristics. This document discusses the 146 limitations of the current HIP architecture and describes the general 147 design space for alternative resolution and rendezvous mechanisms. 148 It does not, however, present any specific resolution and rendezvous 149 mechanisms. Specific alternatives will be described and discussed in 150 companion documents. 152 This problem description document and its companion documents that 153 describe specific resolution and rendezvous approaches obsolete prior 154 contributions, i.e., [9]. 156 2. HIP Resolution and Rendezvous 158 As mentioned in Section 1, HIP complicates the Internet's simple 159 resolution and rendezvous procedures. Currently, nodes use DNS 160 servers at well-known IP addresses to resolve domain names into IP 161 addresses, which they can then use to address packets. The top 162 illustration in Figure 1 shows this DNS resolution procedure. It 163 also shows the reverse DNS resolution, which resolves an IP address 164 back into its associated domain name. 166 With HIP, domain names map into sets of host identities, each of 167 which maps into sets of IP addresses. This results in a logical 168 two-step resolution process before a node knows the IP addresses 169 associated with target domain name. The middle illustration in 170 Figure 1 shows this two-step process. To maintain application 171 compatibility, the first mapping - from names into host identities - 172 should remain in the DNS. For the second mapping - from host 173 identities into IP addresses - various alternatives are possible. 174 Logically, this HIP lookup is a completely separate operation from 175 the initial DNS lookup. A reverse HIP lookup is also useful; it maps 176 IP addresses back into their associated host identities. 178 +--------+ DNS lookup +---------+ 179 | domain |------------------------------------------->| IP | 180 | name |<-------------------------------------------| address | 181 +--------+ reverse DNS lookup +---------+ 183 +--------+ DNS lookup +----------+ HIP lookup +---------+ 184 | domain |--------------->| host |--------------->| IP | 185 | name |<---------------| identity |<---------------| address | 186 +--------+ reverse DNS +----------+ reverse HIP +---------+ 187 lookup lookup 189 +--------+ DNS lookup +--------------------+ 190 | domain |-------------------------------->| host | IP | 191 | name |<--------------------------+ | identity | address | 192 +--------+ reverse DNS lookup | +--------------------+ 193 | | 194 +---------------------+ 196 Figure 1: Domain name resolution without HIP (top), logical lookups 197 with HIP (middle) and with the current HIP architecture (bottom) 199 Current HIP prototypes choose to maintain the second mapping between 200 host identities and IP addresses in the DNS as well. One proposal 201 simply stores a node's host identities alongside its IP addresses in 202 the node's DNS record [2]. A DNS resolution of a domain name thus 203 returns a pair of host identities and IP addresses, as shown in the 204 bottom illustration of Figure 1. This simplistic approach creates 205 several problems that the following sections discuss in more detail. 207 Companion documents to this document that propose specific mechanisms 208 for resolution and rendezvous should investigate if and to what 209 degree the individual proposals address these issues. [Comment.1] 211 2.1 Issue 1: DNS Dependency 213 One critical problem of storing host identities in a node's DNS 214 record, as shown in the bottom of Figure 1, is that this approach 215 creates a dependency between HIP and the DNS. To communicate with 216 HIP under this approach, DNS resolution of a domain name is required 217 to obtain a peer's host identities and IP addresses. It is not 218 possible to communicate with HIP based on host identities alone - no 219 direct resolution mechanism exists to map host identities into IP 220 addresses. 222 This is a drastic change from the current Internet, where the DNS is 223 an optional component and communication can occur based on IP 224 addresses alone. 226 2.2 Issue 2: Direct Communication 228 Storing host identities in a node's DNS record causes a second, 229 related issue: even if a node already knows the host identity of a 230 peer, it cannot use this host identity to initiate communication. It 231 needs to know and resolve the peer's domain name to obtain the peer's 232 IP addresses. 234 HIP allows protocols and services above the network layer to use host 235 identities instead of IP-address-based names. Consequently, with 236 HIP, host identities should replace many uses of IP addresses above 237 the network layer. For example, applications and users should be 238 able to substitute host identities wherever they now use IP 239 addresses. A direct mechanism to resolve host identities into IP 240 addresses, i.e., one that does not depend on knowledge of the 241 corresponding domain name, is required to enable this transparency. 243 (Communication based on IP addresses alone is still possible with the 244 simplistic HIP lookup, as shown on the bottom of Figure 1, but 245 obviously will not incur the benefits of using HIP.) 247 2.3 Issue 3: Reverse Lookup 249 A third problem with the simplistic HIP resolution shown in the 250 bottom of Figure 1 is that the DNS currently provides no mechanism to 251 perform a reverse HIP lookup, i.e., determine the domain name of a 252 node based on its host identity. Only the traditional reverse DNS 253 lookup exists, which operates on IP addresses, not host identities. 254 A reverse HIP lookup would need to be emulated by performing a 255 reverse lookup on an IP address, and a forward DNS lookup on the 256 resulting name to obtain the host identities. This is cumbersome. 258 Alternatively, reverse lookup capability could be added to the DNS 259 through a new root, similar to how it provides reverse lookups on IP 260 addresses. This approach, however, is problematic, because it maps 261 resolution of a flat namespace into an hierarchical name system and 262 also creates additional dependencies between HIP and the DNS [2]. 264 2.4 Issue 4: DNS Rendezvous 266 Rendezvous with the DNS infrastructure is another issue with the 267 simplistic HIP lookup. It may be useful to communicate with DNS 268 servers using HIP instead of IP, i.e., access a DNS server through 269 its well-known host identity instead of its well-known IP address. 270 This would enable DNS servers to benefit from HIP's mobility, 271 multihoming and security mechanisms. 273 The simplistic HIP lookup (bottom of Figure 1) requires a deployed 274 DNS infrastructure. 276 2.5 Issue 5: Node Rendezvous 278 Arguably the largest issue with the current HIP approach of using the 279 DNS to store both the host identities and IP addresses associated 280 with a name is rendezvous between nodes. As mentioned before, the 281 rendezvous procedure encompasses all required steps for two nodes to 282 obtain enough information about the other peer to be able to address 283 packets to it. In most cases, this involves determining the set of a 284 peer's IP addresses. 286 Without HIP, node rendezvous involves a DNS lookup of a peer's domain 287 name to obtain its IP addresses. If the peer's addresses are known 288 already, a host may skip the rendezvous procedure and address packets 289 to it directly. 291 Consequently, different resolution mechanisms can have significantly 292 different effects on node rendezvous. The following sections 293 describe specific issues in detail. 295 2.5.1 Issue 5.1: Middlebox Traversal 297 A different document discusses middlebox traversal of HIP traffic 298 [3], focusing on the current specification of the HIP protocols. 299 This document discusses two separate problems: middlebox traversal of 300 the HIP base exchange - i.e., the current rendezvous procedure - and 301 traversal of HIP data traffic, which is currently carried inside 302 IPsec. 304 New resolution and rendezvous solutions, which may consequently 305 change the current base exchange, must consider how they interact 306 with various middleboxes [10]. 308 2.5.2 Issue 5.2: Location Privacy 310 Internet users are becoming more sensitive to privacy concerns. For 311 example, the introduction of IPv6 already caused concern because of 312 the possibility to trace users based on the unique EUI48 NIC 313 identifiers included in their global IPv6 addresses. HIP may 314 potentially worsen the situation through its use of cryptographic, 315 semi-permanent identifiers. 317 One approach to mitigating these concerns is through the periodic 318 regeneration of host identities. Instead of reusing the same 319 identity, nodes will generate new identities on the fly, similar to 320 RFC 3041 [11]. This approach makes it more difficult to correlate a 321 node's HIP associations and may thus reduce traceability concerns. A 322 second approach to increasing location privacy is concealing the IP 323 addresses of two communicating nodes from one another. The 324 SPI-multiplexed NAT (SPINAT) described as part of the BLIND framework 325 offers this ability [12]. 327 New resolution and rendezvous solutions should consider if and how 328 they may provide location privacy or integrate with other mechanisms 329 that do. 331 2.5.3 Issue 5.3: Mobility and Multihoming 333 HIP already includes mechanisms that allow a peer to signal its peers 334 when its IP addresses have changed [4]. These mechanisms, however, 335 require an already-established HIP association. For establishing new 336 HIP associations after a move, the regular rendezvous procedure must 337 complete. Consequently, a node must update its IP addresses after a 338 move in whatever mechanism provides rendezvous service. 340 When host identities and IP addresses are stored in the DNS, dynamic 341 DNS may provide a simple update mechanism [13][14]. However, the 342 caching mechanisms of the DNS and to a lesser degree implementation 343 issues with some current DNS servers make frequent dynamic DNS 344 updates, i.e., support for highly mobile nodes, problematic. 346 A two-step resolution procedure, as described in Section 2 or 347 dedicated external rendezvous servers [5] can improve HIP operation 348 in such cases by offering a range of different update/lookup 349 operations with different performance trade-offs. 351 One drawback of rendezvous servers is that they may introduce 352 triangle routing: packets no longer follow the direct path between 353 two peers, but instead flow through the rendezvous server. Besides 354 increasing the end-to-end latency, this may decrease communication 355 reliability. The two step resolution process, however, may be unable 356 to support very high-rate mobility due to caching - it is impractical 357 to translate from host identity to current IP address for every 358 single packet. 360 New resolution and rendezvous solutions should discuss the trade-offs 361 between update and lookup performance and routing inefficiencies 362 versus move frequency. 364 2.5.4 Issue 5.4: Interoperation with Legacy Nodes 366 With HIP, node rendezvous breaks down into two distinct cases: 367 rendezvous between two HIP nodes and rendezvous between a HIP node 368 and a legacy non-HIP node. Specific resolution mechanisms for host 369 identities may affect the two rendezvous cases in different ways. 371 For example, the current rendezvous server extensions to the base HIP 372 protocol [5] do not support communication with legacy nodes, because 373 they store the addresses of rendezvous servers in new "RVS" DNS 374 record types that legacy nodes do not support [2]. For communication 375 between two HIP nodes, this approach is successful, because they can 376 use the RVS records to establish communication with the peer. A 377 legacy node, however, expects to receive A or AAAA records that 378 contain IP addresses the peer is directly reachable at. 380 New resolution and rendezvous solutions for HIP nodes should consider 381 how they may provide rendezvous functionality with legacy non-HIP 382 nodes. There are two aspects to this question. First, whether 383 resolution mechanisms allow rendezvous with non-HIP nodes at all, and 384 second, whether they can offer some of the benefits of HIP 385 communication to non-HIP nodes as well. 387 3. Conclusion 389 This document described the design space of HIP resolution and 390 rendezvous mechanisms and described a number of issues that the 391 current architecture fails to support adequately. These issues 392 include dependencies on the DNS, lack of support for direct 393 communication based on host identities, lack of a reverse lookup 394 mechanism for host identities, and DNS and node rendezvous. 396 This document does not propose specific resolution and rendezvous 397 solutions; this will occur in future companion documents that should 398 also describe how the solutions they propose address the issues 399 identified here. 401 4. Security Considerations 403 The security aspects of HIP resolution and rendezvous mechanisms are 404 currently being investigated and will be included in a future 405 revision of this document. 407 5. Acknowledgments 409 Part of this work is a product of the Ambient Networks project, 410 partially supported by the European Commission under its Sixth 411 Framework Programme. It is provided "as is" and without any express 412 or implied warranties, including, without limitation, the implied 413 warranties of fitness for a particular purpose. The views and 414 conclusions contained herein are those of the authors and should not 415 be interpreted as necessarily representing the official policies or 416 endorsements, either expressed or implied, of the Ambient Networks 417 project or the European Commission. 419 6. References 421 6.1 Normative References 423 [1] Moskowitz, R., "Host Identity Protocol Architecture", 424 draft-moskowitz-hip-arch-06 (work in progress), June 2004. 426 [2] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 427 Domain Name System (DNS) Extensions", draft-nikander-hip-dns-00 428 (work in progress), July 2004. 430 [3] Stiemerling, M., "Problem Statement: HIP operation over Network 431 Address Translators", draft-stiemerling-hip-nat-01 (work in 432 progress), July 2004. 434 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 435 Identity Protocol", draft-nikander-hip-mm-02 (work in progress), 436 July 2004. 438 [5] Eggert, L., "Host Identity Protocol (HIP) Rendezvous 439 Extensions", draft-eggert-hip-rvs-00 (work in progress), July 440 2004. 442 6.2 Informative References 444 [6] Saltzer, J., "On the Naming and Binding of Network 445 Destinations", RFC 1498, August 1993. 447 [7] Mockapetris, P., "Domain names - concepts and facilities", STD 448 13, RFC 1034, November 1987. 450 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 451 March 1997. 453 [9] Eggert, L., "Host Identity Protocol (HIP) Rendezvous 454 Mechanisms", draft-eggert-hip-rendezvous-01 (work in progress), 455 July 2004. 457 [10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 458 RFC 3234, February 2002. 460 [11] Narten, T. and R. Draves, "Privacy Extensions for Stateless 461 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 463 [12] Ylitalo, J. and P. Nikander, "BLIND: A Complete Identity 464 Protection Framework for End-points", Proc. Twelfth 465 International Workshop on Security Protocols, Cambridge, 466 England, April 2004. 468 [13] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 469 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 470 April 1997. 472 [14] Wellington, B., "Secure Domain Name System (DNS) Dynamic 473 Update", RFC 3007, November 2000. 475 Editorial Comments 477 [Comment.1] LE: The authors would appreciate feedback on the list of 478 issues; specifically, whether it is complete and whether 479 all of the currently identified issues are valid. 481 Authors' Addresses 483 Lars Eggert 484 NEC Network Laboratories 485 Kurfuerstenanlage 36 486 Heidelberg 69115 487 Germany 489 Phone: +49 6221 90511 43 490 Fax: +49 6221 90511 55 491 EMail: lars.eggert@netlab.nec.de 492 URI: http://www.netlab.nec.de/ 494 Julien Laganier 495 Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) 496 180, Avenue de l'Europe 497 Saint Ismier CEDEX 38334 498 France 500 Phone: +33 476 188 815 501 EMail: ju@sun.com 502 URI: http://research.sun.com/ 504 Appendix A. Document Revision History 506 +-----------+-------------------------------------------------------+ 507 | Revision | Comments | 508 +-----------+-------------------------------------------------------+ 509 | 00 | Initial version. This document and its future | 510 | | companion documents that will propose and analyze | 511 | | specific solutions obsolete prior contributions [9]. | 512 +-----------+-------------------------------------------------------+ 514 Intellectual Property Statement 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed to 518 pertain to the implementation or use of the technology described in 519 this document or the extent to which any license under such rights 520 might or might not be available; nor does it represent that it has 521 made any independent effort to identify any such rights. Information 522 on the procedures with respect to rights in RFC documents can be 523 found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use of 528 such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository at 530 http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights that may cover technology that may be required to implement 535 this standard. Please address the information to the IETF at 536 ietf-ipr@ietf.org. 538 Disclaimer of Validity 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 Copyright Statement 550 Copyright (C) The Internet Society (2004). This document is subject 551 to the rights, licenses and restrictions contained in BCP 78, and 552 except as set forth therein, the authors retain all their rights. 554 Acknowledgment 556 Funding for the RFC Editor function is currently provided by the 557 Internet Society.