idnits 2.17.1 draft-ietf-dime-mip6-split-05.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1275. 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 (September 29, 2007) is 6053 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. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4640 (ref. '2') == Outdated reference: A later version (-03) exists of draft-ietf-mip6-rfc4285bis-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-rfc4285bis (ref. '4') ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4306 (ref. '8') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4005 (ref. '9') (Obsoleted by RFC 7155) == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-01 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-05 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-02 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: April 1, 2008 J. Bournelle 7 France Telecom R&D 8 G. Giaretta 9 Qualcomm 10 M. Nakhjiri 11 Motorola 12 September 29, 2007 14 Diameter Mobile IPv6: Support for Home Agent to Diameter Server 15 Interaction 16 draft-ietf-dime-mip6-split-05.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 1, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 Mobile IPv6 deployments may want to bootstrap their operations 50 dynamically based on an interaction between the Home Agent and the 51 Diameter server of the Mobile Service Provider (MSP). This document 52 specifies the interaction between a Mobile IP Home Agent and the 53 Diameter server. 55 Several different mechanisms for authenticating a Mobile Node are 56 supported. The usage of the Internet Key Exchange v2 (IKEv2) 57 protocol allows different mechanisms, such as the Extensible 58 Authentication Protocol (EAP), certificates and pre-shared secrets in 59 IKEv2 to be used. Furthermore, another method makes use of the 60 Mobile IPv6 Authentication protocol. In addition to authentication 61 authorization, the configuration of Mobile IPv6 specific parameters 62 and accounting is specified in this document. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Advertising Application Support . . . . . . . . . . . . . . . 7 69 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Support for Mobile IPv6 with IKEv2 and EAP . . . . . . . . 7 71 4.2. Support for Mobile IPv6 with IKEv2 and Certificates . . . 9 72 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared 73 Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. Support for the Mobile IPv6 Authentication Protocol . . . 10 75 4.5. Mobile IPv6 Session Management . . . . . . . . . . . . . . 11 76 4.5.1. Session-Termination-Request Command . . . . . . . . . 11 77 4.5.2. Session-Termination-Answer Command . . . . . . . . . . 11 78 4.5.3. Abort-Session-Request Command . . . . . . . . . . . . 11 79 4.5.4. Abort-Session-Answer Command . . . . . . . . . . . . . 11 80 4.6. Accounting for Mobile IPv6 services . . . . . . . . . . . 11 81 4.6.1. Accounting-Request Command . . . . . . . . . . . . . . 12 82 4.6.2. Accounting-Answer Command . . . . . . . . . . . . . . 12 83 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP . . . . . 12 85 5.1.1. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . 13 86 5.1.2. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . 13 87 5.2. Command Code for Mobile IPv6 with IKEv2 and 88 Certificate- and PSK-based Authentication . . . . . . . . 14 89 5.2.1. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . 14 90 5.2.2. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . 15 91 5.3. Command Codes for MIPv6 Auth. Protocol Support . . . . . . 16 92 5.3.1. MIP6-Request-Message . . . . . . . . . . . . . . . . . 16 93 5.3.2. MIP6-Answer-Message . . . . . . . . . . . . . . . . . 17 94 6. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 21 96 6.2. MIP-MN-AAA-SPI AVP . . . . . . . . . . . . . . . . . . . . 21 97 6.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . . 21 98 6.4. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . . . 21 99 6.5. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 21 100 6.6. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 21 101 6.7. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 22 102 6.8. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 22 103 6.9. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 22 104 6.10. MIP-MN-to-HA-MSA AVP . . . . . . . . . . . . . . . . . . . 22 105 6.11. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 22 106 6.12. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 23 107 6.13. MIP-nonce AVP . . . . . . . . . . . . . . . . . . . . . . 23 108 6.14. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 23 109 6.15. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 23 110 6.16. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 23 111 6.17. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 23 112 6.18. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 23 113 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 24 114 7.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 24 115 7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 24 116 8. AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 25 117 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table . . 25 118 8.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . . 26 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 120 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 26 121 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 26 122 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 27 123 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 27 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 125 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 126 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 127 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 128 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 130 Intellectual Property and Copyright Statements . . . . . . . . . . 31 132 1. Introduction 134 Performing the Mobile IPv6 protocol [1], requires the Mobile Node 135 (MN) to own a Home Address (HoA) and assignment of a Home Agent (HA) 136 to the MN. The MN needs to register with the HA in order facilitate 137 its reachability and mobility, when away from home. The registration 138 process itself requires establishment of IPsec security associations 139 (SA) and cryptographic material between the MN and HA. Providing the 140 collection of home address, HA address and keying material is 141 generally referred to as the Mobile IPv6 bootstrapping problem [2]. 142 The purpose of this specification is to provide Diameter support for 143 the interaction between the HA and the AAA server, as it is required 144 for bootstrapping in the split scenario [13] and in the integrated 145 scenario [14] in a manner that satisfies the requirements defined in 146 [15]. 148 From an operator (mobility service provider, MSP) perspective, it is 149 important to verify that the MN is authenticated and authorized to 150 utilize Mobile IPv6 service and that such services are accounted for. 151 Only when the MN is authenticated and authorized, the MSP allows the 152 boostrapping of Mobile IPv6 parameters. Thus, prior to processing 153 the Mobile IPv6 service requests, the HA, participates in the 154 authentication of the MN to verify the MN's identity. The HA also 155 participates in the Mobile IPv6 authorization process involving the 156 Diameter infrastrucure. The HA due to its role in traffic 157 forwarding, also may also perform accounting for the Mobile IPv6 158 service provided to the MN. 160 This document enables the following functionality: 162 Authentication: Asserting or helping in asserting of the correctness 163 of the MN identity. As a Diameter client supporting the new 164 Diameter Mobile IPv6 application, the HA may need to support more 165 than one authentication type depending on the environment. 166 Although the authentication is performed by the AAA server there 167 is an impact for the HA as different set of command codes are 168 needed for the respective authentication procedures. 170 Authorization: The HA must verify that the user is authorized to use 171 the Mobile IPv6 service using the assistance of the MSP Diameter 172 servers. This is accomplised through the use of new Diameter 173 commands specifically designed for performing Mobile IPv6 174 authorization decisions. This document defines these commands and 175 requires the HA to support them and to participate in this 176 authorization signaling. 178 Accounting: For accounting purposes and capacity planning, it is 179 required of the HA to provide accounting report to the Diameter 180 infrastructure and thus to support the related Diameter accounting 181 procedures. 183 Figure 1 depicts the architecture. 185 +--------+ 186 |Diameter| 187 |Server | 188 +--------+ 189 ^ 190 Back-End | Diameter MIPv6 191 Protocol | HA<->AAA Server 192 Support | Interaction 193 | (this document) 194 v 195 +---------+ +--------------+ 196 | Mobile | Front-End Protocol |Home Agent / | 197 | Node |<--------------------------|Diemter Client| 198 +---------+ IKEv2 or RFC 4285 +--------------+ 200 Figure 1: Architecture Overview 202 Mobile IPv6 signaling between the MN and the HA can protected using 203 two different mechanisms, namely using IPsec and via the MIPv6 Auth. 204 Protocol. Note that the actual mechanism to protect the MIPv6 205 signaling messages is only indirectly relevant to this document. The 206 important aspect is, however, that for these two approaches several 207 different authentication and key exchange solutions are available. 208 To establish IPsec security associations for protection of Mobile 209 IPv6 signaling messages IKEv2 is used, see [3]. IKEv2 supports EAP- 210 based authentication, certificates and pre-shared secrets. For 211 protecting using the MIPv6 Auth. Protocol [4] a mechanism has been 212 designed that is very similar to the one used by Mobile IPv4. 214 The ability to use different credentials has an impact on the 215 interaction between the HA (acting as a Diameter client) and the 216 Diameter Server. For that reason this document illustrates the usage 217 of these authentication mechanisms with different subsections for 218 o IKEv2 usage with EAP 219 o IKEv2 usage with certificates and pre-shared secrets 220 o MIPv6 Auth. Protocol 222 For accounting of Mobile IPv6 services provided to the MN, this 223 specification uses the accounting application defined in [5]. 225 2. Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119 [6]. 231 The MIPv6 bootstrapping terminology is taken from [2]. 233 3. Advertising Application Support 235 Diameter nodes conforming to this specification MUST advertise 236 support by including the Diameter Mobile IPv6 Application ID value of 237 [TO BE ASSIGNED BY IANA] in the Auth-Application-Id AVP of the 238 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 239 command [5]. The Acct-Application-id AVP needs to include the 240 Diameter Base Accounting Application ID value of 3 (to support the 241 split accounting model [16]). 243 4. Protocol Description 245 4.1. Support for Mobile IPv6 with IKEv2 and EAP 247 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 248 authenticate the MN. When EAP is used with IKEv2, the Diameter EAP 249 application, as defined in [7], is re-used. EAP methods that do not 250 establish a shared key SHOULD NOT be used, as they are subject to a 251 number of man-in-the-middle attacks as stated in Section 2.16 and 252 Section 5 of RFC 4306 [8]. AVPs specific to Mobile IPv6 253 bootstrapping are added to the EAP application commands. 255 Figure 2 shows the message flow involved during the authentication 256 phase when EAP is used. 258 Mobile Home Diameter 259 Node Agent Server 260 | | | 261 | HDR, SAi1, KEi, Ni (1) | | 262 |-------------------------------->| | 263 | | | 264 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 265 |<------------------------------->| | 266 | | | 267 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 268 | [CP(CFG_REQUEST),] | | 269 | SAi2, TSi, TSr} (3) | | 270 |-------------------------------->| DER (EAP-Response) (4) | 271 | |------------------------->| 272 | | | 273 | | DEA (EAP-Request) (5) | 274 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------| 275 |<------------------------------- | | 276 | | | 277 | HDR, SK{EAP} | | 278 |-------------------------------->| DER (EAP-Response) | 279 | |------------------------->| 280 | | | 281 | | DEA (EAP-Request) | 282 | HDR, SK{EAP-Request} |<-------------------------| 283 |<------------------------------- | | 284 | | | 285 | HDR, SK{EAP-Response} | | 286 |-------------------------------->| DER (EAP-Response) | 287 | |------------------------->| 288 | ... | ... | 289 | | | 290 | | DEA (EAP-Success) | 291 | |<-------------------------| 292 | HDR, SK{EAP-Success} | | 293 |<------------------------------- | | 294 | | | 295 | HDR, SK{AUTH} | | 296 |-------------------------------> | | 297 | | | 298 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 299 | SAr2, TSi, TSr} | | 300 |<------------------------------- | | 301 | | | 303 Figure 2: Mobile IPv6 with IKEv2 and EAP 305 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 307 In this phase cryptographic algorithms are negotiated, nonces and 308 Diffie-Hellman parameters are exchanged. Message (3) starts the 309 IKE_AUTH phase. This second phase authenticates the previous 310 messages, exchanges identities and certificates and establishes the 311 first CHILD_SA. It is used to mutually authenticate the MN (acting 312 as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). 313 The identity of the user/MN is provided in the IDi field. The MN 314 indicates its willingness to be authenticated via EAP by omitting the 315 AUTH field in message (3) (see Section 2.16 of [8]). 317 As part of the authentication process, the MN MAY request a Home- 318 Address, a Home Prefix or suggests one, see [3], using a CFG_REQUEST 319 payload in the message (3). 321 The HA extracts the IDi field from the message (3) and sends a 322 Diameter-EAP-Request (DER) message (4) towards the authenticating 323 Diameter server. The EAP-Payload AVP contains a EAP-Response/ 324 Identity with the identity extracted from the IDi field. 326 This message is routed to the MNs Diameter server/EAP server. The 327 Diameter server selects the EAP method and replies with the DEA 328 Message. Depending on the type of EAP method chosen, a number of DER 329 and DEA messages carry the method specific exchanges between the MN 330 and the Diameter server/EAP server. 332 At the end of the EAP authentication phase, the Diameter server 333 indicates the result of the authentication in the Result-Code AVP and 334 provides the corresponding EAP packet (EAP Success or EAP Failure). 335 The last IKEv2 message sent by the HA contains the Home Address or 336 the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 337 necessary to setup IPsec SAs for Mobile IPv6 signalling. 339 In some deployment scenario, the HA may also acts as a IKEv2 340 Responder for IPsec VPN access. A problem in this case is that the 341 IKEv2 responder may not know if IKEv2 is used for MIP6 service or for 342 IPsec VPN access. A network operator needs to be aware of this 343 limitation. 345 4.2. Support for Mobile IPv6 with IKEv2 and Certificates 347 When IKEv2 is used with certificate-based authentication, the 348 Diameter NASREQ application [9] is used to authorize the MN for the 349 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 350 message MUST correspond to the identity in the MN's certificate. 351 This identity is then used by the Home Agent to populate the User- 352 Name AVP in the succeeding AA-Request message. Further PKI-related 353 procedures such as certificate revocation checking are out of scope 354 of this document. 356 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets 358 When IKEv2 is used with PSK-based initiator authentication, the 359 Diameter NASREQ application [9] isused to authorize the MN for the 360 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 361 message has to contain an identity that is meaningful for the 362 Diameter infrastructure, such as a Network Access Identifier (NAI), 363 and is then used by the Home Agent to populate the User-Name AVP is 364 the succeeding AA-Request message. 366 4.4. Support for the Mobile IPv6 Authentication Protocol 368 Figure 3 describes the sequence of messages sent and received between 369 the MN, the HA and the Diameter server during the registration when 370 MIPv6 Auth. Protocol is used. Binding Update (BU) and Binding 371 Acknowledgement (BA) messages are used in the registration process. 372 This exchange triggers the Diameter interaction. 374 According to [4] the MN uses the Mobile Node Identifier Option, 375 specifically the MN-NAI mobility option (as defined in [17]) to 376 identify itself. 378 The BU initiates a MIP6-Request-Message to the Diameter server and 379 the corresponding response is carried in a MIP6-Answer-Message. The 380 Home Agent also provides the assigned Home Address to the Diameter 381 server in the MIP-Mobile-Node-Address AVP. 383 Mobile Home Diameter 384 Node Agent Server 385 | | | 386 | | | 387 | Binding Update |MIP6-Request-Message | 388 |------------------------------------>|-------------------->| 389 | (Mobile Node Identifier Option, | | 390 | Mobility Message Replay Protection | | 391 | Option, Authentication Option) | | 392 | | | 393 | | | 394 | Binding Acknowledgement |MIP6-Answer-Message | 395 |<------------------------------------|<--------------------| 396 | (Mobile Node Identifier Option | | 397 | Mobility Message Replay Protection | | 398 | Option, Authentication Option) | | 400 Figure 3: MIPv6 Bootstrapping using the MIPv6 Auth. Protocol 402 4.5. Mobile IPv6 Session Management 404 The Diameter server may maintain state or may be stateless. This is 405 indicated in the Auth-Session-State AVP (or its absence). The HA 406 MUST support the Authorization Session State Machine defined in [5]. 407 Moreover, the following four commands may be exchanged between the HA 408 and the Diameter server. 410 4.5.1. Session-Termination-Request Command 412 The Session-Termination-Request (STR) message [5] is sent by the HA 413 to inform the Diameter server that an authorized session is being 414 terminated. 416 4.5.2. Session-Termination-Answer Command 418 The Session-Termination-Answer (STA) message [5] is sent by the 419 Diameter server to acknowledge the notification that the session has 420 been terminated. 422 4.5.3. Abort-Session-Request Command 424 The Abort-Session-Request (ASR) message [5] is sent by the Diameter 425 server to terminates the session. This fulfills one of the 426 requirement described in [15]. 428 4.5.4. Abort-Session-Answer Command 430 The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent 431 in response to an ASR message. 433 4.6. Accounting for Mobile IPv6 services 435 The HA MUST be able act as a Diameter client collecting accounting 436 records needed for service control and charging. The HA MUST support 437 the accounting procedures (specifically the command codes mentioned 438 below) and the Accounting Session State Machine as defined in [5]. 439 The command codes, exchanged between the HA and Diameter server for 440 accounting purposes, are provided in the following subsections. 442 The Diameter application design guideline [16] defines two separate 443 models for accounting: 445 Split accounting model: 447 According to this model, the accounting messages use the Diameter 448 base accounting application ID (value of 3). Since accounting is 449 treated as an independent application, accounting commands may be 450 routed separately from the rest of application messages and thus 451 the accounting messages generally end up in a central accounting 452 server. Since Diameter Mobile IPv6 application does not define 453 its own unique accounting commands, this is the prefered choice, 454 since it permits use of centralized accounting for several 455 applications. 457 Coupled accounting model: 459 In this model, the accounting messages will use the application ID 460 of the Mobile IPv6 application. This means that accounting 461 messages will be routed like any other Mobile IPv6 application 462 messages. This requires the Diameter server in charge of Mobile 463 IPv6 application to handle the accounting records (e.g., sends 464 them to a proper accounting server). 466 As mentioned above, the prefered choice is to use the split 467 accounting model and thus to choose Diameter base accounting 468 application ID (value of 3) for accounting messages. 470 4.6.1. Accounting-Request Command 472 The Accounting-Request command [5] is sent by the HA to the Diameter 473 server to exchange accounting information regarding the MN with the 474 Diameter server. 476 4.6.2. Accounting-Answer Command 478 The Accounting-Answer command [5] is sent by the Diameter server to 479 the HA to acknowledge receiving an Accounting-Request. 481 5. Command Codes 483 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP 485 For usage of Mobile IPv6 with IKEv2 and EAP this document re-uses the 486 Diameter EAP application [7] commands. The following commands are 487 used to carry MIPv6 related bootstrapping AVPs. 489 Command-Name Abbrev. Code Reference Application 490 ------------------------------------------------------------------ 491 Diameter-EAP-Request DER 268 RFC 4072 EAP 492 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 494 Figure 4: Command Codes 496 5.1.1. Diameter-EAP-Request (DER) 498 The Diameter-EAP-Request (DER) message [7], indicated by the Command- 499 Code field set to 268 and the 'R' bit set in the Command Flags field, 500 is sent by the HA to the Diameter server to initiate a Mobile IPv6 501 service authentication and authorization procedure. The DER message 502 format is the same as defined in [7]. The Application-ID field of 503 the Diameter Header MUST be set to the Diameter Mobile IPv6 504 Application ID [TO BE ASSIGNED TO IANA]. 506 ::= < Diameter Header: 268, REQ, PXY > 507 < Session-Id > 508 { Auth-Application-Id } 509 { Origin-Host } 510 { Origin-Realm } 511 { Destination-Realm } 512 { Auth-Request-Type } 513 [ Destination-Host ] 514 [ NAS-Identifier ] 515 [ NAS-IP-Address ] 516 [ NAS-IPv6-Address ] 517 [ NAS-Port-Type ] 518 [ User-Name ] 519 { EAP-Payload } 521 [ MIP6-Feature-Vector ] 522 [ MIP-Home-Agent-Address ] 523 { MIP-Mobile-Node-Address } 524 ... 525 * [ AVP ] 527 5.1.2. Diameter-EAP-Answer (DEA) 529 The Diameter-EAP-Answer (DEA) message defined in [7], indicated by 530 the Command-Code field set to 268 and 'R' bit cleared in the Command 531 Flags field, is sent in response to the Diameter-EAP-Request message 532 (DER). If the Mobile IPv6 authentication procedure was successful 533 then the response MAY include any set of bootstrapping AVPs. 535 The DEA message format is the same as defined in [7]. The 536 Application-Id field in the Diameter header MUST be set to the 537 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 539 ::= < Diameter Header: 268, PXY > 540 < Session-Id > 541 { Auth-Application-Id } 542 { Auth-Request-Type } 543 { Result-Code } 544 { Origin-Host } 545 { Origin-Realm } 547 [ User-Name ] 548 { EAP-Payload } 549 [ Authorization-Lifetime ] 551 [ MIP-Mobile-Node-Address ] 552 [ MIP6-Feature-Vector ] 553 ... 554 * [ AVP ] 556 5.2. Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK- 557 based Authentication 559 This document re-uses the Diameter NASREQ application commands. The 560 following commands are used to carry MIPv6 related bootstrapping 561 AVPs. 563 Command-Name Abbrev. Code Reference Application 564 ------------------------------------------------------------------ 565 AA-Request AAR 265 RFC 4005 NASREQ 566 AA-Answer AAA 265 RFC 4005 NASREQ 568 Figure 7: Command Codes 570 5.2.1. AA-Request (AAR) 572 The AA-Request (AAR) message [9], indicated by the Command-Code field 573 set to 265 and the 'R' bit set in the Command Flags field, is sent by 574 the HA to the Diameter server to initiate a Mobile IPv6 service 575 authentication and authorization procedure. The AAR message format 576 is the same as defined in [9]. The Application-ID field of the 577 Diameter Header MUST be set to the Diameter Mobile IPv6 Application 578 ID [TO BE ASSIGNED TO IANA]. 580 ::= < Diameter Header: 265, REQ, PXY > 581 < Session-Id > 582 { Auth-Application-Id } 583 { Origin-Host } 584 { Origin-Realm } 585 { Destination-Realm } 586 { Auth-Request-Type } 587 [ Destination-Host ] 588 [ NAS-Identifier ] 589 [ NAS-IP-Address ] 590 [ NAS-IPv6-Address ] 591 [ NAS-Port-Type ] 592 [ User-Name ] 594 [ MIP6-Feature-Vector ] 595 [ MIP-Home-Agent-Address ] 596 { MIP-Mobile-Node-Address } 597 ... 598 * [ AVP ] 600 5.2.2. AA-Answer (AAA) 602 The AA-Answer (AAA) message defined in [9], indicated by the Command- 603 Code field set to 265 and 'R' bit cleared in the Command Flags field, 604 is sent in response to the AA-Request message (AAR). If the Mobile 605 IPv6 authentication procedure was successful then the response MAY 606 include any set of bootstrapping AVPs. 608 The AAA message format is the same as defined in [9]. The 609 Application-Id field in the Diameter header MUST be set to the 610 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 612 ::= < Diameter Header: 265, PXY > 613 < Session-Id > 614 { Auth-Application-Id } 615 { Auth-Request-Type } 616 { Result-Code } 617 { Origin-Host } 618 { Origin-Realm } 620 [ User-Name ] 621 [ Authorization-Lifetime ] 623 [ MIP-Mobile-Node-Address ] 624 [ MIP6-Feature-Vector ] 625 ... 626 * [ AVP ] 628 5.3. Command Codes for MIPv6 Auth. Protocol Support 630 This section defines the commands that are used for support with the 631 MIPv6 Auth. Protocol. 633 Command-Name Abbreviation Code Section 634 ------------------------------------------------------------------ 635 MIP6-Request-Message MRM TBD Section 6.2.1 636 MIP6-Answer-Message MAM TBD Section 6.2.2 638 Command Codes 640 5.3.1. MIP6-Request-Message 642 The MIP6-Request-Message (MRM), indicated by the Command-Code field 643 set to TBD and the 'R' bit set in the Command Flags field, is sent by 644 the HA, acting as a Diameter client, in order to request the 645 authentication and authorization of a MN. The HA uses information 646 found in the Binding Update to construct the following AVPs, to be 647 included as part of the MRM: 649 o Home Address (MIP-Mobile-Node-Address AVP) 650 o Mobile Node NAI (User-Name AVP [5]) 651 o MN-AAA Authentication Option (MIP-MN-AAA-Auth AVP) 652 o Care-of Address (MIP-Careof-Address AVP) 653 o Mobility message replay protection Option using timestamps (MIP- 654 Timestamp AVP) 656 The message format is shown below. 658 ::= < Diameter Header: XXX, REQ, PXY > 659 < Session-ID > 660 { Auth-Application-Id } 661 { User-Name } 662 { Destination-Realm } 663 { Origin-Host } 664 { Origin-Realm } 665 [ Acct-Multi-Session-Id ] 666 [ Destination-Host ] 667 [ Origin-State-Id ] 668 [ NAS-Identifier ] 669 [ NAS-IP-Address ] 670 [ NAS-IPv6-Address ] 671 [ NAS-Port-Type ] 673 [ MIP6-Feature-Vector ] 674 { MIP-MN-AAA-SPI } 675 { MIP-Mobile-Node-Address ] 676 { MIP-Home-Agent-Address } 677 { MIP-Careof-Address } 678 { MIP-Authenticator } 679 { MIP-MAC-Mobility-Data } 680 [ MIP-Timestamp ] 681 [ QoS-Capability ] 682 * [ QoS-Resources ] 684 [ Authorization-Lifetime ] 685 [ Auth-Session-State ] 686 * [ Proxy-Info ] 687 * [ Route-Record ] 688 * [ AVP ] 690 5.3.2. MIP6-Answer-Message 692 The MIP6-Answer-Message (MAM) message, indicated by the Command-Code 693 field set to TBD and the 'R' bit cleared in the Command Flags field, 694 is sent by the Diameter server in response to the MIP6-Request- 695 Message message. The User-Name MAY be included in the MAM if it is 696 present in the MRM. The Result-Code AVP MAY contain one of the 697 values defined in Section 7, in addition to the values defined in RFC 698 3588 [5]. 700 An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 701 include the MIP-Mobile-Node-Address AVP. 703 The message format is shown below. 705 ::= < Diameter Header: XXX, PXY > 706 < Session-Id > 707 { Auth-Application-Id } 708 { Result-Code } 709 { Origin-Host } 710 { Origin-Realm } 711 [ Acct-Multi-Session-Id ] 712 [ User-Name ] 713 [ Authorization-Lifetime ] 714 [ Auth-Session-State ] 715 [ Error-Message ] 716 [ Error-Reporting-Host ] 717 [ Re-Auth-Request-Type ] 719 [ MIP6-Feature-Vector ] 720 [ MIP-Home-Agent-Address ] 721 { MIP-Mobile-Node-Address } 722 { MIP-Session-Key } 723 { MIP-MSA-Lifetime } 724 { MIP-MN-to-HA-MSA } 725 * [ QoS-Resources ] 727 [ Origin-State-Id ] 728 * [ Proxy-Info ] 729 * [ AVP ] 731 The QoS-Resources AVP is defined in [10]. 733 6. AVPs 735 To provide support for RFC 4285 [4] and for RFC 4877 [3] the AVPs in 736 the following subsections are needed. RFC 3588, RFC 4004 and RFC 737 4005 defined AVPs are reused whenever possible without violating the 738 existing semantics of those AVPs. 740 +--------------------------+ 741 | AVP Flag rules | 742 +----+-----+----+-----+----+ 743 AVP Defined | | |SHLD| MUST|MAY | 744 Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr| 745 +-----------------------------------------+----+-----+----+-----+----+ 746 |MIP6-Feature- TBD Note 1 Unsigned64 | | P | | M,V | Y | 747 | Vector | | | | | | 748 +-----------------------------------------+----+-----+----+-----+----+ 749 |MIP-Mobile- | | M,P | | V | Y | 750 |Node-Address 334 RFC4004 Address | | | | | | 751 +-----------------------------------------+----+-----+----+-----+----+ 752 |MIP-Home- 334 RFC4004 Address | | M,P | | V | Y | 753 | Agent-Address | | | | | | 754 +-----------------------------------------+----+-----+----+-----+----+ 756 AVPs for Mobile IPv6 with IKEv2 758 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [11]. 760 +--------------------------+ 761 | AVP Flag rules | 762 +----+-----+----+-----+----+ 763 AVP Section | | |SHLD| MUST|MAY | 764 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 765 +-----------------------------------------+----+-----+----+-----+----+ 766 |MIP6-Feature- TBD Note 1 Unsigned64 | | P | | M,V | Y | 767 | Vector | | | | | | 768 +-----------------------------------------+----+-----+----+-----+----+ 769 |MIP-Mobile- 333 RFC4004 Address | | M,P | | V | Y | 770 | Node-Address | | | | | | 771 +-----------------------------------------+----+-----+----+-----+----+ 772 |MIP-Home- 334 RFC4004 Address | | M,P | | V | Y | 773 | Agent-Address | | | | | | 774 +-----------------------------------------+----+-----+----+-----+----+ 775 |MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | M | P | | V | Y | 776 +-----------------------------------------+----+-----+----+-----+----+ 777 |MIP-Careof- TBD 5.4.5 Address | M | P | | V | Y | 778 | Address | | | | | | 779 +-----------------------------------------+----+-----+----+-----+----+ 780 |MIP- TBD 5.4.6 OctetString| M | P | | V | Y | 781 | Authenticator | | | | | | 782 +-----------------------------------------+----+-----+----+-----+----+ 783 |MIP-MAC- TBD 5.4.7 OctetString| M | P | | V | Y | 784 | Mobility-Data | | | | | | 785 +-----------------------------------------+----+-----+----+-----+----+ 786 |MIP-Timestamp TBD TBD Time | | M,P | | V | Y | 787 +-----------------------------------------+----+-----+----+-----+----+ 788 |MIP-Session-Key 343 RFC4004 OctetString| M | P | | V | Y | 789 +-----------------------------------------+----+-----+----+-----+----+ 790 |MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y | 791 | Lifetime | | | | | | 792 +-----------------------------------------+----+-----+----+-----+----+ 793 |MIP-MN-to- 331 RFC4004 Grouped | M | P | | V | Y | 794 | HA-MSA | | | | | | 795 +-----------------------------------------+----+-----+----+-----+----+ 796 |QoS-Capability TBD Note 2 Groupe | | M,P | | V | Y | 797 +-----------------------------------------+----+-----+----+-----+----+ 798 |QoS-Resources TBD Note 2 Grouped | | M,P | | V | Y | 799 +-----------------------------------------+----+-----+----+-----+----+ 801 AVPs for the Mobile IPv6 Authentication Protocol 803 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [11]. 805 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 806 Sections 4.1 and 4.3 of [10]. 808 6.1. User-Name AVP 810 The User-Name AVP (AVP Code 2) is of type UTF8String and contains an 811 NAI extracted from the MN-NAI mobility option included in the 812 received BU message. Alternatively, the NAI can be extracted from 813 the IKEv2 IDi payload included in the IKE_SA_INIT message. 815 6.2. MIP-MN-AAA-SPI AVP 817 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 818 contains an SPI code extracted from the Mobility Message 819 Authentication Option included in the received BU message. 821 This AVP is re-used from [12]. 823 6.3. MIP-Mobile-Node-Address AVP 825 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 826 contains the Home Agent assigned IPv6 Home Address of the Mobile 827 Node. 829 If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address 830 (0::0) in a request message, then the Home Agent expects the Diameter 831 server to assign the Home Address in a subsequent reply message. In 832 case the Diameter server assigns only a prefix to the Mobile Node the 833 lower 64 bits of the MIP-Mobile-Node-Address AVP provided address are 834 set to zero. 836 This AVP is re-used from [12]. 838 6.4. MIP-Home-Agent-Address AVP 840 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 841 contains the IPv6 address of the Home Agent. This AVP is re-used 842 from [12]. 844 6.5. MIP-Careof-Address AVP 846 The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and 847 contains the IPv6 Care-of Address of the Mobile Node. The Home Agent 848 extracts this IP address from the received BU message. 850 6.6. MIP-Authenticator AVP 852 The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and 853 contains the Authenticator Data from the received BU message. The 854 Home Agent extracts this data from the MN-AAA Mobility Message 855 Authentication Option included in the received BU message. 857 6.7. MIP-MAC-Mobility-Data AVP 859 The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString 860 and contains the calculated MAC_Mobility_Data, as defined in [4]. 862 6.8. MIP-Session-Key AVP 864 The AVP (AVP Code 343) is of type OctetString and contains the MN-HA 865 shared secret (i.e., the session key) for the associated Mobile IPv6 866 MH-HA authentication option. When the Diameter server computes the 867 session key it is placed in this AVP. 869 This AVP is re-used from [12]. 871 6.9. MIP-MSA-Lifetime AVP 873 The AVP (AVP Code 367) is of type Unsigned32 and represents the 874 period of time (in seconds) for which the session key (see 875 Section 6.8) or nonce (see Section 6.13) is valid. The associated 876 session key or nonce MUST NOT be used if the lifetime has expired. 878 This AVP is re-used from [12]. 880 6.10. MIP-MN-to-HA-MSA AVP 882 The AVP (AVP Code 331) is of type Grouped and contains the session 883 related information for use with the MIPv6 Auth. Protocol. 885 MIP-MN-to-HA-MSA ::= < AVP Header: 331 > 886 { MIP-Algorithm-Type } 887 { MIP-Replay-Mode } 888 { MIP-nonce } 889 * [ AVP ] 891 This AVP is re-used from [12]. 893 6.11. MIP-Algorithm-Type AVP 895 The AVP (AVP Code 345) is of type Enumerated and contains Algorithm 896 identifier for the associated Mobile IPv6 MN-HA Authentication 897 Option. The Diameter server selects the algorithm type. Existing 898 algorithm types are defined in RFC 4004 that also fulfill current RFC 899 4285 requirements. This AVP is re-used from [12]. 901 6.12. MIP-Replay-Mode AVP 903 The AVP (AVP Code 346) is of type Enumerated and contains the replay 904 mode the Home Agent for authenticating the mobile node. The replay 905 modes, defined in RFC 4004 [12], are supported. This AVP is re-used 906 from [12]. 908 6.13. MIP-nonce AVP 910 The AVP (AVP Code 335) is of type OctetString and contains the nonce 911 sent to the Mobile Node. This AVP is re-used from [12]. At the time 912 of writing the MIPv6 Auth. Protocol does not require use of nonces 913 for replay protection between the MN and the Diameter server. Thus, 914 the Home Agent is allowed to ignore the returned MIP-Nonce AVP. 916 6.14. MIP6-Feature-Vector AVP 918 This AVP is defined in [11]. 920 6.15. MIP-Timestamp AVP 922 The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain 923 the timestamp value from the Mobility message replay protection 924 option, defined in [4]. The Home Agent extracts this value from the 925 received BU message, if available. 927 The support for replay protection is an optional feature in [4]. 928 When the Diameter server checks the timestamp provided by the MN via 929 the HA and recognizes a clock-drift (outside a locally defined replay 930 protection window) then it MUST initiate the re-synchronization 931 procedure by returning a MIP6-Answer-Message with Result-Code set to 932 MIP6-TIMESTAMP-MISMATCH and attaches the MIP-Timestamp AVP including 933 it's current time back to the HA. 935 6.16. QoS-Capability AVP 937 The QoS-Capability AVP is defined in [10] and contains a list of 938 supported Quality of Service profiles. 940 6.17. QoS-Resources AVP 942 The QoS-Resources AVP is defined in [10] and provides QoS and packet 943 filtering capabilities. 945 6.18. Accounting AVPs 947 This document reuses the accounting AVPs defined in Diameter Mobile 948 IPv4 application [12], namely: 950 Accounting-Input-Octets: 952 Number of octets in IP packets received from the user 954 Accounting-Output-Octets: 956 Number of octets in IP packets sent by the user 958 Accounting-Input-Packets: 960 Number of IP packets received from the user 962 Accounting-Output-Packets: 964 Number of IP packets sent by the user. 966 7. Result-Code AVP Values 968 This section defines new Result-Code [5] values that MUST be 969 supported by all Diameter implementations that conform to this 970 specification. 972 7.1. Transient Failures 974 Errors in the transient failures category are used to inform a peer 975 that the request could not be satisfied at the time it was received, 976 but that it may be able to satisfy the request in the future. 978 MIP6-TIMESTAMP-MISMATCH TBD 980 This error code is used by the home agent to indicate to the HA 981 that the timestamp value provided as part of the MN-AAA option has 982 an inacceptable clock-drift. 984 7.2. Permanent Failures 986 Errors that fall within the permanent failures category are used to 987 inform the peer that the request failed and SHOULD NOT be attempted 988 again. 990 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION TBD 992 This error is used by the Diameter server to inform the peer that 993 the requested Mobile IPv6 session keys could not be delivered via 994 a security association. 996 8. AVP Occurence Tables 998 The following tables present the AVPs defined in this document and 999 their occurrences in Diameter messages. Note that AVPs that can only 1000 be present within a Grouped AVP are not represented in this table. 1002 The table uses the following symbols: 1004 0: 1006 The AVP MUST NOT be present in the message. 1008 0+: 1010 Zero or more instances of the AVP MAY be present in the message. 1012 0-1: 1014 Zero or one instance of the AVP MAY be present in the message. 1016 1: 1018 One instance of the AVP MUST be present in the message. 1020 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table 1022 +-----------------------------------+ 1023 | Command-Code | 1024 |-----+-----+-----+-----+-----+-----+ 1025 AVP Name | AAR | AAA | DER | DEA | MRM | MAM | 1026 -------------------------------|-----+-----|-----+-----+-----+-----+ 1027 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1028 MIP-Mobile-Node-Address | 1 | 0-1 | 1 | 0-1 | 1 | 0-1 | 1029 MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 1 | 0 | 1030 MIP-Home-Agent-Address | 0-1 | 0 | 0-1 | 0 | 1 | 0 | 1031 MIP-Careof-Address | 0 | 0 | 0 | 0 | 1 | 0 | 1032 MIP-Authenticator | 0 | 0 | 0 | 0 | 1 | 0 | 1033 MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 1 | 0 | 1034 MIP-Session-Key | 0 | 0 | 0 | 0 | 0 | 1 | 1035 MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 | 1036 MIP-MN-to-HA-MSA | 0 | 0 | 0 | 0 | 0 | 1 | 1037 MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1038 QoS-Resources (1) | 0 | 0 | 0 | 0 | *0 | *0 | 1039 QoS-Capability (1) | 0 | 0 | 0 | 0 | 0-1 | 0 | 1040 +-----+-----+-----+-----+-----+-----+ 1042 Note (1): The QoS-Capability and QoS-Resources AVPs usage with 1043 Diameter EAP and Diameter NASREQ is already defined in [10]. 1045 8.2. Accounting AVP Table 1047 The table in this section is used to represent which AVPs defined in 1048 this document are to be present in the Accounting messages, as 1049 defined in [5]. 1051 +-------------+ 1052 | Command-Code| 1053 |------+------+ 1054 Attribute Name | ACR | ACA | 1055 -------------------------------------|------+------+ 1056 Accounting-Input-Octets | 1 | 0-1 | 1057 Accounting-Input-Packets | 1 | 0-1 | 1058 Accounting-Output-Octets | 1 | 0-1 | 1059 Accounting-Output-Packets | 1 | 0-1 | 1060 Acct-Multi-Session-Id | 1 | 0-1 | 1061 Acct-Session-Time | 1 | 0-1 | 1062 MIP6-Feature-Vector | 1 | 0-1 | 1063 MIP-Home-Agent-Address | 1 | 0-1 | 1064 MIP-Mobile-Node-Address | 1 | 0-1 | 1065 Event-Timestamp | 0-1 | 0 | 1066 -------------------------------------|------+------+ 1068 9. IANA Considerations 1070 This section contains the namespaces that have either been created in 1071 this specification or had their values assigned to existing 1072 namespaces managed by IANA. 1074 9.1. Command Codes 1076 IANA is requested to allocate a command code value for the MIP6- 1077 Request-Message (MRM) and for the MIP6-Answer-Message (MAM) from the 1078 Command Code namespace defined in [5]. See Section 5 for the 1079 assignment of the namespace in this specification. 1081 9.2. AVP Codes 1083 This specification requires IANA to register the following new AVPs 1084 from the AVP Code namespace defined in [5]. 1085 o MIP-Careof-Address 1086 o MIP-Authenticator 1087 o MIP-MAC-Mobility-Data 1088 o MIP-Timestamp 1089 The AVPs are defined in Section 6. 1091 9.3. Result-Code AVP Values 1093 This specification requests IANA to allocate new values to the 1094 Result-Code AVP (AVP Code 268) namespace defined in [5]. See 1095 Section 7 for the assignment of the namespace in this specification. 1097 9.4. Application Identifier 1099 This specification requires IANA to allocate a new value for 1100 "Diameter Mobile IPv6" from the Application Identifier namespace 1101 defined in [5]. 1103 10. Security Considerations 1105 The security considerations for the Diameter interaction required to 1106 accomplish the split scenario are described in in [13]. 1107 Additionally, the security considerations of the Diameter Base 1108 protocol [5], Diameter EAP application [7] are applicable to this 1109 document. This document does not introduce new security 1110 vulnerabilities. 1112 11. Acknowledgements 1114 The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi 1115 Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John 1116 Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay 1117 Devarapalli, Lionel Morand and Yoshihiro Ohba for all the useful 1118 discussions. Ahmad Muhanna provided a detailed review of the 1119 document in August 2007. 1121 We would also like to thank our Area Director, Dan Romascanu, for his 1122 support. 1124 Hannes Tschofenig would like to thank the European Commission support 1125 in the co-funding of the ENABLE project, where this work is partly 1126 being developed. 1128 Julien Bournelle would like to thank GEN/INT since he began this work 1129 while he was under their employ. 1131 12. References 1133 12.1. Normative References 1135 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1136 IPv6", RFC 3775, June 2004. 1138 [2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1139 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1141 [3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1142 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1143 April 2007. 1145 [4] Patel, A., "Authentication Protocol for Mobile IPv6", 1146 draft-ietf-mip6-rfc4285bis-00 (work in progress), March 2007. 1148 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1149 "Diameter Base Protocol", RFC 3588, September 2003. 1151 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1152 Levels", BCP 14, RFC 2119, March 1997. 1154 [7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1155 Authentication Protocol (EAP) Application", RFC 4072, 1156 August 2005. 1158 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1159 RFC 4306, December 2005. 1161 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1162 Network Access Server Application", RFC 4005, August 2005. 1164 [10] Korhonen, J., "Quality of Service Attributes for Diameter and 1165 RADIUS", draft-ietf-dime-qos-attributes-01 (work in progress), 1166 July 2007. 1168 [11] Korhonen, J., "Diameter Mobile IPv6: Support for Network Access 1169 Server to Diameter Server Interaction", 1170 draft-ietf-dime-mip6-integrated-05 (work in progress), 1171 July 2007. 1173 [12] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 1174 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1175 August 2005. 1177 12.2. Informative References 1179 [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1180 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 1181 July 2007. 1183 [14] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1184 Integrated Scenario", 1185 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1186 progress), July 2007. 1188 [15] Giaretta, G., "AAA Goals for Mobile IPv6", 1189 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1190 September 2006. 1192 [16] Fajardo, V., "Diameter Applications Design Guidelines", 1193 draft-ietf-dime-app-design-guide-02 (work in progress), 1194 July 2007. 1196 [17] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1197 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1198 RFC 4283, November 2005. 1200 Authors' Addresses 1202 Jouni Korhonen (editor) 1203 TeliaSonera 1204 Teollisuuskatu 13 1205 Sonera FIN-00051 1206 Finland 1208 Email: jouni.korhonen@teliasonera.com 1210 Hannes Tschofenig 1211 Nokia Siemens Networks 1212 Otto-Hahn-Ring 6 1213 Munich, Bavaria 81739 1214 Germany 1216 Email: Hannes.Tschofenig@nsn.com 1217 URI: http://www.tschofenig.com 1218 Julien Bournelle 1219 France Telecom R&D 1220 38-4O rue du general Leclerc 1221 Issy-Les-Moulineaux 92794 1222 France 1224 Email: julien.bournelle@orange-ftgroup.com 1226 Gerardo Giaretta 1227 Qualcomm 1229 Email: gerardo.giaretta@gmail.com 1231 Madjid Nakhjiri 1232 Motorola 1233 USA 1235 Email: madjid.nakhjiri@motorola.com 1237 Full Copyright Statement 1239 Copyright (C) The IETF Trust (2007). 1241 This document is subject to the rights, licenses and restrictions 1242 contained in BCP 78, and except as set forth therein, the authors 1243 retain all their rights. 1245 This document and the information contained herein are provided on an 1246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1248 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1249 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1250 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1253 Intellectual Property 1255 The IETF takes no position regarding the validity or scope of any 1256 Intellectual Property Rights or other rights that might be claimed to 1257 pertain to the implementation or use of the technology described in 1258 this document or the extent to which any license under such rights 1259 might or might not be available; nor does it represent that it has 1260 made any independent effort to identify any such rights. Information 1261 on the procedures with respect to rights in RFC documents can be 1262 found in BCP 78 and BCP 79. 1264 Copies of IPR disclosures made to the IETF Secretariat and any 1265 assurances of licenses to be made available, or the result of an 1266 attempt made to obtain a general license or permission for the use of 1267 such proprietary rights by implementers or users of this 1268 specification can be obtained from the IETF on-line IPR repository at 1269 http://www.ietf.org/ipr. 1271 The IETF invites any interested party to bring to its attention any 1272 copyrights, patents or patent applications, or other proprietary 1273 rights that may cover technology that may be required to implement 1274 this standard. Please address the information to the IETF at 1275 ietf-ipr@ietf.org. 1277 Acknowledgment 1279 Funding for the RFC Editor function is provided by the IETF 1280 Administrative Support Activity (IASA).