idnits 2.17.1 draft-ietf-dime-mip6-split-06.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 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. 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 (November 19, 2007) is 6002 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) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-rfc4285bis-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-rfc4285bis (ref. '3') ** 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-03 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-06 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-05 Summary: 6 errors (**), 0 flaws (~~), 5 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: May 22, 2008 J. Bournelle 7 France Telecom R&D 8 G. Giaretta 9 Qualcomm 10 M. Nakhjiri 11 Motorola 12 November 19, 2007 14 Diameter Mobile IPv6: Support for Home Agent to Diameter Server 15 Interaction 16 draft-ietf-dime-mip6-split-06.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 May 22, 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 that 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 to 59 be used. Furthermore, another method makes use of the Mobile IPv6 60 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 Authentication 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 . . . . . . . . . . . . . . . . . . . . . . 20 96 6.2. MIP-MN-AAA-SPI AVP . . . . . . . . . . . . . . . . . . . . 21 97 6.3. MIP-MN-to-HA-SPI AVP . . . . . . . . . . . . . . . . . . . 21 98 6.4. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . . 21 99 6.5. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . . . 21 100 6.6. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 21 101 6.7. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 22 102 6.8. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 22 103 6.9. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 22 104 6.10. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 22 105 6.11. MIP-MN-to-HA-MSA AVP . . . . . . . . . . . . . . . . . . . 22 106 6.12. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 23 107 6.13. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 23 108 6.14. MIP-nonce AVP . . . . . . . . . . . . . . . . . . . . . . 23 109 6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 23 110 6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 23 111 6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 24 112 6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 24 113 6.19. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 24 114 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 25 115 7.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 25 116 7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 25 117 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 26 118 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table . . 26 119 8.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . . 27 120 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 121 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 27 122 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 27 123 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 28 124 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 28 125 9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 28 126 9.6. Mobile IPv6 Status Codes . . . . . . . . . . . . . . . . . 28 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 128 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 129 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 130 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 131 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 133 Intellectual Property and Copyright Statements . . . . . . . . . . 32 135 1. Introduction 137 Performing the Mobile IPv6 protocol [1], requires the Mobile Node 138 (MN) to own a Home Address (HoA) and to have an assigned Home Agent 139 (HA) to the MN. The MN needs to register with the HA in order enable 140 its reachability and mobility, when away from home. The registration 141 process itself requires establishment of IPsec security associations 142 (SA) and cryptographic material between the MN and HA. Providing the 143 collection of home address, HA address and keying material is 144 generally referred to as the Mobile IPv6 bootstrapping problem [13]. 145 The purpose of this specification is to provide Diameter support for 146 the interaction between the HA and the AAA server required to solve 147 the bootstrapping problem in the split scenario [2] in a manner that 148 satisfies the requirements defined in [14]. 150 From a mobility service provider (MSP) perspective, it is important 151 to verify that the MN is authenticated and authorized to utilize 152 Mobile IPv6 service and that such services are accounted for. Only 153 when the MN is authenticated and authorized, the MSP allows the 154 bootstrapping of Mobile IPv6 parameters. Thus, prior to processing 155 the Mobile IPv6 registrations, the HA, participates in the 156 authentication of the MN to verify the MN's identity. The HA also 157 participates in the Mobile IPv6 authorization process involving the 158 Diameter infrastructure. The HA, due to its role in traffic 159 forwarding, may also perform accounting for the Mobile IPv6 service 160 provided to the MN. 162 This document enables the following functionality: 164 Authentication: Asserting or helping with assertion of the 165 correctness of the MN identity. As a Diameter client supporting 166 the new Diameter Mobile IPv6 application, the HA may need to 167 support more than one authentication type depending on the 168 environment. Although the authentication is performed by the AAA 169 server there is an impact for the HA as different set of command 170 codes are needed for the respective authentication procedures. 172 Authorization: The HA must verify that the user is authorized to use 173 the Mobile IPv6 service using the assistance of the MSP Diameter 174 servers. This is accomplished through the use of new Diameter 175 commands specifically designed for performing Mobile IPv6 176 authorization decisions. This document defines these commands and 177 requires the HA to support them and to participate in this 178 authorization signaling. 180 Accounting: For accounting purposes and capacity planning, it is 181 required of the HA to provide accounting report to the Diameter 182 infrastructure and thus to support the related Diameter accounting 183 procedures. 185 Figure 1 depicts the reference architecture for this document. 187 +--------+ 188 |Diameter| 189 |Server | 190 +--------+ 191 ^ 192 Back-End | Diameter MIPv6 193 Protocol | HA<->AAA Server 194 Support | Interaction 195 | (this document) 196 v 197 +---------+ +---------------+ 198 | Mobile | Front-End Protocol |Home Agent / | 199 | Node |<--------------------------|Diameter Client| 200 +---------+ IKEv2 or RFC 4285 +---------------+ 202 Figure 1: Architecture Overview 204 Mobile IPv6 signaling between the MN and the HA can protected using 205 two different mechanisms, namely using IPsec and via the MIPv6 206 Authentication Protocol [3]. The important aspect is, however, that 207 for these two approaches several different authentication and key 208 exchange solutions are available. To establish IPsec security 209 associations, protecting of Mobile IPv6 signaling messages IKEv2 is 210 used [4]. IKEv2 supports EAP-based authentication, certificates and 211 pre-shared secrets. For protecting using the MIPv6 Authentication 212 Protocol [3] a mechanism has been designed that is very similar to 213 the one used by Mobile IPv4. 215 The ability to use different credentials has an impact on the 216 interaction between the HA (acting as a Diameter client) and the 217 Diameter Server. For that reason this document illustrates the usage 218 of these authentication mechanisms with different subsections for: 220 o IKEv2 usage with EAP 221 o IKEv2 usage with certificates and pre-shared secrets 222 o MIPv6 Authentication Protocol 224 For accounting of Mobile IPv6 services provided to the MN, this 225 specification uses the accounting application defined in [5]. 227 2. Terminology 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in RFC 2119 [6]. 233 The MIPv6 bootstrapping terminology is taken from [13]. 235 3. Advertising Application Support 237 Diameter nodes conforming to this specification MUST advertise 238 support by including the Diameter Mobile IPv6 Application ID value of 239 [TO BE ASSIGNED BY IANA] in the Auth-Application-Id AVP of the 240 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 241 command [5]. The Acct-Application-id AVP needs to include the 242 Diameter Base Accounting Application ID value of 3 (to support the 243 split accounting model [15]). 245 4. Protocol Description 247 4.1. Support for Mobile IPv6 with IKEv2 and EAP 249 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 250 authenticate the MN. When EAP is used with IKEv2, the Diameter EAP 251 application, as defined in [7], is re-used. EAP methods that do not 252 establish a shared key SHOULD NOT be used, as they are subject to a 253 number of man-in-the-middle attacks as stated in Section 2.16 and 254 Section 5 of RFC 4306 [8]. AVPs specific to Mobile IPv6 255 bootstrapping are added to the EAP application commands. 257 Figure 2 shows the message flow involved during the authentication 258 phase when EAP is used. 260 Mobile Home Diameter 261 Node Agent Server 262 | | | 263 | HDR, SAi1, KEi, Ni (1) | | 264 |-------------------------------->| | 265 | | | 266 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 267 |<--------------------------------| | 268 | | | 269 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 270 | [CP(CFG_REQUEST),] | | 271 | SAi2, TSi, TSr} (3) | | 272 |-------------------------------->| DER (EAP-Response) (4) | 273 | |------------------------->| 274 | | | 275 | | DEA (EAP-Request) (5) | 276 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------| 277 |<------------------------------- | | 278 | | | 279 | HDR, SK{EAP} | | 280 |-------------------------------->| DER (EAP-Response) | 281 | |------------------------->| 282 | | | 283 | | DEA (EAP-Request) | 284 | HDR, SK{EAP-Request} |<-------------------------| 285 |<------------------------------- | | 286 | | | 287 | HDR, SK{EAP-Response} | | 288 |-------------------------------->| DER (EAP-Response) | 289 | |------------------------->| 290 | ... | ... | 291 | | | 292 | | DEA (EAP-Success) | 293 | |<-------------------------| 294 | HDR, SK{EAP-Success} | | 295 |<------------------------------- | | 296 | | | 297 | HDR, SK{AUTH} | | 298 |-------------------------------> | | 299 | | | 300 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 301 | SAr2, TSi, TSr} | | 302 |<------------------------------- | | 303 | | | 305 Figure 2: Mobile IPv6 with IKEv2 and EAP 307 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 309 In this phase cryptographic algorithms are negotiated, nonces and 310 Diffie-Hellman parameters are exchanged. Message (3) starts the 311 IKE_AUTH phase. This second phase authenticates the previous 312 messages, exchanges identities and certificates and establishes the 313 first CHILD_SA. It is used to mutually authenticate the MN (acting 314 as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). 315 The identity of the user/MN is provided in the IDi field. The MN 316 indicates its willingness to be authenticated via EAP by omitting the 317 AUTH field in message (3) (see Section 2.16 of [8]). 319 As part of the authentication process, the MN MAY request a Home- 320 Address, a Home Prefix or suggests one, see [4], using a CFG_REQUEST 321 payload in the message (3). 323 The HA extracts the IDi field from the message (3) and sends a 324 Diameter-EAP-Request (DER) message (4) towards the authenticating 325 Diameter server. The EAP-Payload AVP contains a EAP-Response/ 326 Identity with the identity extracted from the IDi field. 328 This message is routed to the MNs Diameter server/EAP server. The 329 Diameter server selects the EAP method and replies with the DEA 330 Message. Depending on the type of EAP method chosen, a number of DER 331 and DEA messages carry the method specific exchanges between the MN 332 and the Diameter server/EAP server. 334 At the end of the EAP authentication phase, the Diameter server 335 indicates the result of the authentication in the Result-Code AVP and 336 provides the corresponding EAP packet (EAP Success or EAP Failure). 337 The last IKEv2 message sent by the HA contains the Home Address or 338 the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 339 necessary to setup IPsec SAs for Mobile IPv6 signaling. 341 In some deployment scenario, the HA may also acts as a IKEv2 342 Responder for IPsec VPN access. A problem in this case is that the 343 IKEv2 responder may not know if IKEv2 is used for MIP6 service or for 344 IPsec VPN access. The IKEv2 responder may A network operator needs 345 to be aware of this limitation. 347 4.2. Support for Mobile IPv6 with IKEv2 and Certificates 349 When IKEv2 is used with certificate-based authentication, the 350 Diameter NASREQ application [9] is used to authorize the MN for the 351 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 352 message MUST correspond to the identity in the MN's certificate. 353 This identity is then used by the Home Agent to populate the User- 354 Name AVP in the succeeding AA-Request message. Further PKI-related 355 procedures such as certificate revocation checking are out of scope 356 of this document. 358 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets 360 When IKEv2 is used with PSK-based initiator authentication, the 361 Diameter NASREQ application [9] is used to authorize the MN for the 362 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 363 message has to contain an identity that is meaningful for the 364 Diameter infrastructure, such as a Network Access Identifier (NAI), 365 and is then used by the Home Agent to populate the User-Name AVP in 366 the succeeding AA-Request message. 368 4.4. Support for the Mobile IPv6 Authentication Protocol 370 Figure 3 describes the sequence of messages sent and received between 371 the MN, the HA and the Diameter server during the registration when 372 MIPv6 Authentication Protocol is used. Binding Update (BU) and 373 Binding Acknowledgement (BA) messages are used in the registration 374 process. This exchange triggers the Diameter interaction. 376 According to [3] the MN uses the Mobile Node Identifier Option, 377 specifically the MN-NAI mobility option (as defined in [16]) to 378 identify itself. 380 Receiving the BU at the HA initiates a MIP6-Request-Message to the 381 Diameter server, which in turn responds with a MIP6-Answer-Message. 382 The Home Agent also provides the assigned Home Address to the 383 Diameter server in the MIP-Mobile-Node-Address AVP. 385 Mobile Home Diameter 386 Node Agent Server 387 | | | 388 | | | 389 | Binding Update |MIP6-Request-Message | 390 |------------------------------------>|-------------------->| 391 | (Mobile Node Identifier Option, | | 392 | Mobility Message Replay Protection | | 393 | Option, Authentication Option) | | 394 | | | 395 | | | 396 | Binding Acknowledgement |MIP6-Answer-Message | 397 |<------------------------------------|<--------------------| 398 | (Mobile Node Identifier Option | | 399 | Mobility Message Replay Protection | | 400 | Option, Authentication Option) | | 402 Figure 3: MIPv6 Bootstrapping using the MIPv6 Authentication Protocol 404 4.5. Mobile IPv6 Session Management 406 The Diameter server may maintain state or may be stateless. This is 407 indicated in the Auth-Session-State AVP (or its absence). The HA 408 MUST support the Authorization Session State Machine defined in [5]. 409 Moreover, the following four commands may be exchanged between the HA 410 and the Diameter server. 412 4.5.1. Session-Termination-Request Command 414 The Session-Termination-Request (STR) message [5] is sent by the HA 415 to inform the Diameter server that an authorized session is being 416 terminated. 418 4.5.2. Session-Termination-Answer Command 420 The Session-Termination-Answer (STA) message [5] is sent by the 421 Diameter server to acknowledge the notification that the session has 422 been terminated. 424 4.5.3. Abort-Session-Request Command 426 The Abort-Session-Request (ASR) message [5] is sent by the Diameter 427 server to terminate the session. This fulfills one of the 428 requirement described in [14]. 430 4.5.4. Abort-Session-Answer Command 432 The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent 433 in response to an ASR message. 435 4.6. Accounting for Mobile IPv6 services 437 The HA MUST be able act as a Diameter client collecting accounting 438 records needed for service control and charging. The HA MUST support 439 the accounting procedures (specifically the command codes mentioned 440 below) and the Accounting Session State Machine as defined in [5]. 441 The command codes, exchanged between the HA and Diameter server for 442 accounting purposes, are provided in the following subsections. 444 The Diameter application design guideline [15] defines two separate 445 models for accounting: 447 Split accounting model: 449 According to this model, the accounting messages use the Diameter 450 base accounting application ID (value of 3). Since accounting is 451 treated as an independent application, accounting commands may be 452 routed separately from the rest of application messages and thus 453 the accounting messages generally end up in a central accounting 454 server. Since Diameter Mobile IPv6 application does not define 455 its own unique accounting commands, this is the preferred choice, 456 since it permits use of centralized accounting for several 457 applications. 459 Coupled accounting model: 461 In this model, the accounting messages will use the application ID 462 of the Mobile IPv6 application. This means that accounting 463 messages will be routed like any other Mobile IPv6 application 464 messages. This requires the Diameter server in charge of Mobile 465 IPv6 application to handle the accounting records (e.g., sends 466 them to a proper accounting server). 468 As mentioned above, the preferred choice is to use the split 469 accounting model and thus to choose Diameter base accounting 470 application ID (value of 3) for accounting messages. 472 4.6.1. Accounting-Request Command 474 The Accounting-Request command [5] is sent by the HA to the Diameter 475 server to exchange accounting information regarding the MN with the 476 Diameter server. 478 4.6.2. Accounting-Answer Command 480 The Accounting-Answer command [5] is sent by the Diameter server to 481 the HA to acknowledge receiving an Accounting-Request. 483 5. Command Codes 485 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP 487 For usage of Mobile IPv6 with IKEv2 and EAP this document re-uses the 488 Diameter EAP application [7] commands. The following commands are 489 used to carry MIPv6 related bootstrapping AVPs. 491 Command-Name Abbrev. Code Reference Application 492 ----------------------------------------------------------------------- 493 Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 (TBD) 494 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 (TBD) 496 Figure 4: Command Codes 498 5.1.1. Diameter-EAP-Request (DER) 500 The Diameter-EAP-Request (DER) message [7], indicated by the Command- 501 Code field set to 268 and the 'R' bit set in the Command Flags field, 502 is sent by the HA to the Diameter server to initiate a Mobile IPv6 503 service authentication and authorization procedure. The DER message 504 format is the same as defined in [7]. The Application-ID field of 505 the Diameter Header MUST be set to the Diameter Mobile IPv6 506 Application ID [TO BE ASSIGNED TO IANA]. 508 ::= < Diameter Header: 268, REQ, PXY > 509 < Session-Id > 510 { Auth-Application-Id } 511 { Origin-Host } 512 { Origin-Realm } 513 { Destination-Realm } 514 { Auth-Request-Type } 515 [ Destination-Host ] 516 [ NAS-Identifier ] 517 [ NAS-IP-Address ] 518 [ NAS-IPv6-Address ] 519 [ NAS-Port-Type ] 520 [ User-Name ] 521 { EAP-Payload } 522 ... 524 [ MIP6-Feature-Vector ] 525 { MIP-Home-Agent-Address } 526 { MIP-Careof-Address } 527 { MIP-Mobile-Node-Address } 529 [ QoS-Capability ] 530 * [ QoS-Resources ] 531 ... 532 * [ AVP ] 534 5.1.2. Diameter-EAP-Answer (DEA) 536 The Diameter-EAP-Answer (DEA) message defined in [7], indicated by 537 the Command-Code field set to 268 and 'R' bit cleared in the Command 538 Flags field, is sent in response to the Diameter-EAP-Request message 539 (DER). If the Mobile IPv6 authentication procedure was successful 540 then the response MAY include any set of bootstrapping AVPs. 542 The DEA message format is the same as defined in [7]. The 543 Application-Id field in the Diameter header MUST be set to the 544 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 546 ::= < Diameter Header: 268, PXY > 547 < Session-Id > 548 { Auth-Application-Id } 549 { Auth-Request-Type } 550 { Result-Code } 551 { Origin-Host } 552 { Origin-Realm } 553 [ User-Name ] 554 [ EAP-Payload ] 555 ... 557 [ MIP-Mobile-Node-Address ] 558 [ MIP6-Feature-Vector ] 559 * [ QoS-Resources ] 560 ... 561 * [ AVP ] 563 5.2. Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK- 564 based Authentication 566 This document re-uses the Diameter NASREQ application commands. The 567 following commands are used to carry MIPv6 related bootstrapping 568 AVPs. 570 Command-Name Abbrev. Code Reference Application 571 ----------------------------------------------------------------------- 572 AA-Request AAR 265 RFC 4005 Diameter Mobile IPv6 (TBD) 573 AA-Answer AAA 265 RFC 4005 Diameter Mobile IPv6 (TBD) 575 Figure 7: Command Codes 577 5.2.1. AA-Request (AAR) 579 The AA-Request (AAR) message [9], indicated by the Command-Code field 580 set to 265 and the 'R' bit set in the Command Flags field, is sent by 581 the HA to the Diameter server to initiate a Mobile IPv6 service 582 authentication and authorization procedure. The AAR message format 583 is the same as defined in [9]. The Application-ID field of the 584 Diameter Header MUST be set to the Diameter Mobile IPv6 Application 585 ID [TO BE ASSIGNED TO IANA]. 587 ::= < Diameter Header: 265, REQ, PXY > 588 < Session-Id > 589 { Auth-Application-Id } 590 { Origin-Host } 591 { Origin-Realm } 592 { Destination-Realm } 593 { Auth-Request-Type } 594 [ Destination-Host ] 595 [ NAS-Identifier ] 596 [ NAS-IP-Address ] 597 [ NAS-IPv6-Address ] 598 [ NAS-Port-Type ] 599 [ User-Name ] 600 ... 602 [ MIP6-Feature-Vector ] 603 { MIP-Home-Agent-Address } 604 { MIP-Careof-Address } 605 { MIP-Mobile-Node-Address } 607 [ QoS-Capability ] 608 * [ QoS-Resources ] 609 ... 610 * [ AVP ] 612 5.2.2. AA-Answer (AAA) 614 The AA-Answer (AAA) message defined in [9], indicated by the Command- 615 Code field set to 265 and 'R' bit cleared in the Command Flags field, 616 is sent in response to the AA-Request message (AAR). If the Mobile 617 IPv6 authentication procedure was successful then the response MAY 618 include any set of bootstrapping AVPs. 620 The AAA message format is the same as defined in [9]. The 621 Application-Id field in the Diameter header MUST be set to the 622 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 624 ::= < Diameter Header: 265, PXY > 625 < Session-Id > 626 { Auth-Application-Id } 627 { Auth-Request-Type } 628 { Result-Code } 629 { Origin-Host } 630 { Origin-Realm } 631 [ User-Name ] 632 [ Authorization-Lifetime ] 633 ... 635 [ MIP-Mobile-Node-Address ] 636 [ MIP6-Feature-Vector ] 637 * [ QoS-Resources ] 638 ... 639 * [ AVP ] 641 5.3. Command Codes for MIPv6 Authentication Protocol Support 643 This section defines the commands that are used for support with the 644 MIPv6 Authentication Protocol. 646 Command-Name Abbrev. Code Reference Application 647 ---------------------------------------------------------------------- 648 MIP6-Request-Message MRM TBD 5.3.1 Diameter Mobile IPv6 (TBD) 649 MIP6-Answer-Message MAM TBD 5.3.2 Diameter Mobile IPv6 (TBD) 651 Command Codes 653 5.3.1. MIP6-Request-Message 655 The MIP6-Request-Message (MRM), indicated by the Command-Code field 656 set to TBD and the 'R' bit set in the Command Flags field, is sent by 657 the HA, acting as a Diameter client, in order to request the 658 authentication and authorization of a MN. The HA uses information 659 found in the Binding Update to construct the following AVPs, to be 660 included as part of the MRM: 662 o Home Address (MIP-Mobile-Node-Address AVP) 663 o Mobile Node NAI (User-Name AVP [5]) 664 o MN-AAA Authentication Option (MIP-MN-AAA-Auth AVP) 665 o Care-of Address (MIP-Careof-Address AVP) 666 o Mobility message replay protection Option using timestamps (MIP- 667 Timestamp AVP) 669 The message format is shown below. 671 ::= < Diameter Header: XXX, REQ, PXY > 672 < Session-ID > 673 { Auth-Application-Id } 674 { User-Name } 675 { Destination-Realm } 676 { Origin-Host } 677 { Origin-Realm } 678 [ Acct-Multi-Session-Id ] 679 [ Destination-Host ] 680 [ Origin-State-Id ] 681 [ NAS-Identifier ] 682 [ NAS-IP-Address ] 683 [ NAS-IPv6-Address ] 684 [ NAS-Port-Type ] 686 [ MIP6-Feature-Vector ] 687 [ MIP-MN-AAA-SPI ] 688 { MIP-Mobile-Node-Address } 689 { MIP-Home-Agent-Address } 690 { MIP-Careof-Address } 691 [ MIP-Authenticator ] 692 [ MIP-MAC-Mobility-Data ] 693 [ MIP-Timestamp ] 694 [ QoS-Capability ] 695 * [ QoS-Resources ] 697 [ Authorization-Lifetime ] 698 [ Auth-Session-State ] 699 * [ Proxy-Info ] 700 * [ Route-Record ] 701 * [ AVP ] 703 5.3.2. MIP6-Answer-Message 705 The MIP6-Answer-Message (MAM) message, indicated by the Command-Code 706 field set to TBD and the 'R' bit cleared in the Command Flags field, 707 is sent by the Diameter server in response to the MIP6-Request- 708 Message message. The User-Name MAY be included in the MAM if it is 709 present in the MRM. The Result-Code AVP MAY contain one of the 710 values defined in Section 7, in addition to the values defined in RFC 711 3588 [5]. 713 An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 714 include the MIP-Mobile-Node-Address AVP. 716 The message format is shown below. 718 ::= < Diameter Header: XXX, PXY > 719 < Session-Id > 720 { Auth-Application-Id } 721 { Result-Code } 722 { Origin-Host } 723 { Origin-Realm } 724 [ Acct-Multi-Session-Id ] 725 [ User-Name ] 726 [ Authorization-Lifetime ] 727 [ Auth-Session-State ] 728 [ Error-Message ] 729 [ Error-Reporting-Host ] 730 [ Re-Auth-Request-Type ] 732 [ MIP6-Feature-Vector ] 733 [ MIP-Home-Agent-Address ] 734 [ MIP-Mobile-Node-Address ] 735 [ MIP-Session-Key ] 736 [ MIP-MSA-Lifetime ] 737 [ MIP-MN-to-HA-MSA ] 738 * [ QoS-Resources ] 740 [ Origin-State-Id ] 741 * [ Proxy-Info ] 742 * [ AVP ] 744 The QoS-Resources AVP is defined in [10]. 746 6. AVPs 748 To provide support for RFC 4285 [3] and for RFC 4877 [4] the AVPs in 749 the following subsections are needed. RFC 3588, RFC 4004 and RFC 750 4005 defined AVPs are reused whenever possible without changing the 751 existing semantics of those AVPs. 753 +--------------------------+ 754 | AVP Flag rules | 755 +----+-----+----+-----+----+ 756 AVP Defined | | |SHLD| MUST|MAY | 757 Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr| 758 +-----------------------------------------+----+-----+----+-----+----+ 759 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 760 | Vector | | | | | | 761 +-----------------------------------------+----+-----+----+-----+----+ 762 |MIP-Mobile- | M | P | | V | Y | 763 |Node-Address 334 RFC4004 Address | | | | | | 764 +-----------------------------------------+----+-----+----+-----+----+ 765 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 766 | Agent-Address | | | | | | 767 +-----------------------------------------+----+-----+----+-----+----+ 768 |QoS-Capability TBD Note 2 Grouped | | P | | M,V | Y | 769 +-----------------------------------------+----+-----+----+-----+----+ 770 |QoS-Resources TBD Note 2 Grouped | | P | | M,V | Y | 771 +-----------------------------------------+----+-----+----+-----+----+ 773 AVPs for Mobile IPv6 with IKEv2 775 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [11]. 777 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 778 Sections 4.1 and 4.3 of [10]. 780 +--------------------------+ 781 | AVP Flag rules | 782 +----+-----+----+-----+----+ 783 AVP Section | | |SHLD| MUST|MAY | 784 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 785 +-----------------------------------------+----+-----+----+-----+----+ 786 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 787 | Vector | | | | | | 788 +-----------------------------------------+----+-----+----+-----+----+ 789 |MIP-Mobile- 333 RFC4004 Address | M | P | | V | Y | 790 | Node-Address | | | | | | 791 +-----------------------------------------+----+-----+----+-----+----+ 792 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 793 | Agent-Address | | | | | | 794 +-----------------------------------------+----+-----+----+-----+----+ 795 |MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | M | P | | V | Y | 796 +-----------------------------------------+----+-----+----+-----+----+ 797 |MIP-MN-to- TBD 6.3 Unsigned32 | M | P | | V | Y | 798 | HA-SPI | | | | | | 799 +-----------------------------------------+----+-----+----+-----+----+ 800 |MIP-Careof- TBD 6.6 Address | M | P | | V | Y | 801 | Address | | | | | | 802 +-----------------------------------------+----+-----+----+-----+----+ 803 |MIP- TBD 6.7 OctetString| M | P | | V | Y | 804 | Authenticator | | | | | | 805 +-----------------------------------------+----+-----+----+-----+----+ 806 |MIP-MAC- TBD 6.8 OctetString| M | P | | V | Y | 807 | Mobility-Data | | | | | | 808 +-----------------------------------------+----+-----+----+-----+----+ 809 |MIP-Session-Key 343 6.9 OctetString| M | P | | V | Y | 810 +-----------------------------------------+----+-----+----+-----+----+ 811 |MIP-Timestamp TBD 6.16 Time | M | P | | V | Y | 812 +-----------------------------------------+----+-----+----+-----+----+ 813 |MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y | 814 | Lifetime | | | | | | 815 +-----------------------------------------+----+-----+----+-----+----+ 816 |MIP-MN-to- 331 RFC4004 Grouped | M | P | | V | Y | 817 | HA-MSA | | | | | | 818 +-----------------------------------------+----+-----+----+-----+----+ 819 |MIP-Algorithm- 345 6.12 Enumerated | M | P | | V | Y | 820 | Type | | | | | | 821 +-----------------------------------------+----+-----+----+-----+----+ 822 |MIP-Replay-Mode 346 6.13 Enumerated | M | P | | V | Y | 823 +-----------------------------------------+----+-----+----+-----+----+ 824 |MIP-Nonce 335 6.14 OctetString| M | P | | V | Y | 825 +-----------------------------------------+----+-----+----+-----+----+ 826 |QoS-Capability TBD Note 2 Grouped | | P | | M,V | Y | 827 +-----------------------------------------+----+-----+----+-----+----+ 828 |QoS-Resources TBD Note 2 Grouped | | P | | M,V | Y | 829 +-----------------------------------------+----+-----+----+-----+----+ 831 AVPs for the Mobile IPv6 Authentication Protocol 833 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [11]. 835 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 836 Sections 4.1 and 4.3 of [10]. 838 6.1. User-Name AVP 840 The User-Name AVP (AVP Code 2) is of type UTF8String and contains an 841 NAI extracted from the MN-NAI mobility option included in the 842 received BU message. Alternatively, the NAI can be extracted from 843 the IKEv2 IDi payload included in the IKE_SA_INIT message. 845 6.2. MIP-MN-AAA-SPI AVP 847 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 848 contains an SPI code extracted from the Mobility Message 849 Authentication Option included in the received BU message. 851 This AVP is re-used from [12]. 853 6.3. MIP-MN-to-HA-SPI AVP 855 The MIP-MN-to-HA-SPI AVP (AVP Code TBD) is of type Unsigned32 and 856 contains an SPI code provided by the Diameter server for the Mobile 857 IPv6 MN-HA Authentication Option. 859 This AVP is re-used from [12] that introduces the AVP but erroneously 860 does not define the AVP Code. 862 6.4. MIP-Mobile-Node-Address AVP 864 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 865 contains the Home Agent assigned IPv6 Home Address of the Mobile 866 Node. 868 If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address 869 (0::0) in a request message, then the Home Agent expects the Diameter 870 server to assign the Home Address in a subsequent reply message. In 871 case the Diameter server assigns only a Home Network Prefix to the 872 Mobile Node the lower 64 bits of the MIP-Mobile-Node-Address AVP 873 provided address MUST be set to zero. 875 This AVP is re-used from [12]. 877 6.5. MIP-Home-Agent-Address AVP 879 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 880 contains the IPv6 address of the Home Agent. The Home Agent address 881 is the same as in the received BU message that triggered the 882 authentication and authorization procedure towards the Diameter 883 server. This AVP is re-used from [12]. 885 6.6. MIP-Careof-Address AVP 887 The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and 888 contains the IPv6 Care-of Address of the Mobile Node. The Home Agent 889 extracts this IP address from the received BU message. 891 6.7. MIP-Authenticator AVP 893 The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and 894 contains the Authenticator Data from the received BU message. The 895 Home Agent extracts this data from the MN-AAA Mobility Message 896 Authentication Option included in the received BU message. 898 6.8. MIP-MAC-Mobility-Data AVP 900 The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString 901 and contains the calculated MAC_Mobility_Data, as defined in [3]. 903 6.9. MIP-Session-Key AVP 905 The AVP (AVP Code 343) is of type OctetString and contains the MN-HA 906 shared secret (i.e., the session key) for the associated Mobile IPv6 907 MH-HA authentication option. When the Diameter server computes the 908 session key it is placed in this AVP. 910 This AVP is re-used from [12]. 912 6.10. MIP-MSA-Lifetime AVP 914 The AVP (AVP Code 367) is of type Unsigned32 and represents the 915 period of time (in seconds) for which the session key (see 916 Section 6.9) or nonce (see Section 6.14) is valid. The associated 917 session key or nonce MUST NOT be used if the lifetime has expired. 919 This AVP is re-used from [12]. 921 6.11. MIP-MN-to-HA-MSA AVP 923 The AVP (AVP Code 331) is of type Grouped and contains the session 924 related information for use with the MIPv6 Authentication Protocol. 926 MIP-MN-to-HA-MSA ::= < AVP Header: 331 > 927 { MIP-Session-Key } 928 [ MIP-MN-to-HA-SPI ] 929 [ MIP-Algorithm-Type ] 930 [ MIP-Replay-Mode ] 931 [ MIP-nonce ] 932 * [ AVP ] 934 This AVP is re-used from [12]. 936 6.12. MIP-Algorithm-Type AVP 938 The AVP (AVP Code 345) is of type Enumerated and contains Algorithm 939 identifier for the associated Mobile IPv6 MN-HA Authentication 940 Option. The Diameter server selects the algorithm type. Existing 941 algorithm types are defined in RFC 4004 that also fulfill current RFC 942 4285 requirements. This AVP is re-used from [12]. 944 6.13. MIP-Replay-Mode AVP 946 The AVP (AVP Code 346) is of type Enumerated and contains the replay 947 mode the Home Agent for authenticating the mobile node. The replay 948 modes, defined in RFC 4004 [12], are supported. This AVP is re-used 949 from [12]. 951 6.14. MIP-nonce AVP 953 The AVP (AVP Code 335) is of type OctetString and contains the nonce 954 sent to the Mobile Node. This AVP is re-used from [12]. 956 6.15. MIP6-Feature-Vector AVP 958 This AVP is defined in [11]. This document defines a new capability 959 bit for signaling the support of Mobile IPv6 route optimization. The 960 following capability is defined in this document: 962 RO_SUPPORTED (0x0000000800000000) 964 Route optimization is supported. When the Home Agent sets this 965 bit, it indicates support for the route optimization. If this bit 966 is unset in the returned Mobility-Capability AVP, the HAAA does 967 not authorize route optimization for the MN. 969 In a case the Home Agent or the HAAA cannot authorize the use of 970 route optimization then the Home Agent SHOULD send a Binding 971 Acknowledgement with a Status Code set to 972 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This Status 973 Code indicates that the binding registration succeeded but the 974 Home Agent will fail all possible subsequent route optimization 975 attempts because of subscription or operator policy. 977 6.16. MIP-Timestamp AVP 979 The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain 980 the timestamp value from the Mobility message replay protection 981 option, defined in [3]. The Home Agent extracts this value from the 982 received BU message, if available. 984 The support for replay protection is an optional feature in [3]. 985 When the Diameter server checks the timestamp provided by the MN via 986 the HA and recognizes a clock-drift (outside a locally defined replay 987 protection window) then it MUST initiate the re-synchronization 988 procedure by returning a MIP6-Answer-Message with Result-Code set to 989 MIP6-TIMESTAMP-MISMATCH and attaches the MIP-Timestamp AVP including 990 it's current time back to the HA. 992 6.17. QoS-Capability AVP 994 The QoS-Capability AVP is defined in [10] and contains a list of 995 supported Quality of Service profiles. 997 6.18. QoS-Resources AVP 999 The QoS-Resources AVP is defined in [10] and provides QoS and packet 1000 filtering capabilities. 1002 6.19. Accounting AVPs 1004 This document reuses the accounting AVPs defined in Diameter Mobile 1005 IPv4 application [12], namely: 1007 o Accounting-Input-Octets 1009 Number of octets in IP packets received from the mobile node. 1011 o Accounting-Output-Octets: 1013 Number of octets in IP packets sent by the mobile node. 1015 o Accounting-Input-Packets: 1017 Number of IP packets received from the mobile node. 1019 o Accounting-Output-Packets: 1021 Number of IP packets sent by the mobile node. 1023 Other APVs that SHOULD be included in the accounting request message 1024 include: 1026 o QoS-Resources: 1028 Assigned QoS resources for the mobile node. 1030 o QoS-Capability: 1032 The QoS capability related to the assigned QoS-Resources. 1034 o MIP-Mobile-Node-Address: 1036 The Home Address of the mobile node. 1038 o MIP-Careof-Address: 1040 The current Care-of Address of the mobile node. 1042 o MIP-Home-Agent-Address: 1044 The current home agent of the mobile node. 1046 7. Result-Code AVP Values 1048 This section defines new Result-Code [5] values that MUST be 1049 supported by all Diameter implementations that conform to this 1050 specification. 1052 7.1. Transient Failures 1054 Errors in the transient failures category are used to inform a peer 1055 that the request could not be satisfied at the time it was received, 1056 but that it may be able to satisfy the request in the future. 1058 MIP6-TIMESTAMP-MISMATCH (Status Code TBD) 1060 This error code is used by the home agent to indicate to the HA 1061 that the timestamp value provided as part of the MN-AAA option has 1062 an unacceptable clock-drift. 1064 7.2. Permanent Failures 1066 Errors that fall within the permanent failures category are used to 1067 inform the peer that the request failed and SHOULD NOT be attempted 1068 again. 1070 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION (Status Code TBD) 1072 This error is used by the Diameter server to inform the peer that 1073 the requested Mobile IPv6 session keys could not be delivered via 1074 a security association. 1076 8. AVP Occurrence Tables 1078 The following tables present the AVPs defined in this document and 1079 their occurrences in Diameter messages. Note that AVPs that can only 1080 be present within a Grouped AVP are not represented in this table. 1082 The table uses the following symbols: 1084 0: 1086 The AVP MUST NOT be present in the message. 1088 0+: 1090 Zero or more instances of the AVP MAY be present in the message. 1092 0-1: 1094 Zero or one instance of the AVP MAY be present in the message. 1096 1: 1098 One instance of the AVP MUST be present in the message. 1100 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table 1102 +-----------------------------------+ 1103 | Command-Code | 1104 |-----+-----+-----+-----+-----+-----+ 1105 AVP Name | AAR | AAA | DER | DEA | MRM | MAM | 1106 -------------------------------|-----+-----|-----+-----+-----+-----+ 1107 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1108 MIP-Mobile-Node-Address | 1 | 0-1 | 1 | 0-1 | 1 | 0-1 | 1109 MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1110 MIP-Home-Agent-Address | 0-1 | 0 | 0-1 | 0 | 1 | 0 | 1111 MIP-Careof-Address | 0 | 0 | 0 | 0 | 1 | 0 | 1112 MIP-Authenticator | 0 | 0 | 0 | 0 | 0-1 | 0 | 1113 MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 0-1 | 0 | 1114 MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 | 1115 MIP-MN-to-HA-MSA | 0 | 0 | 0 | 0 | 0 | 1 | 1116 MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1117 QoS-Resources | *0 | *0 | *0 | *0 | *0 | *0 | 1118 QoS-Capability | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1119 +-----+-----+-----+-----+-----+-----+ 1121 8.2. Accounting AVP Table 1123 The table in this section is used to represent which AVPs defined in 1124 this document are to be present in the Accounting messages, as 1125 defined in [5]. 1127 +-------------+ 1128 | Command-Code| 1129 |------+------+ 1130 Attribute Name | ACR | ACA | 1131 -------------------------------------|------+------+ 1132 Accounting-Input-Octets | 1 | 0-1 | 1133 Accounting-Input-Packets | 1 | 0-1 | 1134 Accounting-Output-Octets | 1 | 0-1 | 1135 Accounting-Output-Packets | 1 | 0-1 | 1136 Acct-Multi-Session-Id | 1 | 0-1 | 1137 Acct-Session-Time | 1 | 0-1 | 1138 MIP6-Feature-Vector | 1 | 0-1 | 1139 MIP-Home-Agent-Address | 1 | 0-1 | 1140 MIP-Mobile-Node-Address | 1 | 0-1 | 1141 Event-Timestamp | 0-1 | 0 | 1142 QoS-Capability | *0 | *0 | 1143 -------------------------------------|------+------+ 1145 9. IANA Considerations 1147 This section contains the namespaces that have either been created in 1148 this specification or had their values assigned to existing 1149 namespaces managed by IANA. 1151 9.1. Command Codes 1153 IANA is requested to allocate a command code value for the MIP6- 1154 Request-Message (MRM) and for the MIP6-Answer-Message (MAM) from the 1155 Command Code namespace defined in [5]. See Section 5 for the 1156 assignment of the namespace in this specification. 1158 9.2. AVP Codes 1160 This specification requires IANA to register the following new AVPs 1161 from the AVP Code namespace defined in [5]. 1163 o MIP-Careof-Address 1164 o MIP-Authenticator 1165 o MIP-MAC-Mobility-Data 1166 o MIP-Timestamp 1167 o MIP-MN-to-HA-SPI 1169 The AVPs are defined in Section 6. 1171 9.3. Result-Code AVP Values 1173 This specification requests IANA to allocate new values to the 1174 Result-Code AVP (AVP Code 268) namespace defined in [5]. See 1175 Section 7 for the assignment of the namespace in this specification. 1177 9.4. Application Identifier 1179 This specification requires IANA to allocate a new value for 1180 "Diameter Mobile IPv6" from the Application Identifier namespace 1181 defined in [5]. 1183 9.5. Namespaces 1185 This specification defines a new value to the Mobility Capability 1186 registry (see [11]) for use with the MIP6-Feature-Vector AVP: 1188 Token | Value | Description 1189 ---------------------------------+----------------------+------------ 1190 RO_SUPPORTED | 0x0000000800000000 | RFC TBD 1192 9.6. Mobile IPv6 Status Codes 1194 This specification defines a new Mobile IPv6 [1] Status Code value. 1195 The Status Code must be allocated from the range 0-127: 1197 Status Code | Value | Description 1198 ----------------------------------------+---------------+------------ 1199 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD 1201 10. Security Considerations 1203 The security considerations for the Diameter interaction required to 1204 accomplish the split scenario are described in in [2]. Additionally, 1205 the security considerations of the Diameter Base protocol [5], 1206 Diameter EAP application [7] are applicable to this document. This 1207 document does not introduce new security vulnerabilities. 1209 11. Acknowledgements 1211 The authors would like to thank Jari Arkko, Tolga Asversen, Pasi 1212 Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John 1213 Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay 1214 Devarapalli, Lionel Morand, Domagoj Premec and Yoshihiro Ohba for all 1215 the useful discussions. Ahmad Muhanna provided a detailed review of 1216 the document in August 2007. 1218 We would also like to thank our Area Director, Dan Romascanu, for his 1219 support. 1221 Hannes Tschofenig would like to thank the European Commission support 1222 in the co-funding of the ENABLE project, where this work is partly 1223 being developed. 1225 Julien Bournelle would like to thank GET/INT since he began this work 1226 while he was under their employ. 1228 12. References 1230 12.1. Normative References 1232 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1233 IPv6", RFC 3775, June 2004. 1235 [2] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1236 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1238 [3] Patel, A., "Authentication Protocol for Mobile IPv6", 1239 draft-ietf-mip6-rfc4285bis-01 (work in progress), October 2007. 1241 [4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1242 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1243 April 2007. 1245 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1246 "Diameter Base Protocol", RFC 3588, September 2003. 1248 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1249 Levels", BCP 14, RFC 2119, March 1997. 1251 [7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1252 Authentication Protocol (EAP) Application", RFC 4072, 1253 August 2005. 1255 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1256 RFC 4306, December 2005. 1258 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1259 Network Access Server Application", RFC 4005, August 2005. 1261 [10] Korhonen, J., Tschofenig, H., Arumaithurai, M., and M. Jones, 1262 "Quality of Service Attributes for Diameter", 1263 draft-ietf-dime-qos-attributes-03 (work in progress), 1264 November 2007. 1266 [11] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1267 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1268 Server to Diameter Server Interaction", 1269 draft-ietf-dime-mip6-integrated-06 (work in progress), 1270 November 2007. 1272 [12] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 1273 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1274 August 2005. 1276 12.2. Informative References 1278 [13] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1279 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1281 [14] Giaretta, G., "AAA Goals for Mobile IPv6", 1282 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1283 September 2006. 1285 [15] Fajardo, V., Asveren, T., Tschofenig, H., and G. McGregor, 1286 "Diameter Applications Design Guidelines", 1287 draft-ietf-dime-app-design-guide-05 (work in progress), 1288 November 2007. 1290 [16] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1291 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1292 RFC 4283, November 2005. 1294 Authors' Addresses 1296 Jouni Korhonen (editor) 1297 TeliaSonera 1298 Teollisuuskatu 13 1299 Sonera FIN-00051 1300 Finland 1302 Email: jouni.korhonen@teliasonera.com 1304 Hannes Tschofenig 1305 Nokia Siemens Networks 1306 Otto-Hahn-Ring 6 1307 Munich, Bavaria 81739 1308 Germany 1310 Email: Hannes.Tschofenig@nsn.com 1311 URI: http://www.tschofenig.com 1313 Julien Bournelle 1314 France Telecom R&D 1315 38-4O rue du general Leclerc 1316 Issy-Les-Moulineaux 92794 1317 France 1319 Email: julien.bournelle@orange-ftgroup.com 1321 Gerardo Giaretta 1322 Qualcomm 1323 5775 MoreHouse Dr 1324 San Diego, CA 92121 1325 USA 1327 Email: gerardo.giaretta@gmail.com 1329 Madjid Nakhjiri 1330 Motorola 1331 USA 1333 Email: madjid.nakhjiri@motorola.com 1335 Full Copyright Statement 1337 Copyright (C) The IETF Trust (2007). 1339 This document is subject to the rights, licenses and restrictions 1340 contained in BCP 78, and except as set forth therein, the authors 1341 retain all their rights. 1343 This document and the information contained herein are provided on an 1344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1346 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1347 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1348 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1351 Intellectual Property 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org. 1375 Acknowledgment 1377 Funding for the RFC Editor function is provided by the IETF 1378 Administrative Support Activity (IASA).