idnits 2.17.00 (12 Aug 2021) /tmp/idnits12050/draft-ietf-mip6-aaa-ha-goals-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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 538. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 558), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 164 has weird spacing: '...ionship trust...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (April 2005) is 6245 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) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-01 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta 3 Internet Draft I. Guardini 4 Expires: Ocotber 29 2005 E. Demaria 5 TILab 6 J. Bournelle 7 GET/INT 8 R. Lopez 9 Univ. of Murcia 10 April 2005 12 Goals for AAA-HA interface 13 draft-ietf-mip6-aaa-ha-goals-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on October 29, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 In commercial deployments Mobile IPv6 can be a service offered by a 47 Mobility Services Provider (MSP). In this case all protocol 48 operations may need to be explicitely authorized and traced. A 49 convenient approach to do that is to define an interface between the 50 Home Agent (HA) and the AAA infrastructure of the MSP, which stores 51 user's credentials and service profiles. The availability of this 52 interface can be useful also to enable dynamic Mobile IPv6 53 This document describes various scenarios where an interface between 54 the HA and the AAA infrastructure of the MSP is required. 55 Furthermore, a list of design goals for this interface is provided. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [1]. 63 Table of Contents 65 1. Introduction................................................3 66 2. Motivation..................................................4 67 3. Basic security model........................................5 68 4. Bootstrapping scenarios.....................................6 69 4.1 Scenario 1...............................................6 70 4.2 Scenario 2...............................................6 71 4.3 Scenario 3...............................................7 72 4.4 Scenario 4...............................................8 73 5. Goals for the AAA-HA interface..............................9 74 5.1 General goals............................................9 75 5.2 Service Authorization....................................9 76 5.3 Accounting..............................................10 77 5.4 Mobile Node Authentication..............................10 78 5.5 Provisioning of configuration parameters................10 79 6. Mapping between goals and scenarios........................11 80 7. IANA Considerations........................................12 81 8. Security Considerations....................................13 82 9. Acknowledgment.............................................14 83 10. References.................................................15 84 10.1 Normative References..................................15 85 10.2 Informative References................................15 86 AuthorsĘ Addresses..............................................16 87 1. Introduction 89 Mobile IPv6 [2] was originally designed as a standalone protocol to 90 handle terminal mobility relying on a centralized and pre-configured 91 Home Agent (HA). Nonetheless, if Mobile IPv6 is a service offered by 92 a Mobility Services Provider (MSP), all protocol operations may need 93 to be explicitely authorized and traced (e.g. for accounting 94 purposes). A convenient approach to achieve this result is to define 95 an interface between the AAA infrastructure of the MSP and the HA. 96 Such an interface may be useful also in some Mobile IPv6 dynamic 97 bootstrapping scenarios [3]. 99 This document describes various scenarios for which an interface 100 between the HA and the AAA infrastructure of the MSP is useful. 101 Furthermore, a list of goals for such an interface is provided. 103 No assumptions are made on the protocol used to implement the 104 interface. An obvious choice may be the employment of a AAA protocol 105 such as RADIUS or Diameter. Nonetheless, for some scenarios, other 106 non AAA protocols such as SNMPv3 [5] or COPS-PR [6] may satisfy all 107 the goals described herewith. 109 2. Motivation 111 Mobile IPv6 specification [2] requires that Mobile Nodes (MNs) are 112 provisioned with a set of configuration parameters, namely the Home 113 Address and the Home Agent Address, in order to accomplish a home 114 registration. Moreover MNs and Home Agents (HAs) must share the 115 cryptographic material needed to protect Mobile IPv6 signaling (e.g. 116 shared keys or certificates to setup an IPsec security association). 118 The simplest option is to statically provision all the necessary 119 configuration data on MNs and HAs. This solution raises obvious 120 scalability issues especially in a large network with a lot of users 121 (e.g. a mobile operator network). For this reason the dynamic Mobile 122 IPv6 bootstrapping problem is currently under study [3]. 124 In case Mobile IPv6 is a service offered by a Mobility Service 125 Provider (MSP) all protocol operations (e.g. home registrations) may 126 need to be explicitely authorized and monitored (e.g. for accounting 127 purposes). This can be accomplished relying on the AAA 128 infrastructure of the MSP, that stores users' service profiles and 129 credentials. 131 The deployment of this service model requires the availability of an 132 interface between the AAA infrastructure and the HA, that can be 133 seen as the Network Access Server (NAS) for Mobile IPv6. The core 134 capabilities that should be supported by this interface include 135 Mobile IPv6 service authorization and maintenance (e.g. asynchronous 136 service termination) as well as the exchange of accounting data. 137 This is the basic set of features needed in any Mobile IPv6 138 bootstrapping scenario (i.e. static or dynamic). 140 Moreover, whenever static provisioning is not feasible, the AAA 141 infrastructure of the MSP can be used as the central element to 142 build a dynamic Mobile IPv6 bootstrapping solution. In this case the 143 AAA infrastructure can be exploited also to send to the designated 144 HA the needed configuration parameters (e.g. keying material) as 145 well as to assist the HA with mobile node authentication. 147 There is therefore space for the definition of a general AAA-HA 148 communication interface capable to support the basic features 149 described above (e.g. authorization and accounting) as well as the 150 extended capabilities (e.g. transfer of configuration data) needed 151 to enable various dynamic Mobile IPv6 bootstrapping scenarios. 153 3. Basic security model 155 The basic security model behind this draft assumes that the mobile 156 node shares a pre-configured trust relationship with the AAA server 157 of the MSP (AAAH), as stated in [3]. Furthermore the HA is expected 158 to share a trust relationship with the AAAH server (see Figure 1). 160 MN AAAH HA 161 ^ ^ ^ ^ 162 | | | | 163 +----------------+ +---------------+ 164 trust relationship trust relationship 166 Figure 1 - Basic Model 167 4. Bootstrapping scenarios 169 This section describes some bootstrapping scenarios in which a 170 communication between the AAA infrastructure of the Mobility Service 171 Provider and the Home Agent is needed. These scenarios include both 172 dynamic (Scenario 1 and Scenario 2) and static (Scenario 3 and 173 Scenario 4) bootstrapping. 175 4.1 Scenario 1 177 In this scenario, depicted in Figure 2, the MN discovers the Home 178 Agent address (e.g. by means of a new DNS SRV record or DHCP) and 179 performs an IKEv2 [4] exchange with the HA to setup the IPsec SA 180 needed to protect mobility signaling. Eventually, during this 181 handshake, the MN can also obtain a valid Home Address from the HA. 183 The MN is not expected to share a pre-configured trust relationship 184 with the HA, nor to share a secret with it. For this reason, peer 185 authentication in IKEv2 can be performed through an EAP exchange. 186 The HA, behaving as an EAP authenticator operating in pass-through 187 mode, forwards this EAP exchange to the AAAH server, that can 188 authenticate the MN and authorize the Mobile IPv6 service. 189 Therefore, in this case an interface between the HA and the AAAH 190 server is needed at least for authentication and authorization 191 purposes. 193 MN AAAH HA 195 <---------- IKEv2(EAP) --------> 197 <---------> 198 AAA-HA protocol 200 Figure 2 - Dynamic MIPv6 bootstrapping through IKEv2 and EAP 202 4.2 Scenario 2 204 In this scenario Mobile IPv6 bootstrapping is performed during 205 network access authentication (it is assumed that the access 206 provider and the MSP are the same entity, i.e. Integrated ASP [3]) 207 and the AAA server of the MSP (AAAH) controls the whole 208 bootstrapping procedure interacting with both the mobile node and 209 the designated HA. 211 The AAAH server and the MN can exploit AAA routing to exchange 212 configuration data. Possible approaches to implement this 213 communication are the following: 215 - if network access authentication is carried out using EAP, it is 216 possible to piggyback Mobile IPv6 configuration parameters (e.g. 218 Home Agent address, Home Address) within the EAP exchange [7]. See 219 Figure 3; 221 - alternatively, Mobile IPv6 parameters can be transferred to the 222 Network Access Server (NAS) by means of RADIUS or Diameter AVPs 223 [8] and then forwarded to the MN through other means (e.g. L2- 224 specific extensions, DHCP [9]). See Figure 4 for an example. 226 In both cases, the AAAH server must communicate with the designated 227 HA to select a suitable Home Address for the MN and to deliver to 228 the HA the necessary configuration parameters (e.g. pre-shared key 229 for IKE bootstrapping). Therefore in this scenario an interface 230 between the AAAH server and the HA must be defined for parameter 231 exchange as well as authentication and Mobile IPv6 service 232 authorization. 234 MN AAAH HA 235 <------------------------> <--------> 236 Piggybacking of MIPv6 AAA-HA protocol 237 data within EAP 239 Figure 3 - MIPv6 bootstrapping with piggybacking within EAP 241 MN NAS AAAH HA 242 <----------> <---------> <--------> 243 L2-specific MIPv6 AAA-HA protocol 244 extensions RADIUS AVPs 246 Figure 4 - MIPv6 bootstrapping with RADIUS AVPs 248 4.3 Scenario 3 250 In this scenario the MN is statically provisioned with the data 251 needed to bootstrap Mobile IPv6 service (i.e. Home Agent Address, 252 Home Address and a shared secret with the HA). For example, the MN 253 can be configured with a pre-shared key to dynamically establish an 254 IPsec Security Association with the HA using IKE. 256 However, in general the static configuration of these parameters and 257 the authentication performed through the pre-shared key may not be 258 sufficient to conclude that the MN is authorized for MIPv6 service. 259 For example, the MSP might want to prevent the usage of MIPv6 if the 260 the credit of the MN is going to exhaust. Moreover, there might be 261 the need for the MSP to enforce more complex dynamic authorization 262 policies based on time of day and/or visited location. 264 This implies that during the IKE exchange the HA must communicate 265 with the AAAH server in order to explicitly authorize MIPv6 service 266 for that particular MN. See Figure 5. 268 MN AAAH HA 270 <-------------- IKE ------------> 272 <-----------> 273 AAA-HA protocol 275 Figure 5 - Mobile IPv6 authorization with static boostrapping 277 4.4 Scenario 4 279 In this scenario, the IPsec SA between MN and HA is statically and 280 manually configured, thus the MN does not need to perform an IKE 281 exchange with the HA. The MN activates MIPv6 service, sending a 282 Binding Update message to the HA in order to update its location. 284 The presence of the IPsec SA between MN and HA is enough in order to 285 authenticate the binding management messages. However, it is not 286 enough to authorize MIPv6 service; thus, as soon as it receives a 287 Binding Update, the HA must explicitly authorize MIPv6 service 288 interacting with the AAAH server (Figure 6). For this purpose, an 289 interface between the HA and the AAAH is needed at least for 290 authorization purposes. 292 If deemed necessary, the explicit authorization of Binding Updates 293 based on the handshake depicted in Figure 5 can be used also in the 294 bootstrapping scenarios described in the previous sections. It may 295 be useful to enforce dynamic authorization policies, such as those 296 based on the MN's location. 298 MN AAAH HA 300 ------------ BU ------------> 302 <-----------> 303 AAA-HA protocol 305 <----------- BA ------------- 307 Figure 6 - Binding Update Authorization 308 5. Goals for the AAA-HA interface 310 The motivations and scenarios illustrated in previous sections raise 311 the need to define an interface between the AAAH server and the HA. 312 The following sections list a set of goals for this interface. 314 5.1 General goals 316 G1.1 The AAAH server and the HA must be able to authenticate each 317 other (mutual authentication) in order to prevent the 318 installation of unauthorized state on the HA. 320 G1.2 The AAA-HA interface must provide integrity protection in 321 order to prevent any alteration of exchanged data (e.g. Mobile 322 IPv6 configuration parameters). 324 G1.3 The AAA-HA interface must provide replay protection. 326 G1.4 The AAA-HA interface should provide confidentiality since it 327 may be used to transfer security parameters (e.g. IKE pre- 328 shared key). 330 G1.5 The AAA-HA interface should support inactive peer detection. 331 This functionality can be used by the AAAH server to maintain 332 a list of active HAs (e.g. useful for HA selection). 334 5.2 Service Authorization 336 G2.1 The AAA-HA interface should allow the use of Network Access 337 Identifier (NAI) to identify the mobile node. 339 G2.2 The HA should be able to query the AAAH server to verify 340 Mobile IPv6 service authorization for the mobile node. 342 G2.3 The AAAH server should be able to enforce explicit operational 343 limitations and authorization restrictions on the HA (e.g. 344 packet filters, QoS parameters). 346 G2.4 The AAAH server should be able to send an authorization 347 lifetime to the HA to limit Mobile IPv6 session duration for 348 the MN. 350 G2.5 The HA should be able to request to the AAAH server an 351 extension of the authorization lifetime granted to the MN. 353 G2.6 The AAAH server should be able to force the HA to terminate an 354 active Mobile IPv6 session for authorization policy reasons 355 (e.g. credit exhaustion). 357 G2.7 The AAAH server should be able to retreive the Mobile IPv6 358 state associated to a specific MN from the correspondent HA. 359 This may be useful to periodically verify the Mobile IPv6 360 service status. 362 5.3 Accounting 364 G3.1 The AAA-HA interface must support the transfer of accounting 365 records needed for service control and charging. These include 366 (but may not be limited to): time of binding cache entry 367 creation and deletion, octets sent and received by the mobile 368 node in Bi-directional Tunneling, etc. 370 5.4 Mobile Node Authentication 372 G4.1 The AAA-HA interface should support MN authentication (and re- 373 authentication) with the HA working as NAS and the AAAH server 374 working as back-end authentication server. 376 G4.2 The AAA-HA interface should support at least pass-through EAP 377 authentication with the HA working as EAP authenticator 378 operating in pass-through mode and the AAAH server working as 379 back-end authentication server. 381 5.5 Provisioning of configuration parameters 383 G5.1 The AAAH server should be able to poll the designated HA for 384 the allocation of a Home Address to the MN. Optionally, the 385 AAAH server can provide a set of hints for the construction of 386 the Home Address (e.g. a preferred Home Address or a preferred 387 Interface Identifier). 389 G5.2 The HA should be able to communicate to the AAAH server the 390 Home Address allocated to the MN. 392 G5.3 The AAAH server should be able to send to the HA the security 393 data needed to setup the IPsec SA between the MN and the HA. 394 Possible security data are the authentication method and the 395 cryptographic material to be used for IKE bootstrapping. 397 6. Mapping between goals and scenarios 399 The table below shows which goals, among those listed in section 5, 400 are strictly (X) or optionally (O) required for each of the 401 scenarios discussed in section 4. 403 Section +---------------------------------------+ 404 Defined Goals | Scen. 1 | Scen. 2 | Scen. 3 | Scen. 4 | 405 -------------------+---------|---------|---------|---------| 406 G1.1 | X | X | X | X | 407 G1.2 | X | X | X | X | 408 5.1 G1.3 | X | X | X | X | 409 G1.4 | O | X | O | O | 410 G1.5 | X | X | X | X | 411 -------------------|---------|---------|---------|---------| 412 G2.1 | X | X | O | O | 413 G2.2 | X | X | X | X | 414 G2.3 | X | X | X | X | 415 5.2 G2.4 | X | X | X | X | 416 G2.5 | X | X | X | X | 417 G2.6 | X | X | X | X | 418 G2.7 | X | X | X | X | 419 -------------------|---------|---------|---------|---------| 420 5.3 G3.1 | X | X | X | X | 421 -------------------|---------|---------|---------|---------| 422 5.4 G4.1 | X | | | | 423 G4.2 | X | | | | 424 -------------------|---------|---------|---------|---------| 425 G5.1 | | X | | | 426 5.5 G5.2 | | X | | | 427 G5.3 | | X | | | 428 -------------------+---------+---------+---------+---------+ 429 7. IANA Considerations 431 No new message formats or services are defined in this document. 433 8. Security Considerations 435 As stated in section 5.1 the AAA-HA interface must provide mutual 436 authentication, integrity and replay protection. Furthermore, if 437 security parameters (e.g. IKE pre-shared key) are transferred 438 through this interface, confidentiality support is also required. 440 9. Acknowledgment 442 The authors would like to thank James Kempf, Alper Yegin, Vijay 443 Devarapalli, Basavaraj Patil, Gopal Dommety and Hannes Tschofenig 444 for their comments and feedback. 446 10. References 448 10.1 Normative References 450 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 451 Levels", BCP 14, RFC 2119, March 1997. 453 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 454 IPv6", RFC 3775, June 2004. 456 10.2 Informative References 458 [3] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6", 459 draft-ietf-mip6-bootstrap-ps-02 (work in progress), March 2005. 461 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 462 draft-ietf-ipsec-ikev2-17 (work in progress), September 2004. 464 [5] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 465 Applicability Statements for Internet-Standard Management 466 Framework", RFC 3410, December 2002. 468 [6] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 469 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for 470 Policy Provisioning,", RFC 3084, March 2001. 472 [7] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent- 473 Maknavicius, M., "MIPv6 Authorization and Configuration based on 474 EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), 475 September 2004. 477 [8] Chowdhury, K. and Lior, A., "RADIUS Attributes for Mobile IPv6 478 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in 479 progress), October 2004. 481 [9] Jang, H. J. and Yegin, A., "DHCP Option for Home Agent Discovery in 482 MIPv6", draft-jang-dhc-haopt-01 (work in progress), April 2005. 484 AuthorsĘ Addresses 486 Gerardo Giaretta 487 Telecom Italia Lab 488 via G. Reiss Romoli, 274 489 10148 TORINO 490 Italy 491 Phone: +39 011 2286904 492 Email: gerardo.giaretta@tilab.com 494 Ivano Guardini 495 Telecom Italia Lab 496 via G. Reiss Romoli, 274 497 10148 TORINO 498 Italy 499 Phone: +39 011 2285424 500 Email: ivano.guardini@tilab.com 502 Elena Demaria 503 Telecom Italia Lab 504 via G. Reiss Romoli, 274 505 10148 TORINO 506 Italy 507 Phone: +39 011 2285403 508 Email: elena.demaria@tilab.com 510 Julien Bournelle 511 GET/INT 512 9 rue Charles Fourier 513 Evry 91011 514 France 515 Email: julien.bournelle@int-evry.fr 517 Rafa Marin Lopez 518 University of Murcia 519 30071 Murcia 520 Spain 521 EMail: rafa@dif.um.es 522 Intellectual Property Statement 524 The IETF takes no position regarding the validity or scope of any 525 Intellectual Property Rights or other rights that might be claimed 526 to pertain to the implementation or use of the technology described 527 in this document or the extent to which any license under such 528 rights might or might not be available; nor does it represent that 529 it has made any independent effort to identify any such rights. 530 Information on the procedures with respect to rights in RFC 531 documents can be found in BCP 78 and BCP 79. 533 Copies of IPR disclosures made to the IETF Secretariat and any 534 assurances of licenses to be made available, or the result of an 535 attempt made to obtain a general license or permission for the use 536 of such proprietary rights by implementers or users of this 537 specification can be obtained from the IETF on-line IPR repository 538 at http://www.ietf.org/ipr. 540 The IETF invites any interested party to bring to its attention any 541 copyrights, patents or patent applications, or other proprietary 542 rights that may cover technology that may be required to implement 543 this standard. Please address the information to the IETF at ietf 544 ipr@ietf.org 546 Disclaimer of Validity 548 This document and the information contained herein are provided on 549 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 550 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 551 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 552 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 553 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 556 Copyright Statement 558 Copyright (C) The Internet Society (2005). 560 This document is subject to the rights, licenses and restrictions 561 contained in BCP 78, and except as set forth therein, the authors 562 retain all their rights. 564 Acknowledgment 566 Funding for the RFC Editor function is currently provided by the 567 Internet Society.