idnits 2.17.1 draft-korhonen-netlmm-pp-aaa-reqs-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5883 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) -- Looks like a reference, but probably isn't: 'MN1' on line 183 -- Looks like a reference, but probably isn't: 'MN2' on line 183 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-02 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-08 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '7') (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG J. Korhonen 3 Internet-Draft TeliaSonera 4 Intended status: Standards Track A. Muhanna 5 Expires: August 21, 2008 Nortel Networks 6 February 18, 2008 8 Policy Profile and AAA Interfaces Requirements for PMIPv6 9 draft-korhonen-netlmm-pp-aaa-reqs-00.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 August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This specification defines the Policy Profile and AAA interfaces 43 requirements for the Proxy Mobile IPv6. The Policy Profile 44 information needed by the Proxy Mobile IPv6 may be statically 45 provisioned in the mobile access gateway and in the local mobility 46 anchor. Alternatively, the Policy Profile information or a subset of 47 its parameters can be dynamically downloaded to the mobile access 48 gateway from the AAA server during the mobile node access 49 authentication and authorization when the mobile node roams into a 50 Proxy Mobile IPv6 domain. The local mobility anchor may download the 51 user policy profile parameters during the Proxy Mobile IPv6 52 registration process. This document describes the requirements for 53 the Proxy Mobile IPv6 Policy Profile and the corresponding AAA 54 interfaces. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Policy Profile . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Policy Profile and Storage Requirements . . . . . . . . . 7 63 5. Mobility Service Setup . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Generic Service Setup Requirements . . . . . . . . . . . . 8 65 5.2. Initial Dynamic LMA Discovery Requirements . . . . . . . . 9 66 5.3. LMA Discovery After a Handover Requirements . . . . . . . 9 67 5.4. MAG to LMA Security Association Setup Requirements . . . . 10 68 5.5. Generic LMA to AAA Requirements . . . . . . . . . . . . . 10 69 5.6. Generic MAG to AAA Requirements . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 In the Proxy Mobile IPv6 (PMIPv6) protocol [1] and PMIPv6 IPv4 82 support [2], a Mobile Access Gateway (MAG) performs a proxy 83 registration with a Local Mobility Anchor (LMA) on behalf of the 84 mobile node (MN). In order to perform the proxy registration, the 85 PMIPv6 MAG needs the address of the LMA, MN's home network prefix 86 (MN-HNP), possibly MN's IPv4 home address (IPv4-HoA), DHCP server 87 address and other PMIPv6 specific information such as allowed address 88 configuration modes, bearer plane security requirements, and possible 89 roaming related policies. All this information is defined in MN's 90 Policy Profile (PP) that could be downloaded from a remote Policy 91 Store (PS) using the AAA infrastructure or statically configured in 92 the MAG and/or the LMA. 94 Dynamic assignment and downloading of PMIPv6 Policy Profile 95 information is a desirable feature to ease the deployment and network 96 maintenance of large PMIPv6 deployments. For this purpose, the AAA 97 infrastructure which is used for access authentication, can be 98 leveraged to assign some or all of the necessary policy profile 99 parameters. The AAA server in the Mobility Service Authorizer's 100 (MSA) or in the Mobility Service Provider's (MSP) network may return 101 these parameters to the Network Access Server (NAS). The NAS may be 102 either co-located with MAGs or an integral part of a MAG. 104 This specification defines the requirements for the PMIPv6 Policy 105 Profile, the Policy Store and the AAA interfaces interactions. 107 2. Terminology and Abbreviations 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119 [3]. 113 General mobility terminology can be found in [4] and [1]. The 114 following additional or clarified terms are used in this document: 116 Network Access Server (NAS): 118 A device that provides an access service for a user to a network. 119 In the context of this document the NAS may be integrated into or 120 co-located with a MAG. The NAS contains a Diameter client 121 function. 123 Home AAA (HAAA): 125 An authentication, authorization and accounting server located in 126 user's home network. A HAAA is essentially a Diameter server. 128 Policy Profile (PP) 130 A user subscription policy profile contains the essential 131 operational parameters that are required by the network entities 132 for managing the mobile node's network-based mobility service. 133 These policy profiles are stored in a local or a remote policy 134 store. 136 Policy Store (PS): 138 A node that contains the policy profile of a subscriber. The 139 policy store may be co-located with the Mobile Access Gateway, the 140 Local Mobility Anchor or the AAA server. When the Policy Store is 141 co-located with the HAAA server it can be queried by using an AAA 142 infrastructure. 144 3. Overview 146 This document addresses the authentication, authorization, accounting 147 and session management functionality needed by the PMIPv6 protocol. 148 It also defines the requirements of a diameter based MAG to HAAA and 149 LMA to HAAA interfaces. The intention of this document is to define 150 the requirements which may extend existing Mobile IPv6 specifications 151 such as [5] and define needed additional AVPs and functionality to 152 fulfill the needs of the PMIPv6 deployment. 154 The policy profile download from the HAAA to the MAG is part of the 155 network access authentication procedure when a MN roams into or 156 within a PMIPv6 Domain. Figure 1 shows the participating network 157 entities. This document, however, only concentrates on the MAG, LMA, 158 possible local Diameter proxies and the home Diameter server. When 159 aligned with [5] the MAG acts as the NAS located in ASP, the HAAA 160 acts as the Diameter server located in ASA/MSA/MSP and the LMA acts 161 as the HA in ASP/MSP. 163 +--------+ 164 | HAAA & | AAA +-----+ 165 | Policy |<-------->| LMA | 166 | Profile| +-----+ 167 +--------+ | <--- LMA-Address 168 ^ | 169 | // \\ 170 +--|------------- //---\\----------------+ 171 ( | IPv4/IPv6 // \\ ) 172 ( | Network // \\ ) 173 +--|-----------//---------\\-------------+ 174 | // \\ 175 AAA | // <- Tunnel1 \\ <- Tunnel2 176 | // \\ 177 | |- MAG-Address1 |- MAG-Address2 178 | +----+ +----+ 179 +---->|MAG1| |MAG2| 180 +----+ +----+ 181 | | 182 | | 183 [MN1] [MN2] 185 Figure 1: Proxy Mobile IPv6 Domain with MAG and LMA Interfaces with 186 HAAA 188 In a PMIPv6 access scenario a MN attaches to a PMIPv6-Domain and 189 starts a network access authentication procedure. The choice of 190 authentication mechanism is specific to the access network 191 deployment, but could be based on the Extensible Authentication 192 Protocol (EAP) [6]. During the network access authentication 193 procedure, the MAG acting as a NAS queries the HAAA through the AAA 194 infrastructure using the Diameter protocol. If the HAAA detects that 195 the subscriber is also authorized for the PMIPv6 service, the 196 subscriber policy is returned along with the successful network 197 access authentication answer to the MAG. 199 After the mobile node is successfully authenticated and the MAG 200 receives the policy profile parameters during the access 201 authentication procedure the MAG sends a PBU to the LMA. Upon 202 receiving the PBU the LMA may interact with the HAAA and fetches the 203 relevant subscriber policy, authorization and security information 204 related to the PMIPv6 session. This specification assumes that the 205 HAAA is the central node for managing all PMIPv6 subscription and 206 session related activities which may even include the allocation of 207 prefixes. 209 Prior to sending the PBU there might be a need to dynamically setup 210 the MAG to LMA Security Association (SA), for example using IKEv2/ 211 IPSec [7]. The dynamic SA setup procedure may be triggered by the MN 212 attaching to the MAG that does not have existing SA with the 213 correspondent LMA. The details of the dynamic SA setup procedure is 214 out of scope of this specification. However, the SA is between the 215 MAG and the corresponding LMA, thus it can be created using any 216 security mechanism that is applicable for PMIPv6 security such as 217 IKEv2 IPSec with an EAP-based authentication. It should be noted 218 that the identity used by MAG during the SA creation is the MAG's own 219 identity and the credentials are for authenticating the MAG toward 220 the LMA and the MAG authorization to send Proxy BU on behalf the 221 mobile nodes. 223 4. Policy Profile 225 A MN's Policy Profile contains the essential operational parameters 226 that are required by the network entities for managing the MN's 227 mobility service. In the context of this documents, we only address 228 the Policy Profile parameters that are essential for PMIPv6. 229 However, in live network deployments the Policy Profile may also be 230 populated with parameters that are not directly related to PMIPv6 231 operation but required by the operator. This document makes an 232 assumption that these Policy Profiles are stored in a remote Policy 233 Store that could be co-located with the MN's home AAA server and 234 accessed through an AAA interface. The same AAA interface is also 235 used for authenticating the MN when it attaches to the MAG and the 236 PMIPv6 Domain. The Policy Profile has both static and dynamically 237 updated parameters. The dynamic parameters may change per PMIPv6 238 session basis or during the session to reflect the current status of 239 the mobile node's PMIPv6 session. 241 The MAG and the LMA obtain essential parameters of the MN's Policy 242 Profile to their local copies of the Policy Store using the AAA 243 interface. The MAG and the LMA use the same AAA interfaces also to 244 update the dynamic Policy Profile parameters in the remote Policy 245 Store. The Policy Profile may also be handed over to a serving MAG 246 as part of a context transfer procedure during a handover. However, 247 the context transfer is out of scope of this document. The local 248 copy of the MN's Policy Profile may be slightly different in the MAG 249 compared to one in the LMA. 251 The following Policy Profile parameters are located in the MAG. 252 These parameters may be statically configured or dynamically 253 allocated using the MAG-AAA interface. Dynamically assigned 254 parameter values always override the statically configured ones: 256 o The MN's identifier (MN-ID). This parameter may be obtained from 257 the remote Policy Store, learned during mobile node access 258 authentication, or generated locally in the MAG. If inter- 259 operator deployments are supported then the MD-ID parameter must 260 be accompanied with MN's home realm parameter. 262 o The IPv6 address of the Local Mobility Anchor (LMAA). This 263 parameter may be configured dynamically using methods described in 264 section . If inter-operator deployments are supported then the 265 LMAA parameter must be accompanied with corresponding realm 267 o The IPv4 address of the Local Mobility Anchor (LMAA). This 268 parameter may be configured dynamically using methods described in 269 section . If inter-operator deployments are supported then the 270 LMAA parameter must be accompanied with corresponding realm. 272 o The MN's IPv6 home network prefix (MN-HNP). The MN-HNP may be 273 downloaded during the MN access authentication from the remote 274 Policy Store. If the MN-HNP is not provided during the access 275 authentication time, it will be dynamically assigned to the MN 276 during the proxy binding procedure. 278 o Supported address configuration procedures (Stateful, Stateless or 279 both) on the access links in the PMIPv6 domain. This parameter 280 also defines whether IPv4 home address can be configured to the 281 MN. 283 o The MN's IPv4 home address (IPv4-HoA). The IPv4-HoA may be 284 downloaded during the MN access authentication from the remote 285 Policy Store. If the IPv4-HoA is not provided during the access 286 authentication time, it will be dynamically assigned to the MN 287 during the proxy binding procedure. 289 o The MN's interface identifier. The identifier may be MN's link 290 layer interface identifier or generated locally based by the MAG. 291 This identifies must be unique in all those PMIPv6 Domains the MN 292 can attach to. 294 o The local routing option flag. When this configuration option is 295 set true, two MNs attached to the same MAG may directly 296 communicate with each other without routing traffic via the LMA. 298 4.1. Policy Profile and Storage Requirements 300 As stated earlier there are local and remote copies of the Policy 301 Profile. The default local profile is usually coupled with the local 302 administrative policies that must be taken into account during the 303 Policy Profile retrieval from the remote Policy Store. 305 R1.1: There must be a mechanism for a capability negotiation between 306 the MAG and the remote Policy Store. For example, the MAG must be 307 able to inform the remote Policy Store whether a local routing in 308 a MAG is supported by the local administrative policy. 310 5. Mobility Service Setup 312 Setting up the mobility service refers to a procedure that takes 313 place when a MN attaches to a MAG and to a PMIPv6 Domain. Prior the 314 attachment, the MAG may or may not have a security association set up 315 with the LMA located in the MN's home realm. 317 The discovery of the LMA corresponding to the MN's home realm is an 318 essential part of the mobility service setup. The discovery may be 319 dynamic or static depending on the MAG configuration. In the context 320 of this document the dynamic discovery of the LMA is inherently tied 321 to procedures that take place during the MN access authentication. 323 5.1. Generic Service Setup Requirements 325 The mobility service setup procedures must comply with the following 326 deployment related requirements: 328 R2.1: The MN should provide at least its permanent id and home realm 329 during the access authentication. In the case the MN is not able 330 to provide adequate home realm information, then the MN must 331 provide the MAG with another identifier that the MAG can use 332 either to generate or discover MN's home realm. The home realm is 333 used by the MAG/NAS and the AAA infrastructure to route AAA 334 requests from the MAG/NAS to the MN's home AAA server. 336 R2.2: It must be possible to separate the MAG's proxy mobile agent 337 functionality and the NAS functionality. Thus allowing 338 deployments, where a single NAS provides AAA services for a pool 339 of MAGs. 341 R2.3: It must be possible for the LMA to return a temporary MN 342 identity to the MAG during the access authentication. This 343 identity must be unique within the PMIPv6 domain and should hide 344 MN's true identity even from the MAG. The LMA provided temporary 345 MN identity must remain unchanged during the lifetime of the 346 mobility service session. The MAG must use this identity, if 347 available, in all subsequent AAA messages to identify the MN. 349 5.2. Initial Dynamic LMA Discovery Requirements 351 This section describes the requirements for the initial LMA address 352 discovery process. The discovery process takes place when the MN 353 attaches to the PMIPv6 Domain and starts the mobility service for the 354 first time. 356 R3.1: Configuration of the LMA address must be possible per realm 357 basis. The configuration may be static or dynamic to the MAG. 359 R3.2: The LMA address must be provided either as an IP address or as 360 a FQDN. The FQDN may be generated by the MAG based on the MN's 361 home realm or other identifier provided by the MN, or retrieved 362 from the AAA server. 364 R3.3: It must be possible to return multiple LMA addresses and FQDNs 365 simultaneously using the AAA interface between the MAG and the 366 Policy Store. Furthermore, grouping of LMA address and FQDN pairs 367 must be possible. 369 The MAG queries the DNS system in order to resolve the FQDN to the 370 LMA IP address. SRV, AAAA or A resource records may be queried 371 depending on the deployment. 373 The AAA interface between the MAG and the Policy Store may return 374 both LMA IP address and the LMA FQDN at the same time. In this case 375 the MAG may skip the LMA address DNS resolving step. It is possible, 376 depending on the deployment, that the FQDN is also used to piggy-back 377 service level information (e.g. LMAs with dedicated roles). 379 5.3. LMA Discovery After a Handover Requirements 381 This section describes the requirements for the LMA address discovery 382 process after a handover to a new MAG when the MN has an existing 383 mobility session. The discovery process takes place when the MN 384 attaches to a new MAG either under the same or different PMIPv6 385 Domain. 387 R4.1: During the MN access authentication procedure the remote 388 Policy Store must be able to discover that the MN has an existing 389 mobility service session and return the IP address or the FQDN of 390 the LMA where the MN's mobility service session is anchored. 392 R4.2: During the MN access authentication procedure the remote 393 Policy Store must return MN's temporary identity to the MAG, if 394 the MAG does not have other mechanisms of learning it. The remote 395 Policy Store should also return other MN's Policy Profile 396 information to the MAG. This information may include e.g., MN-HNP 397 and IPv4-HoA. 399 If the remote Policy Store (i.e. the home AAA server) is able to find 400 an existing mobility service session for the authenticating MN, then 401 the existing LMA IP address should be returned to the MAG/NAS. If a 402 FQDN is returned instead, then the MAG/NAS may not have a way to 403 distinguish between a MN handover and a MN initial attachment. If 404 only a FQDN gets returned to the MAG/NAS for the existing mobility 405 service session then the operator must ensure that the FQDN gets 406 resolved to exactly one LMA where the MN's mobility service session 407 is anchored. 409 5.4. MAG to LMA Security Association Setup Requirements 411 The SA between the MAG and each LMA may be 1) statically configured 412 or 2) a MAG initiated using some dynamic security association and key 413 exchange protocol. An example of a security association and key 414 exchange protocol is IKEv2 [7]. Credentials and identities used to 415 authenticate and authorize the MAG towards the LMA must be decoupled 416 from those used to authenticate and authorize the MN. The dynamic 417 creation of the MAG to LMA security association setup may be 418 triggered by a MN roaming in and attaching to the PMIPv6 domain. 420 R5.1: Depending on the deployment, it must be possible to decouple 421 the MAG to LMA Security Association Setup from the MN 422 authentication and authorization. 424 The MAG to LMA Security Association may be removed or disabled when 425 there is not any active mobility service session towards the LMA. 427 5.5. Generic LMA to AAA Requirements 429 The LMA to AAA interface has five possible functions: 1) the MAG to 430 LMA security association setup related AAA signaling that was 431 discussed in Section 5.4, 2) authorization of the incoming PBU, 3) 432 mobility service session management, 4) dynamic updating of MN's 433 Policy profile in the remote Policy Store, and 5) accounting. 435 R6.1: Depending on the deployment, the LMA should be able to 436 delegate the MN-HNP and IPv4-HoA management to the AAA server. 438 R6.2: AAA server must be able to initiate a mobility service session 439 termination towards the LMA. 441 R6.3: Based on the deployment and trust relationship between the MAG 442 and the LMA, the LMA MAY be able to validate the mobile node 443 PMIPv6 service authorization upon receiving a PMIPv6 PBU from the 444 specified MAG. 446 R6.4: The LMA must be able to send accounting data to the AAA 447 server. 449 The dynamic updating of MN's Policy Profile in the remote Policy 450 Store is implicitly part of the above requirements. 452 5.6. Generic MAG to AAA Requirements 454 The MAG to AAA interface has several additional functions in addition 455 to the authentication and authorization of the MN, and subsequent 456 setting up the mobility service session. These additional functions 457 include e.g., accounting and the mobility service session management. 459 R7.1: AAA server must be able to initiate a mobility service session 460 termination towards the MAG. 462 R7.2: The MAG must be able to send accounting data to the AAA 463 server. 465 6. IANA Considerations 467 This document has no actions for IANA. 469 7. Security Considerations 471 TBD 473 8. Acknowledgements 475 TBD 477 9. References 479 9.1. Normative References 481 [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 482 B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 483 (work in progress), February 2008. 485 [2] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile 486 IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in 487 progress), November 2007. 489 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 490 Levels", BCP 14, RFC 2119, March 1997. 492 9.2. Informative References 494 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 495 RFC 3753, June 2004. 497 [5] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. 498 Chowdhury, "Diameter Mobile IPv6: Support for Network Access 499 Server to Diameter Server Interaction", 500 draft-ietf-dime-mip6-integrated-08 (work in progress), 501 February 2008. 503 [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 504 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 505 June 2004. 507 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 508 December 2005. 510 Authors' Addresses 512 Jouni Korhonen 513 TeliaSonera 514 Teollisuuskatu 13 515 Sonera FIN-00051 516 Finland 518 Email: jouni.korhonen@teliasonera.com 520 Ahmad Muhanna 521 Nortel Networks 522 2221 Lakeside Blvd. 523 Richardson, TX 75082 524 USA 526 Email: amuhanna@nortel.com 528 Full Copyright Statement 530 Copyright (C) The IETF Trust (2008). 532 This document is subject to the rights, licenses and restrictions 533 contained in BCP 78, and except as set forth therein, the authors 534 retain all their rights. 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 539 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 540 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 541 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Intellectual Property 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Acknowledgment 570 Funding for the RFC Editor function is provided by the IETF 571 Administrative Support Activity (IASA).