idnits 2.17.1 draft-ietf-dime-mip6-split-07.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 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1387. 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 (February 25, 2008) is 5876 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-02 ** 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 (-12) exists of draft-ietf-dime-mip6-integrated-08 == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-04 == Outdated reference: A later version (-01) exists of draft-ietf-mext-aaa-ha-goals-00 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-06 Summary: 6 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 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: August 28, 2008 J. Bournelle 7 Orange Labs 8 G. Giaretta 9 Qualcomm 10 M. Nakhjiri 11 Motorola 12 February 25, 2008 14 Diameter Mobile IPv6: Support for Home Agent to Diameter Server 15 Interaction 16 draft-ietf-dime-mip6-split-07.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 August 28, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 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 and 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 . . . . . . . . . . . . . 11 77 4.5.2. Session-Termination-Answer . . . . . . . . . . . . . . 11 78 4.5.3. Abort-Session-Request . . . . . . . . . . . . . . . . 11 79 4.5.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . 12 80 4.6. Accounting for Mobile IPv6 services . . . . . . . . . . . 12 81 4.6.1. Accounting-Request . . . . . . . . . . . . . . . . . . 12 82 4.6.2. Accounting-Answer . . . . . . . . . . . . . . . . . . 13 83 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP . . . . . 13 85 5.1.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . 13 86 5.1.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . 14 87 5.2. Command Code for Mobile IPv6 with IKEv2 and 88 Certificate- and PSK-based Authentication . . . . . . . . 15 89 5.2.1. AA-Request . . . . . . . . . . . . . . . . . . . . . . 15 90 5.2.2. AA-Answer . . . . . . . . . . . . . . . . . . . . . . 16 91 5.3. Command Codes for MIPv6 Authentication Protocol Support . 17 92 5.3.1. MIP6-Request-Message . . . . . . . . . . . . . . . . . 17 93 5.3.2. MIP6-Answer-Message . . . . . . . . . . . . . . . . . 18 94 6. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 6.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 22 96 6.2. Called-Station-Id AVP . . . . . . . . . . . . . . . . . . 22 97 6.3. MIP-MN-AAA-SPI AVP . . . . . . . . . . . . . . . . . . . . 22 98 6.4. MIP-MN-HA-SPI AVP . . . . . . . . . . . . . . . . . . . . 22 99 6.5. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . . 22 100 6.6. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . . . 23 101 6.7. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 23 102 6.8. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 23 103 6.9. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 23 104 6.10. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 23 105 6.11. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 23 106 6.12. MIP-MN-HA-MSA AVP . . . . . . . . . . . . . . . . . . . . 24 107 6.13. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 24 108 6.14. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 24 109 6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 24 110 6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 25 111 6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 25 112 6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 25 113 6.19. Coupled Accounting Model Accounting AVPs . . . . . . . . . 25 114 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 26 115 7.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 26 116 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 27 117 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table . . 27 118 8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 28 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 120 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 28 121 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 28 122 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 29 123 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 29 124 9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 29 125 9.6. Mobile IPv6 Status Codes . . . . . . . . . . . . . . . . . 29 126 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 127 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 129 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30 130 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 132 Intellectual Property and Copyright Statements . . . . . . . . . . 33 134 1. Introduction 136 Performing the Mobile IPv6 protocol [1], requires the Mobile Node 137 (MN) to own a Home Address (HoA) and to have an assigned Home Agent 138 (HA) to the MN. The MN needs to register with the HA in order enable 139 its reachability and mobility, when away from home. The registration 140 process itself requires establishment of IPSec security associations 141 (SA) and cryptographic material between the MN and HA. Providing the 142 collection of home address, HA address and keying material is 143 generally referred to as the Mobile IPv6 bootstrapping problem [13]. 144 The purpose of this specification is to provide Diameter support for 145 the interaction between the HA and the AAA server required to solve 146 the bootstrapping problem in the split scenario [2] in a manner that 147 satisfies the requirements defined in [14]. 149 From a mobility service provider (MSP) perspective, it is important 150 to verify that the MN is authenticated and authorized to utilize 151 Mobile IPv6 service and that such services are accounted for. Only 152 when the MN is authenticated and authorized, the MSP allows the 153 bootstrapping of Mobile IPv6 parameters. Thus, prior to processing 154 the Mobile IPv6 registrations, the HA, participates in the 155 authentication of the MN to verify the MN's identity. The HA also 156 participates in the Mobile IPv6 authorization process involving the 157 Diameter infrastructure. The HA, due to its role in traffic 158 forwarding, may also perform accounting for the Mobile IPv6 service 159 provided to the MN. 161 This document enables the following functionality: 163 Authentication: Asserting or helping with assertion of the 164 correctness of the MN identity. As a Diameter client supporting 165 the new Diameter Mobile IPv6 application, the HA may need to 166 support more than one authentication type depending on the 167 environment. Although the authentication is performed by the AAA 168 server there is an impact for the HA as different set of command 169 codes are needed for the respective authentication procedures. 171 Authorization: The HA must verify that the user is authorized to use 172 the Mobile IPv6 service using the assistance of the MSP Diameter 173 servers. This is accomplished through the use of new Diameter 174 commands specifically designed for performing Mobile IPv6 175 authorization decisions. This document defines these commands and 176 requires the HA to support them and to participate in this 177 authorization signaling. 179 Accounting: For accounting purposes and capacity planning, it is 180 required of the HA to provide accounting report to the Diameter 181 infrastructure and thus to support the related Diameter accounting 182 procedures. 184 Figure 1 depicts the reference architecture for this document. 186 +--------+ 187 |Diameter| 188 |Server | 189 +--------+ 190 ^ 191 Back-End | Diameter MIPv6 192 Protocol | HA<->AAA Server 193 Support | Interaction 194 | (this document) 195 v 196 +---------+ +---------------+ 197 | Mobile | Front-End Protocol |Home Agent / | 198 | Node |<--------------------------|Diameter Client| 199 +---------+ IKEv2 or RFC 4285 +---------------+ 201 Figure 1: Architecture Overview 203 Mobile IPv6 signaling between the MN and the HA can protected using 204 two different mechanisms, namely using IPSec and via the MIPv6 205 Authentication Protocol [3]. The important aspect is, however, that 206 for these two approaches several different authentication and key 207 exchange solutions are available. To establish IPSec security 208 associations, protecting of Mobile IPv6 signaling messages IKEv2 is 209 used [4]. IKEv2 supports EAP-based authentication, certificates and 210 pre-shared secrets. For protecting using the MIPv6 Authentication 211 Protocol [3] a mechanism has been designed that is very similar to 212 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: 219 o IKEv2 usage with EAP 220 o IKEv2 usage with certificates and pre-shared secrets 221 o MIPv6 Authentication Protocol 223 For accounting of Mobile IPv6 services provided to the MN, this 224 specification uses the accounting application defined in [5]. 226 2. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119 [6]. 232 The MIPv6 bootstrapping terminology is taken from [13]. 234 3. Advertising Application Support 236 Diameter nodes conforming to this specification MUST advertise 237 support by including the Diameter Mobile IPv6 Application ID value of 238 [TO BE ASSIGNED BY IANA] in the Auth-Application-Id AVP of the 239 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 240 command [5]. The Acct-Application-id AVP needs to include the 241 Diameter Base Accounting Application ID value of 3 (to support the 242 split accounting model [15]). 244 4. Protocol Description 246 4.1. Support for Mobile IPv6 with IKEv2 and EAP 248 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 249 authenticate the MN. When EAP is used with IKEv2, the Diameter EAP 250 application, as defined in [7], is re-used. EAP methods that do not 251 establish a shared key SHOULD NOT be used, as they are subject to a 252 number of man-in-the-middle attacks as stated in Section 2.16 and 253 Section 5 of RFC 4306 [8]. AVPs specific to Mobile IPv6 254 bootstrapping are added to the EAP application commands. 256 Figure 2 shows the message flow involved during the authentication 257 phase when EAP is used. 259 Mobile Home Diameter 260 Node Agent Server 261 | | | 262 | HDR, SAi1, KEi, Ni (1) | | 263 |-------------------------------->| | 264 | | | 265 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 266 |<--------------------------------| | 267 | | | 268 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 269 | [CP(CFG_REQUEST),] | | 270 | SAi2, TSi, TSr} (3) | | 271 |-------------------------------->| DER (EAP-Response) (4) | 272 | |------------------------->| 273 | | | 274 | | DEA (EAP-Request) (5) | 275 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------| 276 |<------------------------------- | | 277 | | | 278 | HDR, SK{EAP} | | 279 |-------------------------------->| DER (EAP-Response) | 280 | |------------------------->| 281 | | | 282 | | DEA (EAP-Request) | 283 | HDR, SK{EAP-Request} |<-------------------------| 284 |<--------------------------------| | 285 | | | 286 | HDR, SK{EAP-Response} | | 287 |-------------------------------->| DER (EAP-Response) | 288 | |------------------------->| 289 | ... | ... | 290 | | | 291 | | DEA (EAP-Success) | 292 | |<-------------------------| 293 | HDR, SK{EAP-Success} | | 294 |<--------------------------------| | 295 | | | 296 | HDR, SK{AUTH} | | 297 |-------------------------------->| | 298 | | | 299 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 300 | SAr2, TSi, TSr} | | 301 |<--------------------------------| | 302 | | | 304 Figure 2: Mobile IPv6 bootstrapping using IKEv2 and EAP 306 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 308 In this phase cryptographic algorithms are negotiated, nonces and 309 Diffie-Hellman parameters are exchanged. Message (3) starts the 310 IKE_AUTH phase. This second phase authenticates the previous 311 messages, exchanges identities and certificates and establishes the 312 first CHILD_SA. It is used to mutually authenticate the MN (acting 313 as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). 314 The identity of the user/MN is provided in the IDi field. The MN 315 indicates its willingness to be authenticated via EAP by omitting the 316 AUTH field in message (3) (see Section 2.16 of [8]). 318 As part of the authentication process, the MN MAY request a Home- 319 Address, a Home Prefix or suggests one, see [4], using a CFG_REQUEST 320 payload in the message (3). 322 The HA extracts the IDi field from the message (3) and sends a 323 Diameter-EAP-Request (DER) message (4) towards the authenticating 324 Diameter server. The EAP-Payload AVP contains a EAP-Response/ 325 Identity with the identity extracted from the IDi field. 327 This message is routed to the MNs Diameter server/EAP server. The 328 Diameter server selects the EAP method and replies with the DEA 329 Message. Depending on the type of EAP method chosen, a number of DER 330 and DEA messages carry the method specific exchanges between the MN 331 and the Diameter server/EAP server. 333 At the end of the EAP authentication phase, the Diameter server 334 indicates the result of the authentication in the Result-Code AVP and 335 provides the corresponding EAP packet (EAP Success or EAP Failure). 336 The last IKEv2 message sent by the HA contains the Home Address or 337 the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 338 necessary to setup IPSec SAs for Mobile IPv6 signaling. 340 In some deployment scenario, the HA may also acts as a IKEv2 341 Responder for IPSec VPN access. A problem in this case is that the 342 IKEv2 responder may not know if IKEv2 is used for MIP6 service or for 343 IPSec VPN access. The IKEv2 responder may A network operator needs 344 to be aware of this limitation. 346 Eventually, when the HA receives a Binding Update (BU), the HA 347 authenticates and authorizes the MN. It is RECOMMENDED that the HA 348 sends an accounting request message every time it receives a BU. 350 4.2. Support for Mobile IPv6 with IKEv2 and Certificates 352 When IKEv2 is used with certificate-based authentication, the 353 Diameter NASREQ application [9] is used to authorize the MN for the 354 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 355 message MUST correspond to the identity in the MN's certificate. 357 This identity is then used by the Home Agent to populate the User- 358 Name AVP in the succeeding AA-Request message. Further PKI-related 359 procedures such as certificate revocation checking are out of scope 360 of this document. 362 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets 364 When IKEv2 is used with PSK-based initiator authentication, the 365 Diameter NASREQ application [9] is re-used to authorize the MN for 366 the Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 367 message has to contain an identity that is meaningful for the 368 Diameter infrastructure, such as a Network Access Identifier (NAI), 369 and is then used by the Home Agent to populate the User-Name AVP in 370 the succeeding AA-Request message. 372 4.4. Support for the Mobile IPv6 Authentication Protocol 374 Figure 3 shows the message sequence between the MN, the HA and the 375 Diameter server during the registration when MIPv6 Authentication 376 Protocol is used. BU and Binding Acknowledgement (BA) messages are 377 used in the binding registration process. This exchange triggers the 378 Diameter interaction. 380 According to [3] the MN uses the Mobile Node Identifier Option, 381 specifically the MN-NAI mobility option (as defined in [16]) to 382 identify itself. 384 Receiving the BU at the HA initiates a MIP6-Request-Message to the 385 Diameter server, which in turn responds with a MIP6-Answer-Message. 386 The Home Agent also provides the assigned Home Address to the 387 Diameter server in the MIP-Mobile-Node-Address AVP. 389 The procedure described here for the Mobile IPv6 Authentication 390 Protocol is only needed for the initial BU received by the HA. When 391 the HA receives subsequent BUs, they are processed locally in the HA. 392 It is RECOMMENDED that the HA sends an accounting request message 393 every time it receives a Binding Update. 395 Mobile Home Diameter 396 Node Agent Server 397 | | | 398 | | | 399 | Binding Update |MIP6-Request-Message | 400 |------------------------------------>|-------------------->| 401 | (Mobile Node Identifier Option, | | 402 | Mobility Message Replay Protection | | 403 | Option, Authentication Option) | | 404 | | | 405 | | | 406 | Binding Acknowledgement |MIP6-Answer-Message | 407 |<------------------------------------|<--------------------| 408 | (Mobile Node Identifier Option | | 409 | Mobility Message Replay Protection | | 410 | Option, Authentication Option) | | 412 Figure 3: MIPv6 Bootstrapping using the MIPv6 Authentication Protocol 414 4.5. Mobile IPv6 Session Management 416 The Diameter server may maintain state or may be stateless. This is 417 indicated in the Auth-Session-State AVP (or its absence). The HA 418 MUST support the Authorization Session State Machine defined in [5]. 419 Moreover, the following four commands may be exchanged between the HA 420 and the Diameter server. 422 4.5.1. Session-Termination-Request 424 The Session-Termination-Request (STR) message [5] is sent by the HA 425 to inform the Diameter server that an authorized session is being 426 terminated. 428 4.5.2. Session-Termination-Answer 430 The Session-Termination-Answer (STA) message [5] is sent by the 431 Diameter server to acknowledge the notification that the session has 432 been terminated. 434 4.5.3. Abort-Session-Request 436 The Abort-Session-Request (ASR) message [5] is sent by the Diameter 437 server to terminate the session. This fulfills one of the 438 requirement described in [14]. 440 4.5.4. Abort-Session-Answer 442 The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent 443 in response to an ASR message. 445 4.6. Accounting for Mobile IPv6 services 447 The HA MUST be able act as a Diameter client collecting accounting 448 records needed for service control and charging. The HA MUST support 449 the accounting procedures (specifically the command codes mentioned 450 below) and the Accounting Session State Machine as defined in [5]. 451 The command codes, exchanged between the HA and Diameter server for 452 accounting purposes, are provided in the following subsections. 454 The Diameter application design guideline [15] defines two separate 455 models for accounting: 457 Split accounting model: 459 According to this model, the accounting messages use the Diameter 460 base accounting application ID (value of 3). Since accounting is 461 treated as an independent application, accounting commands may be 462 routed separately from the rest of application messages and thus 463 the accounting messages generally end up in a central accounting 464 server. Since Diameter Mobile IPv6 application does not define 465 its own unique accounting commands, this is the preferred choice, 466 since it permits use of centralized accounting for several 467 applications. 469 Coupled accounting model: 471 In this model, the accounting messages will use the application ID 472 of the Mobile IPv6 application. This means that accounting 473 messages will be routed like any other Mobile IPv6 application 474 messages. This requires the Diameter server in charge of Mobile 475 IPv6 application to handle the accounting records (e.g., sends 476 them to a proper accounting server). 478 As mentioned above, the preferred choice is to use the split 479 accounting model and thus to choose Diameter base accounting 480 application ID (value of 3) for accounting messages. 482 4.6.1. Accounting-Request 484 The Accounting-Request command [5] is sent by the HA to the Diameter 485 server to exchange accounting information regarding the MN with the 486 Diameter server. 488 4.6.2. Accounting-Answer 490 The Accounting-Answer command [5] is sent by the Diameter server to 491 the HA to acknowledge receiving an Accounting-Request. 493 5. Command Codes 495 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP 497 For usage of Mobile IPv6 with IKEv2 and EAP this document re-uses the 498 Diameter EAP application [7] commands. The following commands are 499 used to carry MIPv6 related bootstrapping AVPs. 501 Command-Name Abbrev. Code Reference Application 502 ----------------------------------------------------------------------- 503 Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 (TBD) 504 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 (TBD) 506 Figure 4: Command Codes 508 5.1.1. Diameter-EAP-Request 510 The Diameter-EAP-Request (DER) message [7], indicated by the Command- 511 Code field set to 268 and the 'R' bit set in the Command Flags field, 512 is sent by the HA to the Diameter server to initiate a Mobile IPv6 513 service authentication and authorization procedure. The DER message 514 format is the same as defined in [7]. The Application-ID field of 515 the Diameter Header MUST be set to the Diameter Mobile IPv6 516 Application ID [TO BE ASSIGNED TO IANA]. 518 ::= < Diameter Header: 268, REQ, PXY > 519 < Session-Id > 520 { Auth-Application-Id } 521 { Origin-Host } 522 { Origin-Realm } 523 { Destination-Realm } 524 { Auth-Request-Type } 525 [ Destination-Host ] 526 [ NAS-Identifier ] 527 [ NAS-IP-Address ] 528 [ NAS-IPv6-Address ] 529 [ NAS-Port-Type ] 530 [ User-Name ] 531 ... 532 [ Called-Station-Id] 533 ... 534 { EAP-Payload } 535 ... 536 [ MIP6-Feature-Vector ] 537 { MIP-Home-Agent-Address } 538 { MIP-Mobile-Node-Address } 540 [ QoS-Capability ] 541 * [ QoS-Resources ] 542 ... 543 * [ AVP ] 545 5.1.2. Diameter-EAP-Answer 547 The Diameter-EAP-Answer (DEA) message defined in [7], indicated by 548 the Command-Code field set to 268 and 'R' bit cleared in the Command 549 Flags field, is sent in response to the Diameter-EAP-Request message 550 (DER). If the Mobile IPv6 authentication procedure was successful 551 then the response MAY include any set of bootstrapping AVPs. 553 The DEA message format is the same as defined in [7]. The 554 Application-Id field in the Diameter header MUST be set to the 555 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 557 ::= < Diameter Header: 268, PXY > 558 < Session-Id > 559 { Auth-Application-Id } 560 { Auth-Request-Type } 561 { Result-Code } 562 { Origin-Host } 563 { Origin-Realm } 564 [ User-Name ] 565 [ EAP-Payload ] 566 ... 568 [ MIP-Mobile-Node-Address ] 569 [ MIP6-Feature-Vector ] 570 * [ QoS-Resources ] 571 ... 572 * [ AVP ] 574 5.2. Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK- 575 based Authentication 577 This document re-uses the Diameter NASREQ application commands. The 578 following commands are used to carry MIPv6 related bootstrapping 579 AVPs. 581 Command-Name Abbrev. Code Reference Application 582 ----------------------------------------------------------------------- 583 AA-Request AAR 265 RFC 4005 Diameter Mobile IPv6 (TBD) 584 AA-Answer AAA 265 RFC 4005 Diameter Mobile IPv6 (TBD) 586 Figure 7: Command Codes 588 5.2.1. AA-Request 590 The AA-Request (AAR) message [9], indicated by the Command-Code field 591 set to 265 and the 'R' bit set in the Command Flags field, is sent by 592 the HA to the Diameter server to initiate a Mobile IPv6 service 593 authentication and authorization procedure. The AAR message format 594 is the same as defined in [9]. The Application-ID field of the 595 Diameter Header MUST be set to the Diameter Mobile IPv6 Application 596 ID [TO BE ASSIGNED TO IANA]. 598 ::= < Diameter Header: 265, REQ, PXY > 599 < Session-Id > 600 { Auth-Application-Id } 601 { Origin-Host } 602 { Origin-Realm } 603 { Destination-Realm } 604 { Auth-Request-Type } 605 [ Destination-Host ] 606 [ NAS-Identifier ] 607 [ NAS-IP-Address ] 608 [ NAS-IPv6-Address ] 609 [ NAS-Port-Type ] 610 [ User-Name ] 611 ... 612 [ Called-Station-Id] 613 ... 614 [ MIP6-Feature-Vector ] 615 { MIP-Home-Agent-Address } 616 { MIP-Mobile-Node-Address } 617 ... 618 [ QoS-Capability ] 619 * [ QoS-Resources ] 620 ... 621 * [ AVP ] 623 5.2.2. AA-Answer 625 The AA-Answer (AAA) message defined in [9], indicated by the Command- 626 Code field set to 265 and 'R' bit cleared in the Command Flags field, 627 is sent in response to the AA-Request message (AAR). If the Mobile 628 IPv6 authentication procedure was successful then the response MAY 629 include any set of bootstrapping AVPs. 631 The AAA message format is the same as defined in [9]. The 632 Application-Id field in the Diameter header MUST be set to the 633 Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA]. 635 ::= < Diameter Header: 265, PXY > 636 < Session-Id > 637 { Auth-Application-Id } 638 { Auth-Request-Type } 639 { Result-Code } 640 { Origin-Host } 641 { Origin-Realm } 642 [ User-Name ] 643 [ Authorization-Lifetime ] 644 ... 646 [ MIP-Mobile-Node-Address ] 647 [ MIP6-Feature-Vector ] 648 [ MIP-MN-HA-MSA ] 649 * [ QoS-Resources ] 650 ... 651 * [ AVP ] 653 When IKEv2 is used with PSK-based initiator authentication, the pre- 654 shared secret is carried inside the MIP-MN-HA-MSA AVP. The pre- 655 shared secret SHOULD NOT be user's long term secret and it is 656 RECOMMENDED that a short-term keying material specifically created 657 for this purpose is used instead. 659 5.3. Command Codes for MIPv6 Authentication Protocol Support 661 This section defines the commands that are used for support with the 662 MIPv6 Authentication Protocol. 664 Command-Name Abbrev. Code Reference Application 665 ---------------------------------------------------------------------- 666 MIP6-Request-Message MRM TBD 5.3.1 Diameter Mobile IPv6 (TBD) 667 MIP6-Answer-Message MAM TBD 5.3.2 Diameter Mobile IPv6 (TBD) 669 Command Codes 671 5.3.1. MIP6-Request-Message 673 The MIP6-Request-Message (MRM), indicated by the Command-Code field 674 set to TBD and the 'R' bit set in the Command Flags field, is sent by 675 the HA, acting as a Diameter client, in order to request the 676 authentication and authorization of a MN. 678 Although the HA provides the Diameter server with a replay protection 679 related information, the HA is responsible for the replay protection. 681 The message format is shown below. 683 ::= < Diameter Header: XXX, REQ, PXY > 684 < Session-ID > 685 { Auth-Application-Id } 686 { User-Name } 687 { Destination-Realm } 688 { Origin-Host } 689 { Origin-Realm } 690 [ Acct-Multi-Session-Id ] 691 [ Destination-Host ] 692 [ Origin-State-Id ] 693 [ NAS-Identifier ] 694 [ NAS-IP-Address ] 695 [ NAS-IPv6-Address ] 696 [ NAS-Port-Type ] 698 [ MIP6-Feature-Vector ] 699 [ MIP-MN-AAA-SPI ] 700 { MIP-Mobile-Node-Address } 701 { MIP-Home-Agent-Address } 702 [ MIP-Careof-Address ] 703 [ MIP-Authenticator ] 704 [ MIP-MAC-Mobility-Data ] 705 [ MIP-Timestamp ] 706 [ QoS-Capability ] 707 * [ QoS-Resources ] 709 [ Authorization-Lifetime ] 710 [ Auth-Session-State ] 711 * [ Proxy-Info ] 712 * [ Route-Record ] 713 * [ AVP ] 715 5.3.2. MIP6-Answer-Message 717 The MIP6-Answer-Message (MAM) message, indicated by the Command-Code 718 field set to TBD and the 'R' bit cleared in the Command Flags field, 719 is sent by the Diameter server in response to the MIP6-Request- 720 Message message. The User-Name MAY be included in the MAM if it is 721 present in the MRM. The Result-Code AVP MAY contain one of the 722 values defined in Section 7, in addition to the values defined in RFC 723 3588 [5]. 725 An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 726 include the MIP-Mobile-Node-Address AVP. 728 The message format is shown below. 730 ::= < Diameter Header: XXX, PXY > 731 < Session-Id > 732 { Auth-Application-Id } 733 { Result-Code } 734 { Origin-Host } 735 { Origin-Realm } 736 [ Acct-Multi-Session-Id ] 737 [ User-Name ] 738 [ Authorization-Lifetime ] 739 [ Auth-Session-State ] 740 [ Error-Message ] 741 [ Error-Reporting-Host ] 742 [ Re-Auth-Request-Type ] 744 [ MIP6-Feature-Vector ] 745 [ MIP-Home-Agent-Address ] 746 [ MIP-Mobile-Node-Address ] 747 [ MIP-MN-HA-MSA ] 748 * [ QoS-Resources ] 750 [ Origin-State-Id ] 751 * [ Proxy-Info ] 752 * [ AVP ] 754 6. AVPs 756 To provide support for RFC 4285 [3] and for RFC 4877 [4] the AVPs in 757 the following subsections are needed. RFC 3588, RFC 4004 and RFC 758 4005 defined AVPs are reused whenever possible without changing the 759 existing semantics of those AVPs. 761 +--------------------------+ 762 | AVP Flag rules | 763 +----+-----+----+-----+----+ 764 AVP Defined | | |SHLD| MUST|MAY | 765 Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr| 766 +-----------------------------------------+----+-----+----+-----+----+ 767 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 768 | Vector | | | | | | 769 +-----------------------------------------+----+-----+----+-----+----+ 770 |MIP-Mobile- | M | P | | V | Y | 771 | Node-Address 334 RFC4004 Address | | | | | | 772 +-----------------------------------------+----+-----+----+-----+----+ 773 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 774 | Agent-Address | | | | | | 775 +-----------------------------------------+----+-----+----+-----+----+ 776 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 777 +-----------------------------------------+----+-----+----+-----+----+ 778 |Called- 30 RFC4005 UTF8String | M | P | | V | Y | 779 | Station-Id | | | | | | 780 +-----------------------------------------+----+-----+----+-----+----+ 781 |QoS-Capability TBD Note 2 Grouped | | P | | M,V | Y | 782 +-----------------------------------------+----+-----+----+-----+----+ 783 |QoS-Resources TBD Note 2 Grouped | | P | | M,V | Y | 784 +-----------------------------------------+----+-----+----+-----+----+ 785 |MIP-MN-HA-MSA TBD 6.12. Grouped | M | P | | V | Y | 786 +-----------------------------------------+----+-----+----+-----+----+ 788 AVPs for Mobile IPv6 with IKEv2 790 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 792 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 793 Sections 4.1 and 4.3 of [11]. 795 +--------------------------+ 796 | AVP Flag rules | 797 +----+-----+----+-----+----+ 798 AVP Section | | |SHLD| MUST|MAY | 799 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 800 +-----------------------------------------+----+-----+----+-----+----+ 801 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 802 | Vector | | | | | | 803 +-----------------------------------------+----+-----+----+-----+----+ 804 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 805 +-----------------------------------------+----+-----+----+-----+----+ 806 |MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | M | P | | V | Y | 807 +-----------------------------------------+----+-----+----+-----+----+ 808 |MIP-MN-HA-SPI TBD 6.4 Unsigned32 | M | P | | V | Y | 809 +-----------------------------------------+----+-----+----+-----+----+ 810 |MIP-Mobile- 333 RFC4004 Address | M | P | | V | Y | 811 | Node-Address | | | | | | 812 +-----------------------------------------+----+-----+----+-----+----+ 813 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 814 | Agent-Address | | | | | | 815 +-----------------------------------------+----+-----+----+-----+----+ 816 |MIP-Careof- TBD 6.7 Address | M | P | | V | Y | 817 | Address | | | | | | 818 +-----------------------------------------+----+-----+----+-----+----+ 819 |MIP- TBD 6.8 OctetString| M | P | | V | Y | 820 | Authenticator | | | | | | 821 +-----------------------------------------+----+-----+----+-----+----+ 822 |MIP-MAC- TBD 6.9 OctetString| M | P | | V | Y | 823 | Mobility-Data | | | | | | 824 +-----------------------------------------+----+-----+----+-----+----+ 825 |MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y | 826 +-----------------------------------------+----+-----+----+-----+----+ 827 |MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y | 828 | Lifetime | | | | | | 829 +-----------------------------------------+----+-----+----+-----+----+ 830 |MIP-MN-HA-MSA TBD 6.12 Grouped | M | P | | V | Y | 831 +-----------------------------------------+----+-----+----+-----+----+ 832 |MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y | 833 | Type | | | | | | 834 +-----------------------------------------+----+-----+----+-----+----+ 835 |MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y | 836 +-----------------------------------------+----+-----+----+-----+----+ 837 |MIP-Timestamp TBD 6.16 Time | M | P | | V | Y | 838 +-----------------------------------------+----+-----+----+-----+----+ 839 |QoS-Capability TBD Note 2 Grouped | | P | | M,V | Y | 840 +-----------------------------------------+----+-----+----+-----+----+ 841 |QoS-Resources TBD Note 2 Grouped | | P | | M,V | Y | 842 +-----------------------------------------+----+-----+----+-----+----+ 843 AVPs for the Mobile IPv6 Authentication Protocol 845 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 847 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 848 Sections 4.1 and 4.3 of [11]. 850 6.1. User-Name AVP 852 The User-Name AVP (AVP Code 1) is of type UTF8String and contains an 853 NAI extracted from the MN-NAI mobility option included in the 854 received BU message. Alternatively, the NAI can be extracted from 855 the IKEv2 IDi payload included in the IKE_AUTH message sent by the 856 IKE initiator. 858 6.2. Called-Station-Id AVP 860 The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and 861 contains the string extracted from the IKEv2 IDr payload, if 862 available in the IKE_AUTH message sent by the IKE initiator. 864 6.3. MIP-MN-AAA-SPI AVP 866 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 867 contains an SPI code extracted from the Mobility Message 868 Authentication Option included in the received BU message. 870 This AVP is re-used from [12]. 872 6.4. MIP-MN-HA-SPI AVP 874 The MIP-MN-HA-SPI AVP (AVP Code TBD) is of type Unsigned32 and 875 contains an SPI code provided by the Diameter server for the Mobile 876 IPv6 MN-HA Authentication Option. 878 6.5. MIP-Mobile-Node-Address AVP 880 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 881 contains the Home Agent assigned IPv6 Home Address of the Mobile 882 Node. 884 If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address 885 (0::0) in a request message, then the Home Agent expects the Diameter 886 server to assign the Home Address in a subsequent reply message. In 887 case the Diameter server assigns only a Home Network Prefix to the 888 Mobile Node the lower 64 bits of the MIP-Mobile-Node-Address AVP 889 provided address MUST be set to zero. 891 This AVP is re-used from [12]. 893 6.6. MIP-Home-Agent-Address AVP 895 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 896 contains the IPv6 address of the Home Agent. The Home Agent address 897 is the same as in the received BU message that triggered the 898 authentication and authorization procedure towards the Diameter 899 server. This AVP is re-used from [12]. 901 6.7. MIP-Careof-Address AVP 903 The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and 904 contains the IPv6 Care-of Address of the Mobile Node. The Home Agent 905 extracts this IP address from the received BU message. 907 6.8. MIP-Authenticator AVP 909 The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and 910 contains the Authenticator Data from the received BU message. The 911 Home Agent extracts this data from the MN-AAA Mobility Message 912 Authentication Option included in the received BU message. 914 6.9. MIP-MAC-Mobility-Data AVP 916 The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString 917 and contains the calculated MAC_Mobility_Data, as defined in [3]. 919 6.10. MIP-Session-Key AVP 921 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 922 contains the MN-HA shared secret (i.e., the session key) for the 923 associated Mobile IPv6 MH-HA authentication option. When the 924 Diameter server computes the session key it is placed in this AVP. 926 The MIP-Session-Key AVP may also be used to convey a pre-shared 927 secret when IKEv2 is used with PSK-based initiator authentication. 929 This AVP is re-used from [12]. 931 6.11. MIP-MSA-Lifetime AVP 933 The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 934 represents the period of time (in seconds) for which the session key 935 (see Section 6.10) is valid. The associated session key MUST NOT be 936 used if the lifetime has expired. 938 This AVP is re-used from [12]. 940 6.12. MIP-MN-HA-MSA AVP 942 The MIP-MN-HA-MSA AVP (AVP Code TBD) is of type Grouped and contains 943 the session related information for use with the MIPv6 Authentication 944 Protocol. 946 MIP-MN-HA-MSA ::= < AVP Header: TBD > 947 { MIP-Session-Key } 948 { MIP-MSA-Lifetime } 949 [ MIP-MN-HA-SPI ] 950 [ MIP-Algorithm-Type ] 951 [ MIP-Replay-Mode ] 952 * [ AVP ] 954 6.13. MIP-Algorithm-Type AVP 956 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and 957 contains Algorithm identifier for the associated Mobile IPv6 MN-HA 958 Authentication Option. The Diameter server selects the algorithm 959 type. Existing algorithm types are defined in RFC 4004 that also 960 fulfill current RFC 4285 requirements. 962 This AVP is re-used from [12]. 964 6.14. MIP-Replay-Mode AVP 966 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 967 contains the replay mode the Home Agent for authenticating the mobile 968 node. The replay modes, defined in RFC 4004 [12], are supported. 970 This AVP is re-used from [12]. 972 6.15. MIP6-Feature-Vector AVP 974 This AVP is defined in [10]. This document defines a new capability 975 bit for signaling the support of Mobile IPv6 route optimization. The 976 following capability is defined in this document: 978 RO_SUPPORTED (0x0000000800000000) 980 Route optimization is supported. When the Home Agent sets this 981 bit, it indicates support for the route optimization. If this bit 982 is unset in the returned Mobility-Capability AVP, the AAAH does 983 not authorize route optimization for the MN. 985 In a case the Home Agent or the AAAH cannot authorize the use of 986 route optimization then the Home Agent SHOULD send a Binding 987 Acknowledgement with a Status Code set to 988 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This Status 989 Code indicates that the binding registration succeeded but the 990 Home Agent will fail all possible subsequent route optimization 991 attempts because of subscription or operator policy. 993 USER_TRAFFIC_ENCRYPTION (0x0000000100000000) 995 User plane traffic encryption is supported. When the Home Agent 996 sets this bit, it indicates support for the user plane traffic 997 encryption between the MN and the Home Agent. If this bit is 998 unset in the returned Mobility-Capability AVP, the AAAH does not 999 authorize user plane traffic encryption for the MN because of 1000 subscription or operator policy. 1002 In the case the AAAH cannot authorize the use of route 1003 optimization then the Home Agent SHOULD send a Binding 1004 Acknowledgement with a Status Code set to 1005 ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION (status code TBD). This Status 1006 Code indicates that the binding registration succeeded but the 1007 Home Agent will silently discard all encrypted user plane packets 1008 sent by the MN to the Home Agent. 1010 6.16. MIP-Timestamp AVP 1012 The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain 1013 the timestamp value from the Mobility message replay protection 1014 option, defined in [3]. The Home Agent extracts this value from the 1015 received BU message, if available. 1017 6.17. QoS-Capability AVP 1019 The QoS-Capability AVP is defined in [11] and contains a list of 1020 supported Quality of Service profiles. 1022 6.18. QoS-Resources AVP 1024 The QoS-Resources AVP is defined in [11] and provides QoS and packet 1025 filtering capabilities. 1027 6.19. Coupled Accounting Model Accounting AVPs 1029 Diameter Mobile IPv6 application is used in the case of the coupled 1030 account model. Diameter Mobile IPv4 application [12] accounting AVPs 1031 are reused in this document. The following AVPs MUST be included in 1032 the accounting request message: 1034 o Accounting-Input-Octets: Number of octets in IP packets received 1035 from the mobile node. 1036 o Accounting-Output-Octets: Number of octets in IP packets sent by 1037 the mobile node 1038 o Accounting-Input-Packets: Number of IP packets received from the 1039 mobile node. 1040 o Accounting-Output-Packets: Number of IP packets sent by the mobile 1041 node. 1042 o Acct-Multi-Session-Id: Used to link together multiple related 1043 accounting sessions, where each session would have a unique 1044 Session-Id, but the same Acct-Multi-Session-Id AVP. 1045 o Acct-Session-Time: Indicates the length of the current session in 1046 seconds. 1047 o MIP6-Feature-Vector: The supported features for this mobility 1048 service session. 1049 o MIP-Mobile-Node-Address: The Home Address of the mobile node. 1050 o MIP-Home-Agent-Address: The current home agent of the mobile node. 1052 Other APVs that SHOULD be included in the accounting request message 1053 include: 1055 o QoS-Resources: Assigned QoS resources for the mobile node. 1056 o QoS-Capability: The QoS capability related to the assigned QoS- 1057 Resources. 1058 o MIP-Careof-Address: The current Care-of Address of the mobile 1059 node. 1061 7. Result-Code AVP Values 1063 This section defines new Result-Code [5] values that MUST be 1064 supported by all Diameter implementations that conform to this 1065 specification. 1067 7.1. Permanent Failures 1069 Errors that fall within the permanent failures category are used to 1070 inform the peer that the request failed and SHOULD NOT be attempted 1071 again. 1073 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION (Status Code TBD) 1075 This error is used by the Diameter server to inform the peer that 1076 the requested Mobile IPv6 session keys could not be delivered via 1077 a security association. 1079 8. AVP Occurrence Tables 1081 The following tables present the AVPs defined in this document and 1082 their occurrences in Diameter messages. Note that AVPs that can only 1083 be present within a Grouped AVP are not represented in this table. 1085 The table uses the following symbols: 1087 0: 1089 The AVP MUST NOT be present in the message. 1091 0+: 1093 Zero or more instances of the AVP MAY be present in the message. 1095 0-1: 1097 Zero or one instance of the AVP MAY be present in the message. 1099 1: 1101 One instance of the AVP MUST be present in the message. 1103 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table 1105 +-----------------------------------+ 1106 | Command-Code | 1107 |-----+-----+-----+-----+-----+-----+ 1108 AVP Name | AAR | AAA | DER | DEA | MRM | MAM | 1109 -------------------------------|-----+-----|-----+-----+-----+-----+ 1110 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1111 MIP-Mobile-Node-Address | 1 | 0-1 | 1 | 0-1 | 1 | 0-1 | 1112 MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1113 MIP-Home-Agent-Address | 0-1 | 0 | 0-1 | 0 | 1 | 0 | 1114 MIP-Careof-Address | 0 | 0 | 0 | 0 | 0-1 | 0 | 1115 MIP-Authenticator | 0 | 0 | 0 | 0 | 0-1 | 0 | 1116 MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 0-1 | 0 | 1117 MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 | 1118 MIP-MN-HA-MSA | 0 | 0-1 | 0 | 0 | 0 | 0-1 | 1119 MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1120 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 1 | 0-1 | 1121 Called-Station-Id | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1122 QoS-Resources | *0 | *0 | *0 | *0 | *0 | *0 | 1123 QoS-Capability | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1124 +-----+-----+-----+-----+-----+-----+ 1126 8.2. Coupled Accounting Model AVP Table 1128 The table in this section is used to represent which AVPs defined in 1129 this document are to be present in the Accounting messages, as 1130 defined in [5]. 1132 +-------------+ 1133 | Command-Code| 1134 |------+------+ 1135 Attribute Name | ACR | ACA | 1136 -------------------------------------|------+------+ 1137 Accounting-Input-Octets | 1 | 0-1 | 1138 Accounting-Input-Packets | 1 | 0-1 | 1139 Accounting-Output-Octets | 1 | 0-1 | 1140 Accounting-Output-Packets | 1 | 0-1 | 1141 Acct-Multi-Session-Id | 1 | 0-1 | 1142 Acct-Session-Time | 1 | 0-1 | 1143 MIP6-Feature-Vector | 1 | 0-1 | 1144 MIP-Home-Agent-Address | 1 | 0-1 | 1145 MIP-Mobile-Node-Address | 1 | 0-1 | 1146 Event-Timestamp | 0-1 | 0 | 1147 MIP-Careof-Address | 0-1 | 0 | 1148 QoS-Capability | *0 | *0 | 1149 QoS-Resources | *0 | *0 | 1150 -------------------------------------|------+------+ 1152 9. IANA Considerations 1154 This section contains the namespaces that have either been created in 1155 this specification or had their values assigned to existing 1156 namespaces managed by IANA. 1158 9.1. Command Codes 1160 IANA is requested to allocate a command code value for the MIP6- 1161 Request-Message (MRM) and for the MIP6-Answer-Message (MAM) from the 1162 Command Code namespace defined in [5]. See Section 5 for the 1163 assignment of the namespace in this specification. 1165 9.2. AVP Codes 1167 This specification requires IANA to register the following new AVPs 1168 from the AVP Code namespace defined in [5]. 1170 o MIP-Careof-Address 1171 o MIP-Authenticator 1172 o MIP-MAC-Mobility-Data 1173 o MIP-Timestamp 1174 o MIP-MN-HA-SPI 1175 o MIP-MN-HA-MSA 1177 The AVPs are defined in Section 6. 1179 9.3. Result-Code AVP Values 1181 This specification requests IANA to allocate new values to the 1182 Result-Code AVP (AVP Code 268) namespace defined in [5]. See 1183 Section 7 for the assignment of the namespace in this specification. 1185 9.4. Application Identifier 1187 This specification requires IANA to allocate a new value for 1188 "Diameter Mobile IPv6" from the Application Identifier namespace 1189 defined in [5]. 1191 9.5. Namespaces 1193 This specification defines a new value to the Mobility Capability 1194 registry (see [10]) for use with the MIP6-Feature-Vector AVP: 1196 Token | Value | Description 1197 ---------------------------------+----------------------+------------ 1198 RO_SUPPORTED | 0x0000000800000000 | RFC TBD 1199 USER_TRAFFIC_ENCRYPTION | 0x0000000100000000 | RFC TBD 1201 9.6. Mobile IPv6 Status Codes 1203 This specification defines a new Mobile IPv6 [1] Status Code value. 1204 The Status Code must be allocated from the range 0-127: 1206 Status Code | Value | Description 1207 ----------------------------------------+---------------+------------ 1208 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD 1209 ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION | is set to TBD | RFC TBD 1211 10. Security Considerations 1213 The security considerations for the Diameter interaction required to 1214 accomplish the split scenario are described in in [2]. Additionally, 1215 the security considerations of the Diameter Base protocol [5], 1216 Diameter EAP application [7] are applicable to this document. This 1217 document does not introduce new security vulnerabilities. 1219 11. Acknowledgements 1221 The authors would like to thank Jari Arkko, Tolga Asversen, Pasi 1222 Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John 1223 Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay 1224 Devarapalli, Lionel Morand, Domagoj Premec and Yoshihiro Ohba for all 1225 the useful discussions. Ahmad Muhanna provided a detailed review of 1226 the document in August 2007. 1228 We would also like to thank our Area Director, Dan Romascanu, for his 1229 support. 1231 Hannes Tschofenig would like to thank the European Commission support 1232 in the co-funding of the ENABLE project, where this work is partly 1233 being developed. 1235 Julien Bournelle would like to thank GET/INT since he began this work 1236 while he was under their employ. 1238 12. References 1240 12.1. Normative References 1242 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1243 IPv6", RFC 3775, June 2004. 1245 [2] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1246 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1248 [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1249 "Authentication Protocol for Mobile IPv6", 1250 draft-ietf-mip6-rfc4285bis-02 (work in progress), 1251 December 2007. 1253 [4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1254 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1255 April 2007. 1257 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1258 "Diameter Base Protocol", RFC 3588, September 2003. 1260 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1261 Levels", BCP 14, RFC 2119, March 1997. 1263 [7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1264 Authentication Protocol (EAP) Application", RFC 4072, 1265 August 2005. 1267 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1268 RFC 4306, December 2005. 1270 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1271 Network Access Server Application", RFC 4005, August 2005. 1273 [10] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1274 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1275 Server to Diameter Server Interaction", 1276 draft-ietf-dime-mip6-integrated-08 (work in progress), 1277 February 2008. 1279 [11] Korhonen, J., Tschofenig, H., Arumaithurai, M., and M. Jones, 1280 "Quality of Service Attributes for Diameter", 1281 draft-ietf-dime-qos-attributes-04 (work in progress), 1282 January 2008. 1284 [12] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 1285 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1286 August 2005. 1288 12.2. Informative References 1290 [13] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1291 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1293 [14] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 1294 Lopez, "AAA Goals for Mobile IPv6", 1295 draft-ietf-mext-aaa-ha-goals-00 (work in progress), 1296 December 2007. 1298 [15] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. 1299 Loughney, "Diameter Applications Design Guidelines", 1300 draft-ietf-dime-app-design-guide-06 (work in progress), 1301 January 2008. 1303 [16] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1304 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1305 RFC 4283, November 2005. 1307 Authors' Addresses 1309 Jouni Korhonen 1310 TeliaSonera 1311 P.O.Box 970 1312 Sonera FIN-00051 1313 Finland 1315 Email: jouni.korhonen@teliasonera.com 1317 Hannes Tschofenig 1318 Nokia Siemens Networks 1319 Linnoitustie 6 1320 Espoo 02600 1321 Finland 1323 Phone: +358 (50) 4871445 1324 Email: Hannes.Tschofenig@gmx.net 1325 URI: http://www.tschofenig.com 1327 Julien Bournelle 1328 Orange Labs 1329 38-4O rue du general Leclerc 1330 Issy-Les-Moulineaux 92794 1331 France 1333 Email: julien.bournelle@orange-ftgroup.com 1335 Gerardo Giaretta 1336 Qualcomm 1337 5775 MoreHouse Dr 1338 San Diego, CA 92121 1339 USA 1341 Email: gerardo.giaretta@gmail.com 1343 Madjid Nakhjiri 1344 Motorola 1345 USA 1347 Email: madjid.nakhjiri@motorola.com 1349 Full Copyright Statement 1351 Copyright (C) The IETF Trust (2008). 1353 This document is subject to the rights, licenses and restrictions 1354 contained in BCP 78, and except as set forth therein, the authors 1355 retain all their rights. 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1360 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1361 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1362 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Intellectual Property 1367 The IETF takes no position regarding the validity or scope of any 1368 Intellectual Property Rights or other rights that might be claimed to 1369 pertain to the implementation or use of the technology described in 1370 this document or the extent to which any license under such rights 1371 might or might not be available; nor does it represent that it has 1372 made any independent effort to identify any such rights. Information 1373 on the procedures with respect to rights in RFC documents can be 1374 found in BCP 78 and BCP 79. 1376 Copies of IPR disclosures made to the IETF Secretariat and any 1377 assurances of licenses to be made available, or the result of an 1378 attempt made to obtain a general license or permission for the use of 1379 such proprietary rights by implementers or users of this 1380 specification can be obtained from the IETF on-line IPR repository at 1381 http://www.ietf.org/ipr. 1383 The IETF invites any interested party to bring to its attention any 1384 copyrights, patents or patent applications, or other proprietary 1385 rights that may cover technology that may be required to implement 1386 this standard. Please address the information to the IETF at 1387 ietf-ipr@ietf.org. 1389 Acknowledgment 1391 Funding for the RFC Editor function is provided by the IETF 1392 Administrative Support Activity (IASA).