idnits 2.17.1 draft-tschofenig-mip6-aaa-ha-diameter-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** 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 65: '...etection - the HA-AAA interface SHOULD...' RFC 2119 keyword, line 68: '...HA-AAA interface SHOULD allow the use ...' RFC 2119 keyword, line 71: '...2. G2.2. The HA SHOULD be able to que...' RFC 2119 keyword, line 74: '... The AAAH server SHOULD be able to enf...' RFC 2119 keyword, line 83: '... The AAAH server SHOULD be able to ret...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 81 has weird spacing: '...xplicit sessi...' == Line 221 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 (October 23, 2005) is 6760 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: '7' is defined on line 488, 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-00 == Outdated reference: A later version (-05) exists of draft-alfano-aaa-qosprot-04 == 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 Mobility for IPv6 (mip6) H. Tschofenig 3 Internet-Draft T. Tsenov 4 Expires: April 26, 2006 Siemens 5 G. Giaretta 6 TILab 7 J. Bournelle 8 GET/INT 9 October 23, 2005 11 Mobile IPv6 Bootstrapping using Diameter 12 draft-tschofenig-mip6-aaa-ha-diameter-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 26, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Both Mobile IPv6 bootstrapping solutions require use of a AAA 46 interface. In the split scenario, this interface is between the Home 47 Agent and the AAA infrastructure of the Mobile Service Provider (MSP) 48 and the Mobility Service Authorizer (MSA). The first interface 49 should meet a list of requirements. This document provides an 50 overview of the capabilities and design of the Diameter protocol that 51 could meet the specified goals. In the integrated scenario, in 52 addition to this interface, the impact of the MIPv6 bootstrapping on 53 the AAA interface for network access authentication must be 54 considered. Basically, this interface is also used to carry Home 55 Agent information. This document defines the necessary AVP and how 56 Diameter can be used in the integrated scenario. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 6 65 3.1.2. Dead peer detection - the HA-AAA interface SHOULD 66 support inactive peer detection. . . . . . . . . . . . 6 67 3.2. Service Authorization . . . . . . . . . . . . . . . . . . 6 68 3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of 69 Network Access Identifier (NAI) to identify the 70 mobile node. . . . . . . . . . . . . . . . . . . . . . 6 71 3.2.2. G2.2. The HA SHOULD be able to query the AAAH 72 server to verify Mobile IPv6 service authorization 73 for the mobile node. . . . . . . . . . . . . . . . . . 7 74 3.2.3. G2.3. The AAAH server SHOULD be able to enforce 75 explicit operational limitations and authorization 76 restrictions on the HA.( e.g. packet filters, QoS 77 parameters). . . . . . . . . . . . . . . . . . . . . . 7 78 3.2.4. G2.4 - G2.6. Issues addressing the maintenance of 79 a Mobile IPv6 session by the AAAH server, e.g. 80 authorization lifetime, extension of the 81 authorization lifetime and explicit session 82 termination by the AAAH server side. . . . . . . . . . 7 83 3.2.5. G2.7. The AAAH server SHOULD be able to retrieve 84 the Mobile IPv6 state associated to a specific MN 85 from the correspondent HA. This MAY be useful to 86 periodically verify the Mobile IPv6 service status. . 8 87 3.3. Accounting - G3.1. The HA-AAA interface MUST support 88 the transfer of accounting records needed for service 89 control and charging . . . . . . . . . . . . . . . . . . . 8 90 3.4. Mobile Node Authentication (G4.1. and G4.2.) . . . . . . . 8 91 3.5. Provisioning of configuration parameters . . . . . . . . . 9 92 4. Bootstrapping Mobile IPv6 in the split scenario . . . . . . . 10 93 5. Bootstrapping Mobile IPv6 in the integrated scenario based 94 on DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.1. Home-Agent AVP . . . . . . . . . . . . . . . . . . . . . . 14 97 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 7. Security considerations . . . . . . . . . . . . . . . . . . . 16 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 105 Intellectual Property and Copyright Statements . . . . . . . . . . 21 107 1. Introduction 109 In Mobile IPv6 deployment, authentication, authorization and 110 accounting issues in the protocol operations are approached by using 111 the AAA infrastructure. The [8] document presents a number of 112 bootstrapping scenarios using the HA-AAA interface and defines a list 113 of requirements that this interface should cover. In the first part, 114 this document deals with the functional capabilities of the Diameter 115 protocol as a AAA protocol applicable at the discussed interface. 117 Currently, two Mobile IPv6 bootstrapping solutions exist depending on 118 the considered scenario. In the split scenario, only a HA-AAA 119 interface is considered whereas in the integrated scenario both NAS- 120 AAA and HA-AAA interface need to be addressed. This document 121 explains how to use Diameter and its EAP and NASREQ applications to 122 handle the AAA part of the both Mobile IPv6 bootstrapping solutions. 124 2. Motivation 126 Designed to cover network access requirements for AAA protocols [1], 127 Diameter protocol provides a framework for applications offering AAA 128 services. This design approach gives to the protocol extensibility, 129 interoperability and flexibility in offering AAA solutions in 130 comparison to other AAA protocols. Support of definition of new 131 application Ids, commands and AVPs provides extensibility. 132 Recommended re-use of commands and AVPs and careful consideration of 133 the level of AVP's support provides interoperability. Usage of IPsec 134 and TLS for transport hop-by-hop security, possible support for AVP 135 integrity and confidentiality and usage of peer-to-peer model (any 136 Diameter node can initiate a request message) provide flexibility of 137 the Diameter AAA applications to fit to specific requirements. 139 In the following sections we try to specify by which means a possible 140 Diameter application would cover the requirements for the HA-AAA 141 interface specified in [8]. 143 3. Goals 145 In presentation of the analysis of goals and possible design 146 solutions by Diameter we follow the classification, labels and naming 147 assigned in the document [8], where these goals are identified. 148 Since several of the issues MIGHT be addressed in similar way or by 149 similar Diameter functionality, we have grouped these issues and have 150 given a general description of the groups. 152 3.1. General goals 154 3.1.1. G1.1 - G1.4 Security 156 As design goals for an AAA interface, G1.1 - G1.4 goals specify 157 standard requirements for a AAA protocol - mutual authentication of 158 the peers, integrity, replay protection and confidentiality. IPsec 159 or TLS provide the hop-by-hop security. Combined, they SHOULD be 160 able to provide the range of security services required for the HA- 161 AAA interface. 163 3.1.2. Dead peer detection - the HA-AAA interface SHOULD support 164 inactive peer detection. 166 Two possible approaches MIGHT be considered here: 168 o AAAH server and Home Agent establish a transport connection 169 between each other. In this case Diameter heartbeat messages 170 called Watch-Dog-Request/Answer, which are exchanged over this 171 connection to test for its aliveness, MAY be used to detect 172 inactivity in any of the two Diameter peers. 174 o AAAH server and Home Agent do not have transport connection. In 175 this case inactive peer detection functionality SHOULD be provided 176 into the Diameter session - service stateless Diameter sessions 177 MIGHT be established between the AAAH server and the range of 178 MSP's Home Agents for detecting HAs availability. 180 3.2. Service Authorization 182 3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network 183 Access Identifier (NAI) to identify the mobile node. 185 Identification by User-Name AVP [1], which has a format consistent 186 with the NAI specifications, is common for Diameter applications. 187 Diameter provides functionality for routing of Diameter requests 188 based on the information included in the User-Name AVP. 190 3.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify 191 Mobile IPv6 service authorization for the mobile node. 193 Based on the peer-to-peer model, Diameter design gives the 194 functionality that any Diameter node can initiate a request message. 195 This, combined with the support of EAP, would provide flexible 196 solutions for this issue. Currently several Diameter application 197 standardized or under work-in-progress address different types of 198 authorization - network access [2], credit control [9], quality of 199 service [10]. This MIGHT allow re-use of present AVPs over the 200 AAAH-HA interface. 202 3.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit 203 operational limitations and authorization restrictions on the 204 HA.( e.g. packet filters, QoS parameters). 206 Several present Diameter applications, standardized or under work-in- 207 progress address an operation and authorization control over specific 208 services and have defined appropriate AVPs. NAS-Filter-Rule AVP, 209 defined by Diameter NASREQ application [2], provides IP packet filter 210 description. QoS-Filter-Rule AVP defined by Diameter NASREQ 211 application and QSPEC AVP defined by Diameter QoS Authorization [10] 212 provide QoS parameter description. Credit Control application [9] 213 provides cost control over requested services. AVPs MAY be re-used 214 for providing required functionality over the AAAH-HA interface. 215 This, combined with the possibility that any node can initiate 216 request message, gives control to the AAAH server over HA's 217 functionality. 219 3.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 220 session by the AAAH server, e.g. authorization lifetime, 221 extension of the authorization lifetime and explicit session 222 termination by the AAAH server side. 224 Diameter base protocol provides a powerful set of commands and AVPs 225 for management of the authorization and accounting sessions. A 226 number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout- 227 AVP) handle the duration (in time) of an authorization session [1]. 228 Additional AVPs for measuring the authorization duration in units 229 different that time are specified too [9]. Exchanging of application 230 specific authorization request/answer messages provides extension of 231 the authorization session. Initiation of the re-authorization by 232 both sides could be supported. Both sides could initiate session 233 termination, by using Diameter Session Termination and Abort Session 234 messages. 236 All these are applied to the Diameter session used for authorization 237 of a Mobile IPv6 session and need to be applied appropriately to this 238 Mobile IPv6 session too. 240 3.2.5. G2.7. The AAAH server SHOULD be able to retrieve the Mobile IPv6 241 state associated to a specific MN from the correspondent HA. 242 This MAY be useful to periodically verify the Mobile IPv6 243 service status. 245 This issue has two sides: 247 1. How the AAAH SHOULD know which HA to contact to retrieve current 248 status of MN's Mobile IPv6 service in case of stateless MSP 249 architecture and several servicing AAA servers? - As analyzed 250 into the [11], this need would be required for re-authorization 251 and in this case the provision of HA info could be provided from 252 the MN during the re-authentication session between NM and AAAH 253 server. 255 2. Once having the HA info, AAAH SHOULD contact it to verify the 256 status of MN's Mobile IPv6 service. - This could be performed by 257 Request/Response messages initiated by the AAAH server. This 258 functionality is supported by the Diameter protocol and currently 259 is applied into Diameter SIP application for updating user 260 profiles at Diameter client (i.e., SIP server). 262 3.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer 263 of accounting records needed for service control and charging 265 Diameter accounting protocol provides a variety of options - real- 266 time accounting, event/session-type accounting records, fault 267 resilience, correlation of accounting records. Requirements for the 268 accounting services over AAAH-HA interface are standard. Definition 269 or re-used of AVPs for the specific accounting records combined with 270 the functionality of the Diameter accounting protocol SHOULD provide 271 desired accounting services. 273 3.4. Mobile Node Authentication (G4.1. and G4.2.) 275 These issues require the functionality of AAAH server working as a 276 back-end authentication server and HA working as NAS and EAP 277 authenticator in pass-through mode for providing a mobile node 278 authentication. These functionalities are provided by Diameter 279 NASREQ and EAP applications, and MIGHT be re-used at the AAAH-AH 280 interface.[2], [3] 282 3.5. Provisioning of configuration parameters 284 Issues G5.1 - G5.3 are related to capability of exchanging and 285 negotiating of operational parameters for Mobile IPv6 protocol 286 bootstrapping and providing appropriate security level for this 287 information. 289 Diameter provides secure transport by means of IPsec, TLS and 290 possible AVPs integrity and confidentiality support (currently with 291 no interest from the community). Several AVPs could be re-used for 292 carrying the operational parameters for the Mobile IPv6 293 bootstrapping. Framed-IPv6-Prefix AVP, Login-IPv6-Host AVP, Framed- 294 Interface-Id AVP, Framed-IPv6-Route AVP defined by NASREQ MIGHT be 295 used for home address provision and AVPs defined in EAP application 296 MIGHT be used for key transport [3]. 298 4. Bootstrapping Mobile IPv6 in the split scenario 300 In the split scenario for bootstrapping Mobile IPv6 [4], the MN 301 discovers HA through DNS mechanism. Then it uses IKEv2 [5] to setup 302 IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus 303 the MN. As such, the MN can use its credentials (obtained from the 304 MSA) to be authenticated for the IPv6 mobility service. The HA MAY 305 rely on a EAP server co-located on a AAA server for this purpose. In 306 this case, a HA-AAA interface is needed. This interface MUST support 307 transport of EAP packets. 309 +----+ IKEv2 +----+ Diameter EAP +---+ 310 | MN |<----------->| HA |<-------------------->|AAA| 311 +----+ +----+ +---+ 313 Figure 1: Diameter EAP as the HA-AAA interface in Split scenario 315 For this purpose, the HA can use Diameter EAP Application [3] (cf. 316 Figure 1). As shown in the previous section, this protocol fulfill 317 goals described in [8] 318 MN HA AAAH 319 -- -- ---- 320 IKE_SA_INIT 321 <------------------------------> 323 HDR, SK{IDi,[CERTREQ,] [IDr,] 324 SAi2, TSi, TSr} 325 -------------------------------> 326 DER (EAP-Response) 327 ------------------------> 328 DEA (EAP-Request) 329 <------------------------ 330 HDR, SK {IDr, [CERT,] AUTH, 331 EAP } 332 <------------------------------- 333 HDR, SK {EAP} 334 --------------------------------> 335 DER (EAP-Response) 336 ------------------------> 337 DEA (EAP-Request) 338 <------------------------ 339 HDR, SK{EAP-Request} 340 <------------------------------- 341 HDR, SK{EAP-Response} 342 --------------------------------> 343 DER (EAP-Response) 344 ------------------------> 345 ... ... 347 DEA (EAP-Success) 348 <------------------------ 349 HDR, SK{EAP-Success} 350 <------------------------------- 351 HDR, SK{AUTH} 352 -------------------------------> 353 HDR, SK {AUTH, SAr2, TSi, TSr } 354 <------------------------------- 356 Figure 2: IKEv2 Diameter EAP 358 MN and HA start with an IKE_SA_INIT to setup the IKE SA. The MN 359 indicates its desire to use EAP by not including the AUTH payload in 360 the third message. However it indicates its identity (e.g. NAI) by 361 using the IDi field. If the HA supports EAP for authentication, it 362 forwards the identity to the AAAH by sending a Diameter-EAP-Request 363 (DER) message containing the identity in the EAP-Payload AVP and in 364 the User-Name AVP. Based on this identity, the AAAH chooses an 365 authentication method and sends the first EAP-Request in the 366 Diameter-EAP-Answer message. During the EAP authentication phase, 367 the HA relays EAP packets between the MN and the AAAH. If the 368 authentication succeeds and if the MN is authorized to use Mobile 369 IPv6 service, the AAAH sends a DEA message containing the EAP-success 370 and the AAA-Key derived from the EAP authentication method . Note 371 that EAP authentication methods that do not derive keys are not 372 recommended. This key is used by both MN and HA to generate the AUTH 373 payload. In the latter message, MN and HA finish to setup IPsec SAs 374 for Mobile IPv6. 376 5. Bootstrapping Mobile IPv6 in the integrated scenario based on DHCP 378 The Figure 3 represents the components and architecture of the Mobile 379 IPv6 bootstrapping solution in the integrated scenario. This figure 380 is extracted from [6]. 382 | 383 ASP(/MSP) | ASA/MSA(/MSP) 384 | 385 | 386 +-------+ | +-----+ 387 | AAAL |-----------|--------|AAAH | 388 +-------+ | +-----+ 389 | | 390 | | 391 | | 392 | | 393 | | 394 +-----+ +------+ | 395 +----+ | | |DHCP | | 396 | MN |------| NAS/|----|Server| | 397 +----+ |Relay| | | | 398 +-----+ +------+ | 399 | 400 | 401 +--------+ | +--------+ 402 | HA | | | HA | 403 | in ASP | | |in MSP | 404 +--------+ | +--------+ 406 Figure 3: Mobile IPv6 Bootstrapping: Integrated scenario 408 In the solution for the Integrated scenario based on DHCP [6], the HA 409 is allocated during the network access authentication phase. Then, 410 the MN queries a HA by using DHCPv6 (the NAS acting as a DCHPv6 411 relay). In this scenario, it is the same entity that authorizes 412 Network Access (ASA) and Mobility Service (MSA). The current 413 solution [6] allows the MN to require a local HA (in the visited ASP) 414 by specifying it in its DHCPv6 request. Even in this case, the AAAH 415 allocates a HA from the home MSP. The Home Agent information is sent 416 during the AAA exchange for network access authentication. After 417 this, the MN initiates an IKEv2 exchange with the allocated HA as 418 described in the previous section. 420 Diameter EAP [3] or NASREQ [2] applications are used as Diameter AAA 421 protocols for network access. As we are combining network access and 422 mobility authorization, the Home Agent information SHOULD be sent 423 when the MN is correctly authenticated. For this reason, the AVP 424 containing HA information MUST be sent in a AAA message containing 425 the success authentication. For Diameter EAP, this AVP will be 426 carried in a DEA message containing the EAP-Payload AVP with EAP- 427 Success. For Diameter-NASREQ, the AVP MUST be carried in AA-Answer 428 containing the Result-Code AVP indicating a success. 430 5.1. Home-Agent AVP 432 The Home-Agent AVP (AVP Code To Be Assigned) is of type OctetString 433 and contains the IPv6 address of the allocated Home Agent. The 'M" 434 bit in the header of the Home-Agent AVP MUST be cleared, otherwise if 435 the NAS does not support it, the authentication will fail. 437 6. Conclusion 439 This document provides information about the Diameter usage for both 440 split and integrated scenarios for Mobile IPv6 bootstrapping. It is 441 not yet complete since the goals for the HA-AAA interface [8] are 442 still work in progress. 444 7. Security considerations 446 [Editor's Note: Since the document is not complete it is necessary to 447 state that the security consideration section is incomplete as well. 448 Hence, it is only possible to refer to the security issues raised in 449 the Mobile IPv6 and Diameter protocol related documents mentioned 450 here, such as [11], [8] and [1].] 452 8. IANA Considerations 454 The AVP code for the Home-Agent AVP needs to be allocated. 456 9. Acknowledgements 458 We would like to thank the MIPv6 Bootstrapping Design Team for their 459 comments. Additionally, we would like to thank Junghoon Jee for his 460 feedback. 462 10. References 464 10.1. Normative References 466 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 467 "Diameter Base Protocol", RFC 3588, September 2003. 469 [2] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 470 Network Access Server Application", RFC 4005, August 2005. 472 [3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 473 Authentication Protocol (EAP) Application", RFC 4072, 474 August 2005. 476 [4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 477 draft-ietf-mip6-bootstrapping-split-01 (work in progress), 478 October 2005. 480 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 481 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 483 [6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 484 the Integrated Scenario", 485 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 486 progress), October 2005. 488 [7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network 489 Services", BCP 17, RFC 2219, October 1997. 491 10.2. Informative References 493 [8] Giaretta, G., "Goals for AAA-HA interface", 494 draft-ietf-mip6-aaa-ha-goals-00 (work in progress), May 2005. 496 [9] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 497 Hakala, "Diameter Credit-control Application", 498 draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. 500 [10] Alfano, F., "Diameter Quality of Service Application", 501 draft-alfano-aaa-qosprot-04 (work in progress), September 2005. 503 [11] Giaretta, G., "MIPv6 Authorization and Configuration based on 504 EAP", draft-giaretta-mip6-authorization-eap-02 (work in 505 progress), October 2004. 507 Authors' Addresses 509 Hannes Tschofenig 510 Siemens 511 Otto-Hahn-Ring 6 512 Munich, Bavaria 81739 513 Germany 515 Email: Hannes.Tschofenig@siemens.com 517 Tseno Tsenov 518 Siemens 519 Otto-Hahn-Ring 6 520 Munich, Bayern 81739 521 Germany 523 Email: tseno.tsenov@mytum.de 525 Gerardo Giaretta 526 Telecom Italia Lab 527 via G. Reiss Romoli, 274 528 TORINO, 10148 529 Italy 531 Email: gerardo.giaretta@tilab.com 533 Julien Bournelle 534 GET/INT 535 9 rue Charles Fourier 536 Evry 91011 537 France 539 Email: julien.bournelle@int-evry.fr 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2005). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.