idnits 2.17.1 draft-ietf-hip-registration-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. ** 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 (June 7, 2006) is 6531 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-05 ** 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 (-05) exists of draft-ietf-hip-rvs-04 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: December 9, 2006 T. Koponen 5 HIIT 6 L. Eggert 7 NEC 8 June 7, 2006 10 Host Identity Protocol (HIP) Registration Extension 11 draft-ietf-hip-registration-02 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 December 9, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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) [RFC4423]. The extension provides a generic means for a host 52 to register with a service. The service may, for example, be a HIP 53 rendezvous server [I-D.ietf-hip-rvs] or a middlebox [RFC3234]. 55 This document makes no further assumptions about the exact type of 56 service. Likewise, this document does not specify any mechanisms to 57 discover the presence of specific services or means to interact with 58 them after registration. Future documents may describe those 59 operations. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Terminology 67 This section defines terminology that is used throughout the 68 remainder of this document. Please note that terminology shared with 69 other documents is defined elsewhere [RFC4423]. 71 Requester: 72 a HIP node registering with a HIP registrar to request 73 registration for a service. 75 Registrar: 76 a HIP node offering registration for one or more services. 78 Service: 79 a facility that provides requesters with new capabilities or 80 functionalities operating at the HIP layer. Examples include 81 firewalls that support HIP traversal or HIP rendezvous servers. 83 Registration: 84 shared state stored by a requester and a registrar, allowing the 85 requester to benefit from one or more HIP services offered by the 86 registrar. Each registration has an associated finite lifetime. 87 Requesters can extend established registrations through re- 88 registration (i.e., perform a refresh). 90 Registration Type: 91 an identifier for a given service in the registration protocol. 92 For example, the rendezvous service is identified by a specific 93 registration type. 95 3. HIP Registration Extension Overview 97 This document does not specify the means by which a requester 98 discovers the availability of a service, or how a requester locates a 99 registrar. After a requester has discovered a registrar, it either 100 initiates HIP base exchange or uses an existing HIP association with 101 the registrar. In both cases, registrars use additional parameters 102 that the remainder of this document defines to announce their quality 103 and grant or refuse registration. Requesters use corresponding 104 parameters to register with the service. Both the registrar and the 105 requester MAY also include in the messages exchanged additional HIP 106 parameters specific to the registration type implicated. Other 107 documents will define parameters and how they shall be used. The 108 following sections describe the differences between this registration 109 handshake and the standard HIP base exchange [I-D.ietf-hip-base] . 111 3.1. Registrar Announcing its Ability 113 A host that is capable and willing to act as a registrar SHOULD 114 include a REG_INFO parameter in the R1 packets it sends during all 115 base exchanges. If it is currently unable to provide services due to 116 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 117 with no services listed. If services can be provided later, it 118 SHOULD send UPDATE packets indicating the current set of services 119 available in a new REG_INFO parameter to all hosts it is associated 120 with. 122 3.2. Requester Requesting Registration 124 To request registration with a service, a requester constructs and 125 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 126 packet it sends to the registrar. 128 If the requester has no HIP association established with the 129 registrar, it SHOULD already send the REG_REQUEST in the I2 packet. 130 This minimizes the number of packets that need to be exchanged with 131 the registrar. A registrar MAY end a HIP association that does not 132 carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED 133 in the R2. In this case, no HIP association is created between the 134 hosts. The REG_REQUIRED notification error type is TBD. 136 3.3. Registrar Granting or Refusing Service(s) Registration 138 Once registration has been requested, the registrar is able to 139 authenticate the requester based on the host identity included in I2. 140 It then verifies the host identity is authorized to register with the 141 requested service(s), based on local policies. The details of this 142 authorization procedure depend on the type of requested service(s) 143 and on the local policies of the registrar, and are therefore not 144 further specified in this document. 146 After authorization, the registrar includes in its response (i.e., an 147 R2 or an UPDATE, respectively, depending on whether the registration 148 was requested during the base exchange, or using an existing 149 association) a REG_RESPONSE parameter containing the service(s) 150 type(s) for which it has authorized registration, and zero or more 151 REG_FAILED parameter containing the service(s) type(s) for which it 152 has not authorized registration or registration has failed for other 153 reasons. In particular, REG_FAILED with a failure type of zero 154 indicates the service(s) type(s) that require further credentials for 155 registration. 157 If the registrar requires further authorization and the requester has 158 additional credentials available, the requester SHOULD try to again 159 register with the service after the HIP association has been 160 established. The precise means of establishing and verifying 161 credentials are beyond the scope of this document and are expected to 162 be defined in other documents. 164 Successful processing of a REG_RESPONSE parameter creates 165 registration state at the requester. In a similar manner, successful 166 processing of a REG_REQUEST parameter creates registration state at 167 the registrar and possibly at the service. Both the requester and 168 registrar can cancel a registration before it expires, if the 169 services afforded by a registration are no longer needed by the 170 requester, or cannot be provided any longer by the registrar (for 171 instance, because its configuration has changed). 173 +-----+ I1 +-----+-----+ 174 | |--------------------->| | S1 | 175 | |<---------------------| | | 176 | | R1(REG_INFO:S1,S2) | +-----+ 177 | RQ | | R | S2 | 178 | | I2(REG_REQ:S1) | | | 179 | |--------------------->| +-----+ 180 | |<---------------------| | S3 | 181 | | R2(REG_RESP:S1) | | | 182 +-----+ +-----+-----+ 183 +-----+ +-----+-----+ 184 | | UPDATE(REG_INFO:S) | | | 185 | |<---------------------| | | 186 | RQ |--------------------->| R | S | 187 | | UPDATE(REG_REQ:S) | | | 188 | | UPDATE(REG_RESP:S) | | | 189 | |<---------------------| | | 190 +-----+ +-----+-----+ 192 4. Parameter Formats and Processing 194 This section describes the format and processing of the new 195 parameters introduced by the HIP registration extension. 197 4.1. Encoding Registration Lifetimes with Exponents 199 The HIP registration uses an exponential encoding of registration 200 lifetimes. This allows compact encoding of 255 different lifetime 201 values ranging from 4 ms to 178 days into an 8-bit integer field. 202 The lifetime exponent field used throughout this document MUST be 203 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 204 seconds. 206 4.2. REG_INFO 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | ... | ... | Reg Type #n | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Type [ TBD by IANA (930) ] 221 Length Length in octets, excluding Type, Length, and Padding. 222 Min Lifetime Minimum registration lifetime. 223 Max Lifetime Maximum registration lifetime. 224 Reg Type The registration types offered by the registrar. 226 Other documents will define specific values for registration types. 228 Reg Type Service 229 -------- ------- 230 0-200 Reserved by IANA 231 201-255 Reserved by IANA for private use 233 Registrars include the parameter in R1 packets in order to announce 234 their registration capabilities. The registrar SHOULD include the 235 parameter in UPDATE packets when its service offering has changed. 236 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 238 4.3. REG_REQUEST 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | ... | ... | Reg Type #n | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Type [ TBD by IANA (932) ] 253 Length Length in octets, excluding Type, Length, and Padding. 254 Lifetime Requested registration lifetime. 255 Reg Type The preferred registration types in order of preference. 257 Other documents will define specific values for registration types. 259 Reg Type Service 260 -------- ------- 261 0-200 Reserved by IANA 262 201-255 Reserved by IANA for private use 264 A requester includes the REG_REQUEST parameter in I2 or UPDATE 265 packets to register with a registrar's service(s). If the 266 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 267 modify the registrations of registration types which are not listed 268 in the parameter. Moreover, the requester MUST NOT include the 269 parameter unless the registrar's R1 packet or latest received UPDATE 270 packet has contained a REG_INFO parameter with the requested 271 registration types. 273 The requester MUST NOT include more than one REG_REQUEST parameter in 274 its I2 or UPDATE packets, while the registrar MUST be able to process 275 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 277 When the registrar is requested a registration which lifetime is 278 either smaller or greater than the minimum or maximum lifetime, 279 respectively, then it SHOULD grant the registration for the minimum 280 or maximum lifetime, respectively. 282 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 283 packets. 285 4.4. REG_RESPONSE 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Lifetime | Reg Type #1 | Reg Type #2 | Reg Type #3 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | ... | ... | Reg Type #n | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Type [ TBD by IANA (934) ] 300 Length Length in octets, excluding Type, Length, and Padding. 301 Lifetime Granted registration lifetime. 302 Reg Type The granted registration types in order of preference. 304 Other documents will define specific values for registration types. 306 Reg Type Service 307 -------- ------- 308 0-200 Reserved by IANA 309 201-255 Reserved by IANA for private use 311 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 312 UPDATE packet only if a registration has successfully completed. 314 The registrar MUST NOT include more than one REG_RESPONSE parameter 315 in its R2 or UPDATE packets, while the requester MUST be able to 316 process one or more REG_RESPONSE parameters in received R2 or UPDATE 317 packets. 319 The requester MUST be prepared to receive any registration lifetime, 320 included ones beyond the minimum and maximum lifetime indicated in 321 the REG_INFO parameter. It MUST NOT expect that the returned 322 lifetime will be the requested one, even in the case that the 323 requested lifetime falls within the announced minimum and maximum. 325 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 326 packets. 328 4.5. REG_FAILED 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Failure Type | Reg Type #1 | Reg Type #2 | Reg Type #3 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | ... | ... | Reg Type #n | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding + 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Type [ TBD by IANA (936) ] 343 Length Length in octets, excluding Type, Length, and Padding. 344 Failure Type Reason for failure. 345 Reg Type The registration types that failed with the specified 346 reason. 348 Other documents will define specific values for registration types. 350 Reg Type Service 351 -------- ------- 352 0-200 Reserved by IANA 353 201-255 Reserved by IANA for private use 355 Failure Type Reason 356 ------------ -------------------------------------------- 357 0 Registration requires additional credentials 358 1 Registration type unavailable 359 2-200 Reserved by IANA 360 201-255 Reserved by IANA for private use 362 A failure type of zero means a registrar requires additional 363 credentials to authorize a requester to register with the 364 registration types listed in the parameter. A failure type of one 365 means that the requested service type is unavailable at the 366 registrar. Other failure types than zero (0) and one (1) have not 367 been defined. 369 The registrar SHOULD include the REG_FAILED parameter in its R2 or 370 UPDATE packet, if registration with the registration types listed has 371 not completed successfully and a requester is asked to try again with 372 additional credentials. 374 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 375 packets. 377 5. Establishing and Maintaining Registrations 379 Establishing and/or maintaining a registration may require additional 380 information not available in the transmitted REG_REQUEST or 381 REG_RESPONSE parameters. Therefore, registration type definitions 382 MAY define dependencies for HIP parameters that are not defined in 383 this document. Their semantics are subject to the specific 384 registration type specifications. 386 The minimum lifetime both registrars and requesters MUST support is 387 10 seconds, while they SHOULD support a maximum lifetime of 120 388 seconds, at least. These values define a baseline for the 389 specification of services based on the registration system. They 390 were chosen to be neither to short nor too long, and to accommodate 391 for existing timeouts of state established in middleboxes (e.g. NATs 392 and firewalls.) 394 A zero lifetime is reserved for canceling purposes. Requesting a 395 zero lifetime for a registration type equals to canceling the 396 registration of that type. A requester MAY cancel a registration 397 before it expires by sending a REG_REQ to the registrar with a zero 398 lifetime. A registrar SHOULD respond and grant a registration with a 399 zero lifetime. A registrar (and an attached service) MAY cancel a 400 registration before it expires, at its own discretion. However, if 401 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 402 registered requesters. 404 6. Security Considerations 406 This section discusses the threats on the HIP registration protocol, 407 and their implications on the overall security of HIP. In 408 particular, it argues that the extensions described in this document 409 do not introduce additional threats to HIP. 411 The extensions described in this document rely on the HIP base 412 exchange and do not modify its security characteristics, e.g., 413 digital signatures or HMAC. Hence, the only threat introduced by 414 these extensions are related to the creation of soft registration 415 state at the registrar. 417 Registrars act on a voluntary basis and are willing to accept to be a 418 responder and to then create HIP associations with a number of 419 previously unknown hosts. Because they have to store HIP association 420 state anyway, adding a certain amount of time-limited HIP 421 registration state should not introduce and serious additional 422 threats, especially because HIP registrars may cancel registrations 423 at any time at their own discretion, e.g., because of resource 424 constraints during an attack. 426 7. IANA Considerations 428 This section is to be interpreted according to [RFC2434]. 430 This document updates the IANA Registry for HIP Parameters Types by 431 assigning new HIP Parameter Types values for the new HIP Parameters 432 defined in this document: 434 o REG_INFO (defined in Section 4.2) 436 o REG_REQUEST (defined in Section 4.3) 438 o REG_RESPONSE (defined in Section 4.4) 440 o REG_FAILED (defined in Section 4.5) 442 IANA needs to open a new registry for registration types. This 443 document does not define registration types but makes the following 444 reservations: 446 Reg Type Service 447 -------- ------- 448 0-200 Reserved by IANA 449 201-255 Reserved by IANA for private use 451 Adding a new type requires new IETF specifications. 453 IANA needs to open a new registry for registration failure types. 454 This document makes the following failure types definitions and 455 reservations: 457 Failure Type Reason 458 ------------ -------------------------------------------- 459 0 Registration requires additional credentials 460 1 Registration type unavailable 461 2-200 Reserved by IANA 462 201-255 Reserved by IANA for private use 464 Adding a new type requires new IETF specifications. 466 8. Acknowledgments 468 The following people (in alphabetical order) have provided thoughtful 469 and helpful discussions and/or suggestions that have helped to 470 improve this document: Jeffrey Ahrenholz, Miriam Esteban, Mika Kousa, 471 Pekka Nikander and Hannes Tschofenig. 473 Julien Laganier and Lars Eggert are partly funded by Ambient 474 Networks, a research project supported by the European Commission 475 under its Sixth Framework Program. The views and conclusions 476 contained herein are those of the authors and should not be 477 interpreted as necessarily representing the official policies or 478 endorsements, either expressed or implied, of the Ambient Networks 479 project or the European Commission. 481 9. References 483 9.1. Normative References 485 [I-D.ietf-hip-base] 486 Moskowitz, R., "Host Identity Protocol", 487 draft-ietf-hip-base-05 (work in progress), March 2006. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 493 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 494 October 1998. 496 9.2. Informative References 498 [I-D.ietf-hip-rvs] 499 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 500 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 501 progress), October 2005. 503 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 504 Issues", RFC 3234, February 2002. 506 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 507 (HIP) Architecture", RFC 4423, May 2006. 509 Authors' Addresses 511 Julien Laganier 512 DoCoMo Communications Laboratories Europe GmbH 513 Landsberger Strasse 312 514 Munich 80687 515 Germany 517 Phone: +49 89 56824 231 518 Email: julien.ietf@laposte.net 519 URI: http://www.docomolab-euro.com/ 521 Teemu Koponen 522 Helsinki Institute for Information Technology 523 Advanced Research Unit (ARU) 524 P.O. Box 9800 525 Helsinki FIN-02015-HUT 526 Finland 528 Phone: +358 9 45 1 529 Email: teemu.koponen@hiit.fi 530 URI: http://www.hiit.fi/ 532 Lars Eggert 533 NEC Network Laboratories 534 Kurfuerstenanlage 36 535 Heidelberg 69115 536 Germany 538 Phone: +49 6221 90511 43 539 Fax: +49 6221 90511 55 540 Email: lars.eggert@netlab.nec.de 541 URI: http://www.netlab.nec.de/ 543 Intellectual Property Statement 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org. 567 Disclaimer of Validity 569 This document and the information contained herein are provided on an 570 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 571 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 572 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 573 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 574 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 575 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Copyright Statement 579 Copyright (C) The Internet Society (2006). This document is subject 580 to the rights, licenses and restrictions contained in BCP 78, and 581 except as set forth therein, the authors retain all their rights. 583 Acknowledgment 585 Funding for the RFC Editor function is currently provided by the 586 Internet Society.