idnits 2.17.1 draft-ietf-dime-mip6-split-02.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, updated by RFC 4748 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. 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 (May 3, 2007) is 6203 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: 'CERTREQ' on line 300 == Unused Reference: '10' is defined on line 548, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 557, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 561, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4640 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-03 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-04 ** Obsolete normative reference: RFC 4306 (ref. '5') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 3588 (ref. '9') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (ref. '10') (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4006 (ref. '13') (Obsoleted by RFC 8506) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Bournelle, Ed. 3 Extensions (DIME) GET/INT 4 Internet-Draft G. Giaretta 5 Intended status: Standards Track Telecom Italia 6 Expires: November 4, 2007 H. Tschofenig 7 Nokia Siemens Networks 8 M. Nakhjiri 9 Huawei 10 May 3, 2007 12 Diameter Mobile IPv6: HA <-> HAAA Support 13 draft-ietf-dime-mip6-split-02 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 November 4, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 In a Mobile IPv6 deployment the need for an interaction between the 47 Home Agent, the AAA infrastructure of the Mobile Service Provider 48 (MSP) and the Mobility Service Authorizer (MSA) has been identified. 50 This document describes a new Diameter application, called Mobile 51 IPv6 Authorization Application, used in conjunction with the Diameter 52 EAP Application is used to perform the necessary AAA functions before 53 executing Mobile IPv6 services. This document also specifies the 54 role of the Home Agent as part of the AAA infrastructure supporting 55 the Diameter Mobile IPv6 Authorization Application. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Diameter MIP6 HA-to-AAAH Overview . . . . . . . . . . . . . . 4 62 4. Diameter Mobile IPv6 HA-to-AAAH Support . . . . . . . . . . . 5 63 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1.1. HA with EAP Support . . . . . . . . . . . . . . . . . 6 65 4.1.2. HA without EAP Support . . . . . . . . . . . . . . . . 8 66 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.4. Mobile IPv6 Session Management . . . . . . . . . . . . . . 9 69 4.4.1. Session-Termination-Request Command . . . . . . . . . 9 70 4.4.2. Session-Termination-Answer Command . . . . . . . . . . 9 71 4.4.3. Abort-Session-Request Command . . . . . . . . . . . . 9 72 4.4.4. Abort-Session-Answer Command . . . . . . . . . . . . . 10 73 5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. MIP6-Authorization-Request . . . . . . . . . . . . . . . . 10 75 5.2. MIP6-Authorization-Answer . . . . . . . . . . . . . . . . 10 76 6. Result-Code AVPs . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 11 80 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Authentication Token . . . . . . . . . . . . . . . . . . . 11 82 10.2. HA as a Single Physical Device . . . . . . . . . . . . . . 11 83 10.3. Triggering the MIP6 Authorization Application . . . . . . 11 84 10.4. RFC4285 Support . . . . . . . . . . . . . . . . . . . . . 12 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 92 Intellectual Property and Copyright Statements . . . . . . . . . . 15 94 1. Introduction 96 With the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned a 97 Home Agent which is in charge of relaying IPv6 packets destined to 98 MN's Home Address to the MN's current address. Moreover, the Mobile 99 Node and its Home Agent (HA) must share IPsec Security Associations 100 to protect Mobile IPv6 signalling. Note that it is possible to use 101 another method than IPsec to secure signalling messages, but in this 102 document, only IPsec is considered. One of the problem is to 103 dynamically set-up these Security Associations and to assign the Home 104 Agent Address and the Home Address to the Mobile Node. This problem 105 is known as the Mobile IPv6 bootstrapping problem and is detailed in 106 [2]. Two possible bootstrapping scenarios have been identified, 107 namely the Integrated and the Split Scenario. With the Integrated 108 Scenario (see [3]), the Home Agent Address is delivered during the 109 process of network access authentication, while in the Split scenario 110 (see [4]), the Home Agent information is discovered using the DNS 111 infrastructure. In both cases, the Mobile Node has the Home Agent 112 information and it interacts with the Home Agent using IKEv2 [5]. 114 From an operator perspective, it is important to verify that the user 115 (MN) is authorized to utilize Mobile IPv6 service and that such 116 services are accounted for. The Home Agent, while verifying the 117 user's identity, also participates in the Mobile IPv6 authorization 118 process and due to its role in traffic forwarding performs accounting 119 for this service. For this reason, it is important for the Home 120 Agent to act as part of the service provider's AAA infrastructure. 122 The goal of this document is to specify a new Diameter application, 123 called Diameter Mobile IPv6 Authorization Application specifying the 124 authorization and accounting procedures associated for Mobile IPv6 125 service. Furthermore, the document specifies the role of Home Agent 126 as a Diameter client to support this application. This modular 127 approach provides flexibility for the choice of authentication in 128 conjunction with Mobile IPv6 services. For instance, the HA can use 129 the Diameter EAP Application [6] or other procedures for performing 130 authentications through a Diameter server. Note that this 131 application can be used both in Integrated and Split scenarios. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [7]. 139 The MIPv6 bootstrapping terminology is taken from [2]. 141 3. Diameter MIP6 HA-to-AAAH Overview 143 The Home Agent offers the Mobile IPv6 service to the Mobile Node. As 144 a Diameter client, the delivered Home Agent performs the following 145 operations: 147 Authentication: The Home Agent must verify the identity of the user 148 provided in the IKEv2 exchange. 150 Authorization: The Home Agent must verify that the user is 151 authorized to use the Mobile IPv6 service. 153 Accounting: For billing purposes and capacity planning, the Home 154 Agent provides accounting report to the AAA infrastructure. 156 Figure 1 shows the architecture of the solution described in this 157 document. 159 MSP MSA 160 +--------+ +-------------+ 161 +--+ IKEv2 +--+ | Diameter EAP | +--------+ | 162 |MN|<------>|HA|<-------------------------->|AAAH-EAP| | 163 +--+ | +--+ |(AUTHENTICATE_ONLY) | +--------+ | 164 | ^ | | | 165 | | | | | 166 | | Diameter MIP6 Authz/Acc | +---------+ | 167 | +---------------------------->|AAAH-MIP6| | 168 | | | +---------+ | 169 +--------+ +-------------+ 171 Figure 1: Architecture Overview 173 For the authentication part, it is likely that operators will use EAP 174 within IKEv2 to authenticate the user since it is the easiest way for 175 operator to leverage their AAA infrastructure for IKEv2 initiator 176 authentication. The Diameter EAP Application [6] is the application 177 that permits carrying EAP packets between an access device and a AAA 178 server. However, this application is primarly defined to perform AAA 179 operations for network access service and not for Mobile IPv6 180 service. For this reason, it is recommended that, when EAP is used 181 for authentication, the Diameter EAP application will be used only 182 for Authentication purpose. This implies that the Home Agent will 183 use the Diameter EAP Application in "AUTHENTICATE_ONLY" mode. This 184 is realized by setting the Auth-Request-Type AVP to 185 AUTHENTICATE_ONLY. In this document, the AAA server contacted for 186 Authentication is called AAAH-EAP. This server belongs to the MSA. 188 To explicitely authorize the Mobile IPv6 service, in this document, 189 we define a new Diameter application, called Mobile IPv6 190 Authorization Application. The application requires two new 191 messages, namely: MIP6-Authorization-Request (MAR) and MIP6- 192 Authorization-Answer (MAA). The HA, acting as a Diameter client for 193 this new application, sends a MIP6-Authorization-Request message 194 containing identity of the user to the Mobility service authorizer 195 (e.g., HAAA for MIP6 service) to verify that this user is authorized 196 to use Mobile IPv6 service. This message is sent towards Diameter 197 server called AAAH-MIP6 in this document. This server belongs to the 198 MSA. 200 This message may also contain some specific authorization AVPs 201 concerning Home-Address Allocation and Home-Address DNS registration. 202 The response is contained in the MIP6-Authorization-Answer. As this 203 application needs a new Application-Id [[[To Be assigned by IANA]]], 204 it has to be noted that the Mobile IPv6 authorization requests may be 205 routed to a different AAA server (AAAH-MIP6) than the AAA server used 206 for Authentication request (AAAH-EAP). 208 When the verification of user authorization to receive Mobile IPv6 209 service is complete, the Home-Agent start performing Accounting 210 operation by sending accounting message (ACR) with the AVP Acct- 211 Application-ID set to [[[To Be Assigned by IANA]]]. These messages 212 contain specific Mobile IPv6 AVPs and are sent to the AAAH-MIP6. 214 4. Diameter Mobile IPv6 HA-to-AAAH Support 216 Although the main goal of this document is to specify the 217 authorization and accounting for Mobile IPv6 application, the intent 218 is also to provide guidance on the AAA operations expected from HA. 219 Hence, this document provides guidance on the procedures required 220 from the HA as part of the authentication process. As EAP is 221 considered as a strong choice in performing authentication, this 222 document explains the use of Diameter EAP application in cases where 223 the prior authentication between MN and HA is done through use of 224 EAP. Therefore, the HA performs AAA operations for Mobile IPv6 by 225 using two Diameter Applications, namely: Diameter EAP[6] and Diameter 226 Mobile IPv6 (specified by this document). 228 If EAP is used within IKEv2, the HA uses the procedures of Diameter 229 EAP application (DER/DEA) with the Auth-Request-Type set to 230 AUTHENTICATE_ONLY. 232 4.1. Authentication 234 As mentioned before, prior to performing authorization process, the 235 HA must authenticate the user. The use of IKEv2 between the MN and 236 the HA allows the HA to authenticate the Mobile Node. Traditional 237 IKE authentication procedures require existence of pre-shared secrets 238 or certificates between MN and HA. However, given the possible lack 239 of prior knowledge between MN and HA, the more desired approach is to 240 use EAP and the AAA infrastructure to authenticate the user during 241 IKEv2. 243 4.1.1. HA with EAP Support 245 Figure 2 shows the message flow involved during the authentication 246 phase when EAP is used. 248 Mobile Node HA/Diameter Client Home AAA/EAP Server(AAAH-EAP) 249 ---------- ----------------- ------------------- 250 IKE_SA_INIT (1,2) 251 <------------------------------> 253 HDR, SK{IDi,[CERTREQ,] [IDr,] 254 [CP(CFG_REQUEST),] 255 SAi2, TSi, TSr} (3) 256 -------------------------------> 257 DER (EAP-Response)(AUTHENTICATE_ONLY) 258 ------------------------> 259 DEA (EAP-Request) 260 <------------------------ 261 HDR, SK {IDr, [CERT,] AUTH, 262 EAP } 263 <------------------------------- 264 HDR, SK {EAP} 265 --------------------------------> 266 DER (EAP-Response)(AUTHENTICATE_ONLY) 267 ------------------------> 268 DEA (EAP-Request) 269 <------------------------ 270 HDR, SK{EAP-Request} 271 <------------------------------- 272 HDR, SK{EAP-Response} 273 --------------------------------> 274 DER (EAP-Response) 275 ------------------------> 276 ... ... 278 DEA (EAP-Success) 279 <------------------------ 280 HDR, SK{EAP-Success} 281 <------------------------------- 282 HDR, SK{AUTH} 283 -------------------------------> 284 HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr } 285 <------------------------------- 287 Figure 2: IKEv2 Diameter EAP Message Flow 289 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 290 In this phase cryptographic algorithms are negotiated, nonces and a 291 Diffie-Hellman parameters are exchanged. Message (3) starts the 292 IKE_AUTH phase. This second phase authenticates the previous 293 messages, exchanges identities and certificates and establishes the 294 first CHILD_SA. It is used to mutually authenticate the Mobile Node 295 (acting as an IKEv2 Initiator) and the Home Agent (acting as an IKEv2 296 Responder). The identity of the User/Mobile Node is provided in the 297 field IDi. The Mobile Node indicates its willingness to be 298 authenticated by EAP by omitting the field AUTH in message 3 (cf. 299 [5]). The Mobile Node authenticates the Home Agent by requesting a 300 certificate. This is done by including the field [CERTREQ] in 301 message 3. 303 As part of the authentication process, the Mobile Node MAY request a 304 Home-Address, a Home Prefix or suggests one [4]. This is done by 305 using a CFG_REQUEST payload in the message 3. 307 The Home Agent extracts the IDi field from the message 3 and sends a 308 Diameter-EAP-Request message towards the authenticating Diameter 309 server AAAH-EAP. The User-Name AVP of the DER message MUST be set to 310 the IDi field and the Auth-Request-Type MUST be set to 311 AUTHENTICATE_ONLY. This message is routed through the AAA 312 infrastructure to the home AAA server (AAAH-EAP) of this Mobile Node. 313 The AAAH-EAP chooses an authentication method and replies with the 314 DEA Message. 316 At the end of the EAP authentication phase, the AAAH-EAP indicates 317 the result of the authentication in the Result-Code AVP and provides 318 the corresponding EAP packet (EAP Success or EAP Failure). The last 319 IKEv2 message sent by the Home Agent contains the Home Address or the 320 Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 321 necessary to setup IPsec SAs for Mobile IPv6 signalling. 323 4.1.2. HA without EAP Support 325 To be completed. 327 4.2. Authorization 329 Following the successful authentication, the Home Agent must ensure 330 that the Mobile Node is authorized to use the Mobile IPv6 service. 331 For this purpose, the Home Agent sends a MIP6-Authorization-Request 332 (MAR) message containing identity of the user towards the AAAH-MIP6. 333 The Application-ID of this message is set to [TO BE ASSIGNED]. The 334 identity is extracted from the IDi field provided in the message 3 of 335 the IKEv2 exchange. The home AAA server (AAAH-MIP6) replies with a 336 MIP6-Authorization-Answer which contains the result of the 337 authorization process. This latter message MAY contain configuration 338 policies to be applied at the Home Agent. 340 As part of the authorization request for the Mobile IPv6 service. 341 The Home Agent may require specific authorization for this MN. As an 342 example, it may request if this user is allowed to auto-assign its 343 Home-Address. 345 4.3. Accounting 347 Concerning accounting, the Diameter Mobile IPv4 Application [8] 348 defines the following AVPs: 350 o Accounting-Input-Octets: Number of octets in IP packets received 351 from the user 352 o Accounting-Output-Octets: Number of octets in IP packets sent by 353 the user 354 o Accounting-Input-Packets: Number of IP packets received from the 355 user 356 o Accounting-Output-Packets: Number of IP packets sent by the user. 358 These AVPs may be re-used for the Mobile IPv6 service. However, due 359 to routing optimization techniques introduced with Mobile IPv6 the HA 360 does not see the entire traffic exchanged between the MN and the CN. 362 [Editor's Note: As the document describing goals for this interface 363 is not finalized, other parameters may be needed in the future.] 365 4.4. Mobile IPv6 Session Management 367 Concerning Mobile IPv6 session, the AAAH (AAAH-MIP6) server may 368 maintain state or may be stateless. This is indicated in the Auth- 369 Session-State AVP (or its abscence) in the MAA message. The Home 370 Agent MUST support the Authorization Session State Machine defined in 371 [9]. Moreover the following 4 commands may be exchanged between the 372 Home Agent and the home AAA server. 374 4.4.1. Session-Termination-Request Command 376 The Session-Termination-Request (STR) message [9] is sent by the Home 377 Agent to inform the Diameter server that an authorized session is 378 being terminated. 380 4.4.2. Session-Termination-Answer Command 382 The Session-Termination-Answer (STA) message [9] is sent by the 383 Diameter server to acknowledge the notification that the session has 384 been terminated. 386 4.4.3. Abort-Session-Request Command 388 The Abort-Session-Request (ASR) message [9] is sent by the Diameter 389 server to terminates the session. This fulfills one of the 390 requirement described in [11]. 392 4.4.4. Abort-Session-Answer Command 394 The Abort-Session-Answer (ASA) message [9] is sent by the Home Agent 395 in response to an ASR message. 397 5. Command-Code Values 399 This section defines Command-Code [9] value that MUST be supported by 400 all Diameter implementations conforming to this specification. The 401 following Command Codes are defined in this specification: 403 Command-Name Abbreviation Code Section 404 --------------------------------------------------------- 405 MIP6-Authorization-Request MAR TBD 406 MIP6-Authorization-Answer MAA TBD 408 Figure 3 410 5.1. MIP6-Authorization-Request 412 The MIP6-Authorization-Request (MAR), indicated by the Command-Code 413 field set to TBD and the 'R' bit set in the Command Flags field is 414 sent by the Home Agent acting as a Diameter Client. This message is 415 used by the Home-Agent to authorize the Mobile IPv6 service. 417 5.2. MIP6-Authorization-Answer 419 The MIP6-Authorization-Answer (MAA), indicated by the Command-Code 420 field set to TBD and the 'R' bit cleared in the Command Flags field 421 is sent by the AAAH (AAAH-MIP6) in response to MIP6-Authorization- 422 Request. 424 6. Result-Code AVPs 426 This section defines new Result-Code [9] values that MUST be 427 supported by all Diameter implementations that conform to this 428 specification. 430 To be completed. 432 7. Mandatory AVPs 434 To be completed. 436 8. Accounting AVPs 438 To be completed. 440 9. AVP Occurence Tables 442 To be completed. 444 10. Open Issues 446 10.1. Authentication Token 448 Authentication and Authorization/Accounting process may be handled by 449 two different AAA servers, namely AAAH-EAP and AAAH-MIP6. As such, 450 the AAAH-MIP6 does not know if the MN has been correctly 451 authenticated before authorizing the service. 453 The issue is to know wether we need to provide a proof to the AAAH- 454 MIP6 that the MN is correctly authenticated by AAAH-EAP 456 10.2. HA as a Single Physical Device 458 The HA acts as a IKEv2 responder with the MN. As such, it can be 459 colocated with a VPN concentrator. 461 The issue is how the HA know that the MN want MIP6 service. 463 10.3. Triggering the MIP6 Authorization Application 465 If EAP is used to authenticate the MN, the HA uses two applications 466 to perform AAA operations: Diameter EAP and the MIP6 Authorization 467 Application. 469 The issue is to know when the MIP6 Authorization Application must be 470 used by the HA. 472 This issue is tied with the "HA as a single box" one. If the only 473 way for the HA to know that it was for mip6 is to wait for a BU from 474 the MN, then the Application can be used only after the reception of 475 the BU. However, if we want to do HoA-Allocation authorization by 476 the AAAH-MIP6, this implies that the application must be used before 477 the end of the IKEv2 exchange and thus before the BU reception 479 10.4. RFC4285 Support 481 This document deals with the HA-to-AAAH support in case IKEv2 is used 482 to setup IPsec SAs between MN and HA to secure Mobile IPv6 483 signalling. 485 The issue is wether support for RFC 4285 mechanism should also be 486 handled by this document. 488 11. IANA Considerations 490 To be completed. 492 12. Security Considerations 494 To be completed. 496 13. Acknowledgements 498 The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi 499 Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen, 500 Avi Lior, John Loughney, Lionel Morand. The authors would 501 particularly like to thank Yoshihiro Ohba for suggesting the idea of 502 creating a specific authorization application for Mobile IPv6 and to 503 use Diameter EAP for the authentication part. 505 The authors would like to thank the European Commission support in 506 the co-funding of the ENABLE project, where this work is partly being 507 developed. 509 Julien Bournelle would like to thank Orange-FT which partly funded 510 this work. 512 14. References 514 14.1. Normative References 516 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 517 IPv6", RFC 3775, June 2004. 519 [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 520 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 522 [3] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 523 Integrated Scenario", 524 draft-ietf-mip6-bootstrapping-integrated-dhc-03 (work in 525 progress), April 2007. 527 [4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 528 draft-ietf-mip6-bootstrapping-split-04 (work in progress), 529 December 2006. 531 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 532 RFC 4306, December 2005. 534 [6] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 535 Authentication Protocol (EAP) Application", RFC 4072, 536 August 2005. 538 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 539 Levels", BCP 14, RFC 2119, March 1997. 541 [8] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 542 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 543 August 2005. 545 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 546 "Diameter Base Protocol", RFC 3588, September 2003. 548 [10] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 549 Network Access Server Application", RFC 4005, August 2005. 551 14.2. Informative References 553 [11] Giaretta, G., "AAA Goals for Mobile IPv6", 554 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 555 September 2006. 557 [12] Alfano, F., "Diameter Quality of Service Application", 558 draft-tschofenig-dime-diameter-qos-01 (work in progress), 559 October 2006. 561 [13] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 562 Loughney, "Diameter Credit-Control Application", RFC 4006, 563 August 2005. 565 Authors' Addresses 567 Julien Bournelle (editor) 568 GET/INT 569 9 rue Charles Fourier 570 Evry 91011 571 France 573 Email: julien.bournelle@int-evry.fr 575 Gerardo Giaretta 576 Telecom Italia Lab 577 via G. Reiss Romoli, 274 578 TORINO, 10148 579 Italy 581 Email: gerardo.giaretta@telecomitalia.it 583 Hannes Tschofenig 584 Nokia Siemens Networks 585 Otto-Hahn-Ring 6 586 Munich, Bavaria 81739 587 Germany 589 Email: Hannes.Tschofenig@nsn.com 590 URI: http://www.tschofenig.com 592 Madjid Nakhjiri 593 Huawei USA 594 12040, 98th AVE NE, suite 200B 595 Kirkland, WA 98033 596 USA 598 Email: mnakhjiri@huawei.com 599 URI: 601 Full Copyright Statement 603 Copyright (C) The IETF Trust (2007). 605 This document is subject to the rights, licenses and restrictions 606 contained in BCP 78, and except as set forth therein, the authors 607 retain all their rights. 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 612 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 613 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 614 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Intellectual Property 619 The IETF takes no position regarding the validity or scope of any 620 Intellectual Property Rights or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; nor does it represent that it has 624 made any independent effort to identify any such rights. Information 625 on the procedures with respect to rights in RFC documents can be 626 found in BCP 78 and BCP 79. 628 Copies of IPR disclosures made to the IETF Secretariat and any 629 assurances of licenses to be made available, or the result of an 630 attempt made to obtain a general license or permission for the use of 631 such proprietary rights by implementers or users of this 632 specification can be obtained from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its attention any 636 copyrights, patents or patent applications, or other proprietary 637 rights that may cover technology that may be required to implement 638 this standard. Please address the information to the IETF at 639 ietf-ipr@ietf.org. 641 Acknowledgment 643 Funding for the RFC Editor function is provided by the IETF 644 Administrative Support Activity (IASA).