idnits 2.17.1 draft-ietf-hip-registration-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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 543. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 20, 2005) is 6791 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) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-03 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: March 24, 2006 T. Koponen 5 HIIT 6 L. Eggert 7 NEC 8 September 20, 2005 10 Host Identity Protocol (HIP) Registration Extension 11 draft-ietf-hip-registration-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 24, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document specifies a registration mechanism for the Host 45 Identity Protocol (HIP) that allows hosts to register with services, 46 such as HIP rendezvous servers or middleboxes. 48 1. Introduction 50 This document specifies an extension to the Host Identity Protocol 51 (HIP) [I-D.ietf-hip-arch]. The extension provides a generic means 52 for a host to register with a service. The service may, for example, 53 be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox 54 [RFC3234]. 56 This document makes no further assumptions about the exact type of 57 service. Likewise, this document does not specify any mechanisms to 58 discover the presence of specific services or means to interact with 59 them after registration. Future documents may describe those 60 operations. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 2. Terminology 68 This section defines terminology that is used throughout the 69 remainder of this document. Please note that terminology shared with 70 other documents is defined elsewhere [I-D.ietf-hip-arch]. 72 Requester: 73 a HIP node registering with a HIP registrar to request 74 registration for a service. 76 Registrar: 77 a HIP node offering registration for one or more services. 79 Service: 80 a facility that provides requesters with new capabilities or 81 functionalities operating at the HIP layer. Examples include 82 firewalls that support HIP traversal or HIP rendezvous servers. 84 Registration: 85 shared state stored by a requester and a registrar, allowing the 86 requester to benefit from one or more HIP services offered by the 87 registrar. Each registration has an associated finite lifetime. 88 Requesters can extend established registrations through re- 89 registration (i.e., perform a refresh). 91 Registration Type: 92 an identifier for a given service in the registration protocol. 93 For example, the rendezvous service is identified by a specific 94 registration type. 96 3. HIP Registration Extension Overview 98 This document does not specify the means by which a requester 99 discovers the availability of a service, or how a requester locates a 100 registrar. After a requester has discovered a registrar, it either 101 initiates HIP base exchange or uses an existing HIP association with 102 the registrar. In both cases, registrars use additional parameters 103 that the remainder of this document defines to announce their quality 104 and grant or refuse registration. Requesters use corresponding 105 parameters to register with the service. The following sections 106 describe the differences between this registration handshake and the 107 standard HIP base exchange [I-D.ietf-hip-base] . 109 3.1 Registrar Announcing its Ability 111 A host that is capable and willing to act as a registrar SHOULD 112 include a REG_INFO parameter in the R1 packets it sends during all 113 base exchanges. If it is currently unable to provide services due to 114 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 115 with no services listed. If services can be provided later, it 116 SHOULD send UPDATE packets indicating the current set of services 117 available in a new REG_INFO parameter to all hosts it is associated 118 with. 120 3.2 Requester Requesting Registration 122 To request registration with a service, a requester constructs and 123 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 124 packet it sends to the registrar. 126 If the requester has no HIP association established with the 127 registrar, it SHOULD already send the REG_REQUEST in the I2 packet. 128 This minimizes the number of packets that need to be exchanged with 129 the registrar. A registrar MAY end a HIP association that does not 130 carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED 131 in the R2. In this case, no HIP association is created between the 132 hosts. The REG_REQUIRED notification error type is TBD. 134 3.3 Registrar Granting or Refusing Service(s) Registration 136 Once registration has been requested, the registrar is able to 137 authenticate the requester based on the host identity included in I2. 138 It then verifies the host identity is authorized to register with the 139 requested service(s), based on local policies. The details of this 140 authorization procedure depend on the type of requested service(s) 141 and on the local policies of the registrar, and are therefore not 142 further specified in this document. 144 After authorization, the registrar includes in its response (i.e., an 145 R2 or an UPDATE, respectively, depending on whether the registration 146 was requested during the base exchange, or using an existing 147 association) a REG_RESPONSE parameter containing the service(s) 148 type(s) for which it has authorized registration, and zero or more 149 REG_FAILED parameter containing the service(s) type(s) for which it 150 has not authorized registration or registration has failed for other 151 reasons. In particular, REG_FAILED with a failure type of zero 152 indicates the service(s) type(s) that require further credentials for 153 registration. 155 If the registrar requires further authorization and the requester has 156 additional credentials available, the requester SHOULD try to again 157 register with the service after the HIP association has been 158 established. 160 Successful processing of a REG_RESPONSE parameter creates 161 registration state at the requester. In a similar manner, successful 162 processing of a REG_REQUEST parameter creates registration state at 163 the registrar and possibly at the service. Both the requester and 164 registrar can cancel a registration before it expires, if the 165 services afforded by a registration are no longer needed by the 166 requester, or cannot be provided any longer by the registrar (for 167 instance, because its configuration has changed). 169 +-----+ I1 +-----+-----+ 170 | |--------------------->| | S1 | 171 | |<---------------------| | | 172 | | R1(REG_INFO:S1,S2) | +-----+ 173 | RQ | | R | S2 | 174 | | I2(REG_REQ:S1) | | | 175 | |--------------------->| +-----+ 176 | |<---------------------| | S3 | 177 | | R2(REG_RESP:S1) | | | 178 +-----+ +-----+-----+ 180 +-----+ +-----+-----+ 181 | | UPDATE(REG_INFO:S) | | | 182 | |<---------------------| | | 183 | RQ |--------------------->| R | S | 184 | | UPDATE(REG_REQ:S) | | | 185 | | UPDATE(REG_RESP:S) | | | 186 | |<---------------------| | | 187 +-----+ +-----+-----+ 189 4. Parameter Formats and Processing 191 This section describes the format and processing of the new 192 parameters introduced by the HIP registration extension. 194 4.1 Encoding Registration Lifetimes with Exponents 196 The HIP registration uses an exponential encoding of registration 197 lifetimes. This allows compact encoding of 255 different lifetime 198 values ranging from 4 ms to 178 days into an 8-bit integer field. 199 The lifetime exponent field used throughout this document MUST be 200 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 201 seconds. 203 4.2 REG_INFO 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Reg Type #3 | | 213 +-+-+-+-+-+-+-+-+ Padding + 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Type [ TBD by IANA (930) ] 218 Length Length in octets, excluding Type, Length, and Padding. 219 Min Lifetime Minimum registration lifetime. 220 Max Lifetime Maximum registration lifetime. 221 Reg Type The registration types offered by the registrar. 223 Other documents will define specific values for registration types. 225 Reg Type Service 226 -------- ------- 227 0-200 Reserved by IANA 228 201-255 Reserved by IANA for private use 230 Registrars include the parameter in R1 packets in order to announce 231 their registration capabilities. The registrar SHOULD include the 232 parameter in UPDATE packets when its service offering has changed. 233 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 235 4.3 REG_REQUEST 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Lifetime | Reg Type #1 | Reg Type #2 | Padding | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Type [ TBD by IANA (932) ] 246 Length Length in octets, excluding Type, Length, and Padding. 247 Lifetime Requested registration lifetime. 248 Reg Type The preferred registration types in order of preference. 250 Other documents will define specific values for registration types. 252 Reg Type Service 253 -------- ------- 254 0-200 Reserved by IANA 255 201-255 Reserved by IANA for private use 257 A requester includes the REG_REQUEST parameter in I2 or UPDATE 258 packets to register with a registrar's service(s). If the 259 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 260 modify the registrations of registration types which are not listed 261 in the parameter. Moreover, the requester MUST NOT include the 262 parameter unless the registrar's R1 packet or latest received UPDATE 263 packet has contained a REG_INFO parameter with the requested 264 registration types. 266 The requester MUST NOT include more than one REG_REQUEST parameter in 267 its I2 or UPDATE packets, while the registrar MUST be able to process 268 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 270 When the registrar is requested a registration which lifetime is 271 either smaller or greater than the minimum or maximum lifetime, 272 respectively, then it SHOULD grant the registration for the minimum 273 or maximum lifetime, respectively. 275 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 276 packets. 278 4.4 REG_RESPONSE 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Lifetime | Reg Type #1 | Reg Type #2 | Padding | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Type [ TBD by IANA (934) ] 289 Length Length in octets, excluding Type, Length, and Padding. 290 Lifetime Granted registration lifetime. 291 Reg Type The granted registration types in order of preference. 293 Other documents will define specific values for registration types. 295 Reg Type Service 296 -------- ------- 297 0-200 Reserved by IANA 298 201-255 Reserved by IANA for private use 300 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 301 UPDATE packet only if a registration has successfully completed. 303 The registrar MUST NOT include more than one REG_RESPONSE parameter 304 in its R2 or UPDATE packets, while the requester MUST be able to 305 process one or more REG_RESPONSE parameters in received R2 or UPDATE 306 packets. 308 The requester MUST be prepared to receive any registration lifetime, 309 included ones beyond the minimum and maximum lifetime indicated in 310 the REG_INFO parameter. It MUST NOT expect that the returned 311 lifetime will be the requested one, even in the case that the 312 requested lifetime falls within the announced minimum and maximum. 314 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 315 packets. 317 4.5 REG_FAILED 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Failure Type | Reg Type #1 | Reg Type #n | Padding | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type [ TBD by IANA (936) ] 328 Length Length in octets, excluding Type, Length, and Padding. 329 Failure Type Reason for failure. 330 Reg Type The registration types that failed with the specified 331 reason. 333 Other documents will define specific values for registration types. 335 Reg Type Service 336 -------- ------- 337 0-200 Reserved by IANA 338 201-255 Reserved by IANA for private use 340 Failure Type Reason 341 ------------ -------------------------------------------- 342 0 Registration requires additional credentials 343 1 Registration type unavailable 344 2-200 Reserved by IANA 345 201-255 Reserved by IANA for private use 347 A failure type of zero means a registrar requires additional 348 credentials to authorize a requester to register with the 349 registration types listed in the parameter. Other failure types than 350 zero have not been defined. 352 The registrar SHOULD include the REG_FAILED parameter in its R2 or 353 UPDATE packet, if registration with the registration types listed has 354 not completed successfully and a requester is asked to try again with 355 additional credentials. 357 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 358 packets. 360 5. Establishing and Maintaining Registrations 362 Establishing and/or maintaining a registration may require additional 363 information not available in the transmitted REG_REQUEST or 364 REG_RESPONSE parameters. Therefore, registration type definitions 365 MAY define dependencies for HIP parameters that are not defined in 366 this document. Their semantics are subject to the specific 367 registration type specifications. 369 The minimum lifetime both registrars and requesters MUST support is 370 10 seconds, while they SHOULD support a maximum lifetime of 120 371 seconds, at least. 373 A zero lifetime is reserved for canceling purposes. Requesting a 374 zero lifetime for a registration type equals to canceling the 375 registration of that type. A requester MAY cancel a registration 376 before it expires by sending a REG_REQ to the registrar with a zero 377 lifetime. A registrar SHOULD respond and grant a registration with a 378 zero lifetime. A registrar (and an attached service) MAY cancel a 379 registration before it expires, at its own discretion. However, if 380 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 381 registered requesters. 383 6. Security Considerations 385 This section discusses the threats on the HIP registration protocol, 386 and their implications on the overall security of HIP. In 387 particular, it argues that the extensions described in this document 388 do not introduce additional threats to HIP. 390 The extensions described in this document rely on the HIP base 391 exchange and do not modify its security characteristics, e.g., 392 digital signatures or HMAC. Hence, the only threat introduced by 393 these extensions are related to the creation of soft registration 394 state at the registrar. 396 Registrars act on a voluntary basis and are willing to accept to be a 397 responder and to then create HIP associations with a number of 398 previously unknown hosts. Because they have to store HIP association 399 state anyway, adding a certain amount of time-limited HIP 400 registration state should not introduce and serious additional 401 threats, especially because HIP registrars may cancel registrations 402 at any time at their own discretion, e.g., because of resource 403 constraints during an attack. 405 7. IANA Considerations 407 This section is to be interpreted according to [RFC2434]. 409 This document updates the IANA Registry for HIP Parameters Types by 410 assigning new HIP Parameter Types values for the new HIP Parameters 411 defined in this document: 413 o REG_INFO (defined in Section 4.2) 415 o REG_REQUEST (defined in Section 4.3) 417 o REG_RESPONSE (defined in Section 4.4) 419 o REG_FAILED (defined in Section 4.5) 421 IANA needs to open a new registry for registration types. This 422 document does not define registration types but makes the following 423 reservations: 425 Reg Type Service 426 -------- ------- 427 0-200 Reserved by IANA 428 201-255 Reserved by IANA for private use 430 Adding a new type requires new IETF specifications. 432 IANA needs to open a new registry for registration failure types. 433 This document makes the following failure types definitions and 434 reservations: 436 Failure Type Reason 437 ------------ -------------------------------------------- 438 0 Registration requires additional credentials 439 1 Registration type unavailable 440 2-200 Reserved by IANA 441 201-255 Reserved by IANA for private use 443 Adding a new type requires new IETF specifications. 445 8. Acknowledgments 447 The following people (in alphabetical order) have provided thoughtful 448 and helpful discussions and/or suggestions that have helped to 449 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, 450 Pekka Nikander and Hannes Tschofenig. 452 Julien Laganier and Lars Eggert are partly funded by Ambient 453 Networks, a research project supported by the European Commission 454 under its Sixth Framework Program. The views and conclusions 455 contained herein are those of the authors and should not be 456 interpreted as necessarily representing the official policies or 457 endorsements, either expressed or implied, of the Ambient Networks 458 project or the European Commission. 460 9. References 461 9.1 Normative References 463 [I-D.ietf-hip-base] 464 Moskowitz, R., "Host Identity Protocol", 465 draft-ietf-hip-base-03 (work in progress), June 2005. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 471 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 472 October 1998. 474 9.2 Informative References 476 [I-D.ietf-hip-arch] 477 Moskowitz, R., "Host Identity Protocol Architecture", 478 draft-ietf-hip-arch-02 (work in progress), January 2005. 480 [I-D.ietf-hip-rvs] 481 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 482 Rendezvous Extension", draft-ietf-hip-rvs-03 (work in 483 progress), July 2005. 485 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 486 Issues", RFC 3234, February 2002. 488 Authors' Addresses 490 Julien Laganier 491 DoCoMo Communications Laboratories Europe GmbH 492 Landsberger Strasse 312 493 Munich 80687 494 Germany 496 Phone: +49 89 56824 231 497 Email: julien.ietf@laposte.net 498 URI: http://www.docomolab-euro.com/ 499 Teemu Koponen 500 Helsinki Institute for Information Technology 501 Advanced Research Unit (ARU) 502 P.O. Box 9800 503 Helsinki FIN-02015-HUT 504 Finland 506 Phone: +358 9 45 1 507 Email: teemu.koponen@hiit.fi 508 URI: http://www.hiit.fi/ 510 Lars Eggert 511 NEC Network Laboratories 512 Kurfuerstenanlage 36 513 Heidelberg 69115 514 Germany 516 Phone: +49 6221 90511 43 517 Fax: +49 6221 90511 55 518 Email: lars.eggert@netlab.nec.de 519 URI: http://www.netlab.nec.de/ 521 Intellectual Property Statement 523 The IETF takes no position regarding the validity or scope of any 524 Intellectual Property Rights or other rights that might be claimed to 525 pertain to the implementation or use of the technology described in 526 this document or the extent to which any license under such rights 527 might or might not be available; nor does it represent that it has 528 made any independent effort to identify any such rights. Information 529 on the procedures with respect to rights in RFC documents can be 530 found in BCP 78 and BCP 79. 532 Copies of IPR disclosures made to the IETF Secretariat and any 533 assurances of licenses to be made available, or the result of an 534 attempt made to obtain a general license or permission for the use of 535 such proprietary rights by implementers or users of this 536 specification can be obtained from the IETF on-line IPR repository at 537 http://www.ietf.org/ipr. 539 The IETF invites any interested party to bring to its attention any 540 copyrights, patents or patent applications, or other proprietary 541 rights that may cover technology that may be required to implement 542 this standard. Please address the information to the IETF at 543 ietf-ipr@ietf.org. 545 Disclaimer of Validity 547 This document and the information contained herein are provided on an 548 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 549 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 550 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 551 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 552 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Copyright Statement 557 Copyright (C) The Internet Society (2005). This document is subject 558 to the rights, licenses and restrictions contained in BCP 78, and 559 except as set forth therein, the authors retain all their rights. 561 Acknowledgment 563 Funding for the RFC Editor function is currently provided by the 564 Internet Society.