idnits 2.17.1 draft-tschofenig-dime-mip6-split-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 485. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 59: '...etection - the HA-AAA interface SHOULD...' RFC 2119 keyword, line 62: '...HA-AAA interface SHOULD allow the use ...' RFC 2119 keyword, line 65: '...2. G2.2. The HA SHOULD be able to que...' RFC 2119 keyword, line 68: '... The AAAH server SHOULD be able to enf...' RFC 2119 keyword, line 77: '... The AAAH server SHOULD be able to ret...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 75 has weird spacing: '...xplicit sessi...' == Line 212 has weird spacing: '...xplicit sessi...' -- 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 27, 2006) is 6631 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: '6' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 411, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (ref. '2') (Obsoleted by RFC 7155) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-01 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintanence and H. Tschofenig 3 Extensions (DIME) Siemens 4 Internet-Draft T. Tsenov 5 Expires: August 31, 2006 6 G. Giaretta 7 TILab 8 J. Bournelle 9 GET/INT 10 February 27, 2006 12 Mobile IPv6 Bootstrapping using Diameter in the Split Scenario 13 draft-tschofenig-dime-mip6-split-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 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 August 31, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 In Mobile IPv6 deployment a need for an interaction between the Home 47 Agent, the AAA infrastructure of the Mobile Service Provider (MSP) 48 and the Mobility Service Authorizer (MSA) has been identified. This 49 document provides a description of the functionality that allows to 50 meet the goals outlined in the MIPv6 AAA Goals document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. General goals . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 5 59 3.1.2. Dead peer detection - the HA-AAA interface SHOULD 60 support inactive peer detection. . . . . . . . . . . . 5 61 3.2. Service Authorization . . . . . . . . . . . . . . . . . . 5 62 3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of 63 Network Access Identifier (NAI) to identify the 64 mobile node. . . . . . . . . . . . . . . . . . . . . . 5 65 3.2.2. G2.2. The HA SHOULD be able to query the AAAH 66 server to verify Mobile IPv6 service authorization 67 for the mobile node. . . . . . . . . . . . . . . . . . 6 68 3.2.3. G2.3. The AAAH server SHOULD be able to enforce 69 explicit operational limitations and authorization 70 restrictions on the HA.( e.g. packet filters, QoS 71 parameters). . . . . . . . . . . . . . . . . . . . . . 6 72 3.2.4. G2.4 - G2.6. Issues addressing the maintenance of 73 a Mobile IPv6 session by the AAAH server, e.g. 74 authorization lifetime, extension of the 75 authorization lifetime and explicit session 76 termination by the AAAH server side. . . . . . . . . . 6 77 3.2.5. G2.7. The AAAH server SHOULD be able to retrieve 78 the Mobile IPv6 state associated to a specific MN 79 from the correspondent HA. This MAY be useful to 80 periodically verify the Mobile IPv6 service status. . 7 81 3.3. Accounting - G3.1. The HA-AAA interface MUST support 82 the transfer of accounting records needed for service 83 control and charging . . . . . . . . . . . . . . . . . . . 7 84 3.4. Mobile Node Authentication (G4.1. and G4.2.) . . . . . . . 7 85 3.5. Provisioning of configuration parameters . . . . . . . . . 8 86 4. Bootstrapping Mobile IPv6 in the split scenario . . . . . . . 9 87 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 Intellectual Property and Copyright Statements . . . . . . . . . . 17 96 1. Introduction 98 In Mobile IPv6 deployment, authentication, authorization and 99 accounting issues in the protocol operations are approached by using 100 the AAA infrastructure. The [8] document presents a number of 101 bootstrapping scenarios using the HA-AAA interface and defines a list 102 of requirements that this interface should cover. This document 103 deals with the functional capabilities of the Diameter protocol as a 104 AAA protocol applicable for the split scenario. 106 Currently, two Mobile IPv6 bootstrapping solutions exist. In the 107 split scenario, only a HA-AAA interface is considered whereas in the 108 integrated scenario both NAS-AAA and HA-AAA interface need to be 109 addressed. 111 This document focuses only on the split scenario. A separate 112 document describes a Diameter application for bootstrapping MIPv6 for 113 the integrated scenario. 115 2. Motivation 117 Designed to cover network access requirements for AAA protocols [1], 118 Diameter protocol provides a framework for applications offering AAA 119 services. This design approach gives to the protocol extensibility, 120 interoperability and flexibility in offering AAA solutions in 121 comparison to other AAA protocols. Support of definition of new 122 application Ids, commands and AVPs provides extensibility. 123 Recommended re-use of commands and AVPs and careful consideration of 124 the level of AVP's support provides interoperability. Usage of IPsec 125 and TLS for transport hop-by-hop security, possible support for AVP 126 integrity and confidentiality and usage of peer-to-peer model (any 127 Diameter node can initiate a request message) provide flexibility of 128 the Diameter AAA applications to fit to specific requirements. 130 In the following sections we try to specify by which means a possible 131 Diameter application would cover the requirements for the HA-AAA 132 interface specified in [8]. 134 3. Goals 136 In presentation of the analysis of goals and possible design 137 solutions by Diameter we follow the classification, labels and naming 138 assigned in the document [8], where these goals are identified. 139 Since several of the issues MIGHT be addressed in similar way or by 140 similar Diameter functionality, we have grouped these issues and have 141 given a general description of the groups. 143 3.1. General goals 145 3.1.1. G1.1 - G1.4 Security 147 As design goals for an AAA interface, G1.1 - G1.4 goals specify 148 standard requirements for a AAA protocol - mutual authentication of 149 the peers, integrity, replay protection and confidentiality. IPsec 150 or TLS provide the hop-by-hop security. Combined, they SHOULD be 151 able to provide the range of security services required for the HA- 152 AAA interface. 154 3.1.2. Dead peer detection - the HA-AAA interface SHOULD support 155 inactive peer detection. 157 Two possible approaches MIGHT be considered here: 159 o AAAH server and Home Agent establish a transport connection 160 between each other. In this case Diameter heartbeat messages 161 called Watch-Dog-Request/Answer, which are exchanged over this 162 connection to test for its aliveness, MAY be used to detect 163 inactivity in any of the two Diameter peers. 165 o AAAH server and Home Agent do not have transport connection. In 166 this case inactive peer detection functionality SHOULD be provided 167 into the Diameter session - service stateless Diameter sessions 168 MIGHT be established between the AAAH server and the range of 169 MSP's Home Agents for detecting HAs availability. 171 3.2. Service Authorization 173 3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network 174 Access Identifier (NAI) to identify the mobile node. 176 Identification by User-Name AVP [1], which has a format consistent 177 with the NAI specifications, is common for Diameter applications. 178 Diameter provides functionality for routing of Diameter requests 179 based on the information included in the User-Name AVP. 181 3.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify 182 Mobile IPv6 service authorization for the mobile node. 184 Based on the peer-to-peer model, Diameter design gives the 185 functionality that any Diameter node can initiate a request message. 186 This, combined with the support of EAP, would provide flexible 187 solutions for this issue. Currently several Diameter application 188 standardized or under work-in-progress address different types of 189 authorization - network access [2], credit control [9], quality of 190 service [10]. This MIGHT allow re-use of present AVPs over the 191 AAAH-HA interface. 193 3.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit 194 operational limitations and authorization restrictions on the 195 HA.( e.g. packet filters, QoS parameters). 197 Several present Diameter applications, standardized or under work-in- 198 progress address an operation and authorization control over specific 199 services and have defined appropriate AVPs. NAS-Filter-Rule AVP, 200 defined by Diameter NASREQ application [2], provides IP packet filter 201 description. QoS-Filter-Rule AVP defined by Diameter NASREQ 202 application and QSPEC AVP defined by Diameter QoS Authorization [10] 203 provide QoS parameter description. Credit Control application [9] 204 provides cost control over requested services. AVPs MAY be re-used 205 for providing required functionality over the AAAH-HA interface. 206 This, combined with the possibility that any node can initiate 207 request message, gives control to the AAAH server over HA's 208 functionality. 210 3.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 211 session by the AAAH server, e.g. authorization lifetime, 212 extension of the authorization lifetime and explicit session 213 termination by the AAAH server side. 215 Diameter base protocol provides a powerful set of commands and AVPs 216 for management of the authorization and accounting sessions. A 217 number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout- 218 AVP) handle the duration (in time) of an authorization session [1]. 219 Additional AVPs for measuring the authorization duration in units 220 different that time are specified too [9]. Exchanging of application 221 specific authorization request/answer messages provides extension of 222 the authorization session. Initiation of the re-authorization by 223 both sides could be supported. Both sides could initiate session 224 termination, by using Diameter Session Termination and Abort Session 225 messages. 227 All these are applied to the Diameter session used for authorization 228 of a Mobile IPv6 session and need to be applied appropriately to this 229 Mobile IPv6 session too. 231 3.2.5. G2.7. The AAAH server SHOULD be able to retrieve the Mobile IPv6 232 state associated to a specific MN from the correspondent HA. 233 This MAY be useful to periodically verify the Mobile IPv6 234 service status. 236 This issue has two sides: 238 1. How the AAAH SHOULD know which HA to contact to retrieve current 239 status of MN's Mobile IPv6 service in case of stateless MSP 240 architecture and several servicing AAA servers? - As analyzed 241 into the [11], this need would be required for re-authorization 242 and in this case the provision of HA info could be provided from 243 the MN during the re-authentication session between NM and AAAH 244 server. 246 2. Once having the HA info, AAAH SHOULD contact it to verify the 247 status of MN's Mobile IPv6 service. - This could be performed by 248 Request/Response messages initiated by the AAAH server. This 249 functionality is supported by the Diameter protocol and currently 250 is applied into Diameter SIP application for updating user 251 profiles at Diameter client (i.e., SIP server). 253 3.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer 254 of accounting records needed for service control and charging 256 Diameter accounting protocol provides a variety of options - real- 257 time accounting, event/session-type accounting records, fault 258 resilience, correlation of accounting records. Requirements for the 259 accounting services over AAAH-HA interface are standard. Definition 260 or re-used of AVPs for the specific accounting records combined with 261 the functionality of the Diameter accounting protocol SHOULD provide 262 desired accounting services. 264 3.4. Mobile Node Authentication (G4.1. and G4.2.) 266 These issues require the functionality of AAAH server working as a 267 back-end authentication server and HA working as NAS and EAP 268 authenticator in pass-through mode for providing a mobile node 269 authentication. These functionalities are provided by Diameter 270 NASREQ and EAP applications, and MIGHT be re-used at the AAAH-AH 271 interface.[2], [3] 273 3.5. Provisioning of configuration parameters 275 Issues G5.1 - G5.3 are related to capability of exchanging and 276 negotiating of operational parameters for Mobile IPv6 protocol 277 bootstrapping and providing appropriate security level for this 278 information. 280 Diameter provides secure transport by means of IPsec, TLS and 281 possible AVPs integrity and confidentiality support (currently with 282 no interest from the community). Several AVPs could be re-used for 283 carrying the operational parameters for the Mobile IPv6 284 bootstrapping. Framed-IPv6-Prefix AVP, Login-IPv6-Host AVP, Framed- 285 Interface-Id AVP, Framed-IPv6-Route AVP defined by NASREQ MIGHT be 286 used for home address provision and AVPs defined in EAP application 287 MIGHT be used for key transport [3]. 289 4. Bootstrapping Mobile IPv6 in the split scenario 291 In the split scenario for bootstrapping Mobile IPv6 [4], the MN 292 discovers HA through DNS mechanism. Then it uses IKEv2 [5] to setup 293 IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus 294 the MN. As such, the MN can use its credentials (obtained from the 295 MSA) to be authenticated for the IPv6 mobility service. The HA MAY 296 rely on a EAP server co-located on a AAA server for this purpose. In 297 this case, a HA-AAA interface is needed. This interface MUST support 298 transport of EAP packets. 300 +----+ IKEv2 +----+ Diameter EAP +---+ 301 | MN |<----------->| HA |<-------------------->|AAA| 302 +----+ +----+ +---+ 304 Figure 1: Diameter EAP as the HA-AAA interface in Split scenario 306 For this purpose, the HA can use Diameter EAP Application [3] (cf. 307 Figure 1). As shown in the previous section, this protocol fulfill 308 goals described in [8] 309 MN HA AAAH 310 -- -- ---- 311 IKE_SA_INIT 312 <------------------------------> 314 HDR, SK{IDi,[CERTREQ,] [IDr,] 315 SAi2, TSi, TSr} 316 -------------------------------> 317 DER (EAP-Response) 318 ------------------------> 319 DEA (EAP-Request) 320 <------------------------ 321 HDR, SK {IDr, [CERT,] AUTH, 322 EAP } 323 <------------------------------- 324 HDR, SK {EAP} 325 --------------------------------> 326 DER (EAP-Response) 327 ------------------------> 328 DEA (EAP-Request) 329 <------------------------ 330 HDR, SK{EAP-Request} 331 <------------------------------- 332 HDR, SK{EAP-Response} 333 --------------------------------> 334 DER (EAP-Response) 335 ------------------------> 336 ... ... 338 DEA (EAP-Success) 339 <------------------------ 340 HDR, SK{EAP-Success} 341 <------------------------------- 342 HDR, SK{AUTH} 343 -------------------------------> 344 HDR, SK {AUTH, SAr2, TSi, TSr } 345 <------------------------------- 347 Figure 2: IKEv2 Diameter EAP 349 MN and HA start with an IKE_SA_INIT to setup the IKE SA. The MN 350 indicates its desire to use EAP by not including the AUTH payload in 351 the third message. However it indicates its identity (e.g. NAI) by 352 using the IDi field. If the HA supports EAP for authentication, it 353 forwards the identity to the AAAH by sending a Diameter-EAP-Request 354 (DER) message containing the identity in the EAP-Payload AVP and in 355 the User-Name AVP. Based on this identity, the AAAH chooses an 356 authentication method and sends the first EAP-Request in the 357 Diameter-EAP-Answer message. During the EAP authentication phase, 358 the HA relays EAP packets between the MN and the AAAH. If the 359 authentication succeeds and if the MN is authorized to use Mobile 360 IPv6 service, the AAAH sends a DEA message containing the EAP-success 361 and the AAA-Key derived from the EAP authentication method . Note 362 that EAP authentication methods that do not derive keys are not 363 recommended. This key is used by both MN and HA to generate the AUTH 364 payload. In the latter message, MN and HA finish to setup IPsec SAs 365 for Mobile IPv6. 367 5. Security considerations 369 [Editor's Note: Since the document is not complete it is necessary to 370 state that the security consideration section is incomplete as well. 371 Hence, it is only possible to refer to the security issues raised in 372 the Mobile IPv6 and Diameter protocol related documents mentioned 373 here, such as [11], [8] and [1].] 375 6. IANA Considerations 377 The AVP code for the Home-Agent AVP needs to be allocated. 379 7. Acknowledgements 381 We would like to thank the MIPv6 Bootstrapping Design Team for their 382 comments. Additionally, we would like to thank Junghoon Jee for his 383 feedback. 385 8. References 387 8.1. Normative References 389 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 390 "Diameter Base Protocol", RFC 3588, September 2003. 392 [2] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 393 Network Access Server Application", RFC 4005, August 2005. 395 [3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 396 Authentication Protocol (EAP) Application", RFC 4072, 397 August 2005. 399 [4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 400 draft-ietf-mip6-bootstrapping-split-01 (work in progress), 401 October 2005. 403 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 404 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 406 [6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 407 the Integrated Scenario", 408 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 409 progress), October 2005. 411 [7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network 412 Services", BCP 17, RFC 2219, October 1997. 414 8.2. Informative References 416 [8] Giaretta, G., "Goals for AAA-HA interface", 417 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 418 January 2006. 420 [9] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 421 Hakala, "Diameter Credit-control Application", 422 draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. 424 [10] Alfano, F., "Diameter Quality of Service Application", 425 draft-alfano-aaa-qosprot-05 (work in progress), October 2005. 427 [11] Giaretta, G., "MIPv6 Authorization and Configuration based on 428 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 429 progress), October 2004. 431 Authors' Addresses 433 Hannes Tschofenig 434 Siemens 435 Otto-Hahn-Ring 6 436 Munich, Bavaria 81739 437 Germany 439 Email: Hannes.Tschofenig@siemens.com 441 Tseno Tsenov 442 Sofia, 443 Bulgaria 445 Email: tseno.tsenov@mytum.de 447 Gerardo Giaretta 448 Telecom Italia Lab 449 via G. Reiss Romoli, 274 450 TORINO, 10148 451 Italy 453 Email: gerardo.giaretta@tilab.com 455 Julien Bournelle 456 GET/INT 457 9 rue Charles Fourier 458 Evry 91011 459 France 461 Email: julien.bournelle@int-evry.fr 463 Intellectual Property Statement 465 The IETF takes no position regarding the validity or scope of any 466 Intellectual Property Rights or other rights that might be claimed to 467 pertain to the implementation or use of the technology described in 468 this document or the extent to which any license under such rights 469 might or might not be available; nor does it represent that it has 470 made any independent effort to identify any such rights. Information 471 on the procedures with respect to rights in RFC documents can be 472 found in BCP 78 and BCP 79. 474 Copies of IPR disclosures made to the IETF Secretariat and any 475 assurances of licenses to be made available, or the result of an 476 attempt made to obtain a general license or permission for the use of 477 such proprietary rights by implementers or users of this 478 specification can be obtained from the IETF on-line IPR repository at 479 http://www.ietf.org/ipr. 481 The IETF invites any interested party to bring to its attention any 482 copyrights, patents or patent applications, or other proprietary 483 rights that may cover technology that may be required to implement 484 this standard. Please address the information to the IETF at 485 ietf-ipr@ietf.org. 487 Disclaimer of Validity 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 492 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 493 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 494 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Copyright Statement 499 Copyright (C) The Internet Society (2006). This document is subject 500 to the rights, licenses and restrictions contained in BCP 78, and 501 except as set forth therein, the authors retain all their rights. 503 Acknowledgment 505 Funding for the RFC Editor function is currently provided by the 506 Internet Society.