idnits 2.17.1 draft-ietf-mip6-bootstrapping-integrated-dhc-04.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 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-mip6-bootstrapping-integrated-04', but the file name used is 'draft-ietf-mip6-bootstrapping-integrated-dhc-04' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 1, 2007) is 6167 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: 'RFC2119' is defined on line 502, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-05 == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-03 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-02 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury, Editor 3 Internet-Draft Starent Networks 4 Intended status: Standards Track A. Yegin 5 Expires: December 3, 2007 Samsung AIT 6 June 1, 2007 8 MIP6-bootstrapping for the Integrated Scenario 9 draft-ietf-mip6-bootstrapping-integrated-04.txt 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 December 3, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Mobile IPv6 bootstrapping can be categorized into two primary 43 scenarios, the split scenario and the integrated scenario. In the 44 split scenario, the mobile node's mobility service is authorized by a 45 different service authorizer than the network access authorizer. In 46 the the integrated scenario, the mobile node's mobility service is 47 authorized by the same service authorizer as the network access 48 service authorizer. This document defines a method for home agent 49 information discovery for the integrated scenario. 51 Table of Contents 53 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Logical View of the Integrated Scenario . . . . . . . . . 6 58 4.2. Bootstrapping Message Sequence . . . . . . . . . . . . . . 7 59 4.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 7 60 4.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 9 61 4.3. Bootstrapping Message Sequence: Fallback case . . . . . . 11 62 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated 63 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . . . . 18 74 1. Introduction and Scope 76 The Mobile IPv6 protocol [RFC3775] requires the mobile node to have 77 information of its Home Address, the home agent address and the 78 cryptographic materials for establishing an IPsec security 79 association with the home agent prior to initiating the registration 80 process. The mechanism via which the mobile node obtains these 81 information is called Mobile IPv6 bootstrapping. In order to allow a 82 flexible deployment model for Mobile IPv6, it is desirable to define 83 a bootstrapping mechanism for the mobile node to acquire these 84 parameters dynamically. [RFC4640] describes the problem statement 85 for Mobile IPv6 bootstrapping. It also defines two bootstrapping 86 scenarios based on the relationship between the entity that 87 authenticates and authorizes the mobile node for network access 88 (i.e., the Access Service Authorizer) and the entity that 89 authenticates and authorizes the mobile node for mobility service 90 (i.e., the Mobility Service Authorizer). The scenario in which the 91 Access Service Authorizer is not the Mobility Service Authorizer is 92 called the "Split" scenario. The bootstrapping solution for split 93 scenario is defined in [BOOT-SPLIT]. The scenario in which the 94 Access Service Authorizer is also the Mobility Service Authorizer is 95 called the "Integrated" scenario. This document defines a 96 bootstrapping solution for the Integrated scenario. 98 [BOOT-SPLIT] identifies four different components of the 99 bootstrapping problem: home agent address discovery, HoA assignment, 100 IPsec Security Association setup and Authentication and Authorization 101 with the MSA. This document defines a mechanism for home agent 102 address discovery. The other components of bootstrapping are as per 103 [BOOT-SPLIT]. 105 In the integrated scenario, the bootstrapping of the home agent 106 information can be achieved via DHCPv6. This document defines the 107 mip6 bootstrapping procedures for the integrated scenario. It 108 enables Home Agent assignment in the integrated scenario by utilizing 109 DHCP and AAA protocols. The specification utilizes DHCP and AAA 110 options and AVPs that are defined in [HIOPT], [MIP6-Dime], and 111 [MIP6-RADIUS]. This document specifies the interworking among MN, 112 NAS, DHCP, and AAA entities for bootstrapping procedure in the 113 integrated scenario. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119. 121 General mobility terminology can be found in [RFC3753]. The 122 following additional terms, as defined in [RFC4640], are used in this 123 document: 125 Access Service Authorizer (ASA): A network operator that 126 authenticates a mobile node and establishes the mobile node's 127 authorization to receive Internet service. 129 Access Service Provider (ASP): A network operator that provides 130 direct IP packet forwarding to and from the mobile node. 132 Mobility Service Authorizer (MSA): A service provider that authorizes 133 Mobile IPv6 service. 135 Mobility Service Provider (MSP): A service provider that provides 136 Mobile IPv6 service. A MSP is called home MSP when MSP == MSA. In 137 this document the term MSP means a Mobility Service Provider that has 138 roaming relationship with the MSA but it is not the MSA. 140 Split scenario: A scenario where the mobility service and the network 141 access service are authorized by different entities. 143 Integrated Scenario: A scenario where the mobility service and the 144 network access service are authorized by the same entity. 146 3. Assumptions 148 The following assumptions are made in this document: 150 a. MSA == ASA. 152 b. MSA and MSP roaming relationship is assumed but not required. 154 c. DHCP relay and NAS are collocated or there is a mechanism to pass 155 received AAA information from the NAS to the DHCP relay. 157 d. the NAS shall support MIPv6 specific AAA attributes as specified 158 in [MIP6-RADIUS] and [MIP6-Dime]. 160 e. The AAAH used for network access authentication (ASA) has access 161 to the same database as the AAAH used for the mobility service 162 authentication (MSA). 164 4. Solution Overview 166 4.1. Logical View of the Integrated Scenario 168 In the integrated scenario the mobile node utilizes network access 169 authentication process to bootstrap Mobile IPv6. It is assumed that 170 the access service authorizer is mobility service aware. This allows 171 for Mobile IPv6 bootstrapping at the time of access authentication 172 and authorization. Also, the mechanism defined in this document 173 requires the NAS to support Mobile IPv6 specific AAA attributes and a 174 collocated DHCP relay agent. 176 The following diagram shows the network elements and layout in the 177 integrated scenario: 179 | 180 ASP(/MSP) | ASA/MSA(/MSP) 181 | 182 | 183 +-------+ | +-------+ 184 | | | | | 185 |AAAV |-----------|--------|AAAH | 186 | | | | | 187 | | | | | 188 +-------+ | +-------+ 189 | | 190 | | 191 | | 192 | | 193 | | 194 | | 195 | | 196 +-----+ +------+ | 197 +----+ | | |DHCP | | 198 | MN |------| NAS/|----|Server| | 199 +----+ |Relay| | | | 200 +-----+ +------+ | 201 | 202 | 203 +--------+ | +--------+ 204 | HA | | | HA | 205 | in ASP | | |in MSP | 206 +--------+ | +--------+ 208 Integrated Scenario, Network Diagram with DHCP Server 210 Figure 1. Integrated Scenario, Network Diagram with DHCP 212 Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA 213 proxy in the visited network and a AAA server in the home network. 214 The user's home network authorizes the mobile node for network access 215 and also for mobility services. Note that a home agent for usage 216 with the mobile node might be selected in the access service 217 provider's network or alternatively in the mobility service 218 provider's network. 220 The mobile node interacts with the DHCP Server via the Relay Agent 221 after the network access authentication as part of the mobile node 222 configuration procedure. 224 4.2. Bootstrapping Message Sequence 226 In this case, the mobile node is able to acquire the home agent 227 address via a DHCPv6 query. The message flows for home agent 228 allocation in the ASP and the MSP are illustrated below. In the 229 integrated scenario, the ASA and the MSA are the same, it can be 230 safely assumed that the AAAH used for network access authentication 231 (ASA) has access to the same database as the AAAH used for the 232 mobility service authentication (MSA). Hence, the same AAAH can 233 authorize the mobile node for network access and mobility service at 234 the same time. When the MN performs Mobile IPv6 registration, the 235 AAAH ensures that the MN is accessing the assigned Home Agent for 236 that MSP. 238 4.2.1. Home Agent allocation in the MSP 240 This section describes a scenario where the home agent is allocated 241 in the mobile node's MSP network(s). in order to provide the mobile 242 node with information about the assigned home agent the AAAH conveys 243 the assigned home agent's information to the NAS via AAA protocol 244 [MIP6-RADIUS] or [MIP6-Dime]. 246 | 247 --------------ASP------>|<--ASA+MSA-- 248 | 249 +----+ +------+ +-------+ +-----+ 250 | | | | | | | | 251 | MN/| |NAS/ | | DHCP | |AAAH | 252 |User| |DHCP | | Server| | | 253 | | |relay | | Server| | | 254 +----+ +------+ +-------+ +-----+ 255 | | | | 256 | 1 | 1 | | 257 |<------------->|<---------------------->| 258 | | | | 259 | | | | 260 | 2 | | | 261 |-------------->| | | 262 | | | | 263 | | 3 | | 264 | |------------>| | 265 | | | | 266 | | 4 | | 267 | |<------------| | 268 | | | | 269 | 5 | | | 270 |<--------------| | | 271 | | | | 273 Home Agent in the MSP 275 Figure 2. The home agent allocation in the MSP 277 Figure 2 shows the message sequence for home agent allocation in the 278 MSP. 280 (1) The mobile node executes the network access authentication 281 procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. 282 The NAS is in the ASP and it interacts with the AAAH, which is in the 283 ASA/MSA, to authenticate the mobile node. In the process of 284 authorizing the mobile node the AAAH verifies in the AAA profile that 285 the mobile node is allowed to use Mobile IPv6 service. The AAAH 286 assigns home agent in the home MSP and other authorized MSPs and 287 returns this information to the NAS. The NAS may keep the received 288 information for a configurable duration or it may keep the 289 information for as long as the MN is connected to the NAS. 291 (2) The mobile node sends a DHCPv6 Information Request message 292 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 294 In this message the mobile node (DHCP client) SHALL include the 295 Option Code for Home Network Identifier Option [HIOPT] in the 296 OPTION_ORO, Home Network Identifier Option with id-type set to 1 and 297 the Home Network Identifier field set to the network realm of the 298 home MSP [HIOPT]. The mobile node SHALL also include the 299 OPTION_CLIENTID to identify itself to the DHCP server. 301 (3) The Relay Agent intercepts the Information Request from the 302 mobile node and forwards it to the DHCP server. The Relay Agent also 303 includes the received home agent information from the AAAH in the 304 OPTION_MIP6-RELAY-Option [HIOPT]. If a NAS implementation does not 305 store the received information as long as the MN's session remains in 306 the ASP, and if the MN delays sending DHCP request, the NAS/DHCP 307 relay does not include the OPTION_MIP6-RELAY-Option in the Relay 308 Forward message. 310 (4) The DHCP server identifies the client by looking at the DUID for 311 the client in the OPTION_CLIENTID. The DHCP server also determines 312 that the mobile node is requesting home agent information in the MSP 313 by looking at the Home Network Identifier Option (id-type 1). The 314 DHCP server determines that the home agent is allocated by the AAAH 315 by looking at the MIP6 home agent sub-option in the OPTION_MIP6- 316 RELAY-Option. The DHCP server extracts the allocated home agent 317 information from the OPTION_MIP6-RELAY-Option and includes it in the 318 Home Network Information Option [HIOPT] in the Reply Message. If the 319 requested information is not available in the DHCP server, it follows 320 the behavior described in [HIOPT]. 322 (5) The Relay Agent relays the Reply Message from the DHCP server to 323 the mobile node. At this point, the mobile node has the home agent 324 information that it requested. 326 4.2.2. Home Agent allocation in the ASP 328 This section describes a scenario where the mobile node requests for 329 home agent allocation in the ASP by setting the id-type field to zero 330 in the Home Network Identifier Option [HIOPT] in the DHCPv6 request 331 message. In this scenario, the ASP becomes the MSP for the duration 332 of the network access authentication session. 334 | 335 --------------ASP-------->|<--ASA+MSA-- 336 | 337 +----+ +-------+ +-------+ +------+ 338 | | | | | | | | 339 | MN/| | NAS/ | | DHCP | |AAAH | 340 |User| | DHCP | | Server| | | 341 | | | relay | | Server| | | 342 +----+ +-------+ +-------+ +------+ 343 | | | | 344 | 1 | 1 | | 345 |<------------->|<------------------------>| 346 | | | | 347 | | | | 348 | 2 | | | 349 |-------------->| | | 350 | | | | 351 | | 3 | | 352 | |------------->| | 353 | | | | 354 | | 4 | | 355 | |<-------------| | 356 | | | | 357 | 5 | | | 358 |<--------------| | | 359 | | | | 361 Home Agent in the ASP 363 Figure 3. The home agent allocation in the ASP 365 Figure 3 shows the message sequence for home agent allocation in the 366 ASP. 368 (1) The mobile node executes the network access authentication 369 procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. 370 The NAS is in the ASP and it interacts with the AAAH, which is in the 371 ASA/MSA, to authenticate the mobile node. In the process of 372 authorizing the mobile node the AAAH verifies in the AAA profile that 373 the mobile node is allowed to use Mobile IPv6 services. The AAAH 374 assigns a home agent in the home MSP and returns this information to 375 the NAS. Note that the AAAH is not aware of the fact that the mobile 376 node prefers a home agent allocation in the ASP. Therefore the 377 assigned home agent may not be used by the mobile node. This leaves 378 the location of the mobility anchor point decision to the mobile 379 node. 381 (2) The mobile node sends a DHCPv6 Information Request message 382 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 383 In this message the mobile node (DHCP client) SHALL include the 384 Option Code for Home Network Identifier Option [HIOPT] in the 385 OPTION_ORO, Home Network Identifier Option with id-type set to 0. 386 The mobile node SHALL also include the OPTION_CLIENTID to identify 387 itself to the DHCP server. 389 (3) The Relay Agent intercepts the Information Request from the 390 mobile node and forwards it to the DHCP server. The Relay Agent 391 (which is the NAS) also includes the received AAA AVP from the AAAH 392 in the OPTION_MIP6-RELAY-Option [HIOPT]. 394 (4) The DHCP server identifies the client by looking at the DUID for 395 the client in the OPTION_CLIENTID. The DHCP server also determines 396 that the mobile node is requesting home agent information in the ASP 397 by looking at the Home Network Identifier Option (id-type 0). If 398 configured to do so, the DHCP server allocates an home agent from its 399 configured list of home agents and includes it in the Home Network 400 Information Option [HIOPT] in the Reply Message. Note that in this 401 case, the DHCP server does not use the received information in the 402 OPTION_MIP6-RELAY-Option. 404 (5) The Relay Agent relays the Reply Message from the DHCP server to 405 the mobile node. At this point, the mobile node has the home agent 406 information that it requested. 408 4.3. Bootstrapping Message Sequence: Fallback case 410 In the fallback case, the mobile node is not able to acquire the home 411 agent information via DHCPv6. The mobile node MAY perform DNS 412 queries to discover the home agent address as defined in 413 [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile 414 node needs to know the DNS server address. The details of how the MN 415 is configured with the DNS server address is outside the scope of 416 this document. 418 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 420 In the integrated scenario, the HoA, IPsec Security Associations 421 setup, and Authentication and Authorization with the MSA are 422 bootstrapped via the same mechanism as described in the bootstrapping 423 solution for split scenario [BOOT-SPLIT]. 425 5. Security Considerations 427 The transport of the assigned home agent information via the AAA 428 infrastructure (i.e., from the AAA server to the AAA client) to the 429 NAS may only be integrity protected as per standard RADIUS and 430 Diameter security mechanisms. No additional security considerations 431 are imposed by the usage of this document. The security mechanisms 432 provided by [RFC2865] and [RFC3588] are applicable for this purpose. 433 This document does not introduce any new security issues to Mobile 434 IPv6. 436 6. IANA Considerations 438 None 440 7. Acknowledgements 442 The authors would like to thank Kilian Weniger, Vidya Narayanan, and 443 George Tsirtsis for their review and comments. 445 8. Contributors 447 This contribution is a joint effort of the bootstrapping solution 448 design team of the MIP6 WG. The contributors include Gerardo 449 Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, 450 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 451 Chowdhury, Julien Bournelle, and Hannes Tschofenig. 453 The design team members can be reached at: 455 Gerardo Giaretta gerardog@qualcomm.com 457 Basavaraj Patil basavaraj.patil@nsn.com 459 Alpesh Patel alpesh@cisco.com 461 Jari Arkko jari.arkko@kolumbus.fi 463 James Kempf kempf@docomolabs-usa.com 465 Gopal Dommety gdommety@cisco.com 467 Alper Yegin a.yegin@partner.samsung.com 469 Junghoon Jee jhjee@etri.re.kr 471 Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com 473 Kuntal Chowdhury kchowdhury@starentnetworks.com 475 Julien Bournelle julien.bournelle@orange-ftgroup.com 477 Hannes Tschofenig hannes.tschofenig@nsn.com 479 9. References 481 9.1. Normative References 483 [BOOT-SPLIT] 484 Giaretta et. al., A., "Mobile IPv6 bootstrapping in split 485 scenario.", draft-ietf-mip6-bootstrapping-split-05.txt 486 (work in progress), May 2007. 488 [HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent 489 Discovery in MIPv6.", draft-ietf-mip6-hiopt-03.txt (work 490 in progress), May 2007. 492 [MIP6-Dime] 493 Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA 494 Support.", draft-ietf-dime-mip6-integrated-04.txt (work in 495 progress), May 2007. 497 [MIP6-RADIUS] 498 Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.", 499 draft-ietf-mip6-radius-02.txt (work in progress), 500 March 2007. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 506 "Remote Authentication Dial In User Service (RADIUS)", 507 RFC 2865, June 2000. 509 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 510 and M. Carney, "Dynamic Host Configuration Protocol for 511 IPv6 (DHCPv6)", RFC 3315, July 2003. 513 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 514 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 516 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 517 in IPv6", RFC 3775, June 2004. 519 9.2. Informative References 521 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 522 RFC 3753, June 2004. 524 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 525 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 526 September 2006. 528 Authors' Addresses 530 Kuntal Chowdhury 531 Starent Networks 532 30 International Place 533 Tewksbury, MA 01876 534 US 535 Email: kchowdhury@starentnetworks.com 537 Alper Yegin 538 Samsung AIT 539 Istanbul, 540 Turkey 541 Email: a.yegin@partner.samsung.com 543 Full Copyright Statement 545 Copyright (C) The IETF Trust (2007). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Acknowledgment 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).