idnits 2.17.1 draft-ietf-dime-mip6-split-10.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 1576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1600. 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 (July 6, 2008) is 5770 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-09 == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-07 == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-04 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-06 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-08 Summary: 6 errors (**), 0 flaws (~~), 7 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: January 7, 2009 J. Bournelle 7 Orange Labs 8 G. Giaretta 9 Qualcomm 10 M. Nakhjiri 11 Motorola 12 July 6, 2008 14 Diameter Mobile IPv6: Support for Home Agent to Diameter Server 15 Interaction 16 draft-ietf-dime-mip6-split-10.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 January 7, 2009. 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. Application Identifiers . . . . . . . . . . . . . . . . . . . 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 . . . 11 72 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared 73 Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4. Support for the Mobile IPv6 Authentication Protocol . . . 11 75 4.5. Mobile IPv6 Session Management . . . . . . . . . . . . . . 12 76 4.5.1. Session-Termination-Request . . . . . . . . . . . . . 12 77 4.5.2. Session-Termination-Answer . . . . . . . . . . . . . . 13 78 4.5.3. Abort-Session-Request . . . . . . . . . . . . . . . . 13 79 4.5.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . 13 80 4.6. Accounting for Mobile IPv6 services . . . . . . . . . . . 13 81 4.6.1. Accounting-Request . . . . . . . . . . . . . . . . . . 14 82 4.6.2. Accounting-Answer . . . . . . . . . . . . . . . . . . 14 83 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP . . . . . 14 85 5.1.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . 14 86 5.1.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . 15 87 5.2. Command Code for Mobile IPv6 with IKEv2 and 88 Certificate- and PSK-based Authentication . . . . . . . . 16 89 5.2.1. AA-Request . . . . . . . . . . . . . . . . . . . . . . 16 90 5.2.2. AA-Answer . . . . . . . . . . . . . . . . . . . . . . 17 91 5.3. Command Codes for Mobile IPv6 Authentication Protocol 92 Support . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.3.1. MIP6-Request . . . . . . . . . . . . . . . . . . . . . 18 94 5.3.2. MIP6-Answer . . . . . . . . . . . . . . . . . . . . . 19 95 6. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 6.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 23 97 6.2. Service-Selection AVP . . . . . . . . . . . . . . . . . . 23 98 6.3. MIP-MN-AAA-SPI AVP . . . . . . . . . . . . . . . . . . . . 23 99 6.4. MIP-MN-HA-SPI AVP . . . . . . . . . . . . . . . . . . . . 23 100 6.5. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . . 24 101 6.6. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 24 102 6.7. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 24 103 6.8. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 24 104 6.9. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 25 105 6.10. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 25 106 6.11. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 25 107 6.12. MIP-MN-HA-MSA AVP . . . . . . . . . . . . . . . . . . . . 25 108 6.13. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 26 109 6.14. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 26 110 6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 26 111 6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 27 112 6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 28 113 6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 28 114 6.19. Chargeable-User-Identity AVP . . . . . . . . . . . . . . . 28 115 6.20. Coupled Accounting Model Accounting AVPs . . . . . . . . . 28 116 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 29 117 7.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 29 118 7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 29 119 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 30 120 8.1. AAR, AAA, DER, DEA, MIR and MIA AVP/Command-Code Table . . 30 121 8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 31 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 123 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 32 124 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 32 125 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 33 126 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 33 127 9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 33 128 9.6. Mobile IPv6 Status Codes . . . . . . . . . . . . . . . . . 34 129 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 130 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 131 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 132 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 133 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 135 Intellectual Property and Copyright Statements . . . . . . . . . . 38 137 1. Introduction 139 Performing the Mobile IPv6 protocol [1], requires the Mobile Node 140 (MN) to own a Home Address (HoA) and to have an assigned Home Agent 141 (HA) to the MN. The MN needs to register with the HA in order to 142 enable its reachability and mobility, when away from its home link. 143 The registration process itself may require an establishment of IPSec 144 security associations (SA) and cryptographic material between the MN 145 and HA. Alternatively, the registration process may be secured using 146 a mobility message authentication option, which enables IPv6 mobility 147 in a MN without having to establish an IPSec SA with its HA. 148 Providing the collection of home address, HA address and keying 149 material is generally referred to as the Mobile IPv6 bootstrapping 150 problem [15]. The purpose of this specification is to provide 151 Diameter support for the interaction between the HA and the AAA 152 server. This specification satisfies the requirements defined in 153 [16] for the bootstrapping problem in the split scenario [2] and also 154 specifies Diameter support for the Authentication Protocol for Mobile 155 IPv6 [3]. The Diameter support defined in this specification also 156 applies to Dual Stack Mobile IPv6 [17]. 158 From a mobility service provider (MSP) perspective, it is important 159 to verify that the MN is authenticated and authorized to utilize 160 Mobile IPv6 service, and is accounted for those. Only when the MN is 161 authenticated and authorized, the MSP allows the bootstrapping of 162 Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6 163 registrations, the HA, participates in the authentication of the MN 164 to verify the MN's identity. The HA also participates in the Mobile 165 IPv6 authorization process involving the Diameter infrastructure. 166 The HA, due to its role in traffic forwarding, may also perform 167 accounting for the Mobile IPv6 service provided to the MN. 169 This document enables the following functionality: 171 Authentication: Asserting or helping with assertion of the 172 correctness of the MN identity. As a Diameter client supporting 173 the new Diameter Mobile IPv6 application, the HA may need to 174 support more than one authentication type depending on the 175 environment. Although the authentication is performed by the AAA 176 server there is an impact for the HA as different set of command 177 codes are needed for the respective authentication procedures. 179 Authorization: The HA must verify that the user is authorized to the 180 Mobile IPv6 service using the assistance of the MSP Diameter 181 servers. This is accomplished through the use of new Diameter 182 applications specifically designed for performing Mobile IPv6 183 authorization decisions. This document defines required AAA 184 procedures and requires the HA to support them and to participate 185 in this authorization signaling. 187 Accounting: For accounting purposes and capacity planning, it is 188 required of the HA to provide accounting report to the Diameter 189 infrastructure and thus to support the related Diameter accounting 190 procedures. 192 Session Management: The management of the mobility services may 193 require the AAA to abort or the HA to terminate the Mobile IPv6 194 service before the binding expires. This document defines 195 procedures for the AAA based session management. 197 Figure 1 depicts the reference architecture for this document. 199 +--------+ 200 |Diameter| 201 |Server | 202 +--------+ 203 ^ 204 Back-End | Diameter Mobile IPv6 205 Protocol | HA<->AAA Server 206 Support | Interaction 207 | (this document) 208 v 209 +---------+ +---------------+ 210 | Mobile | Front-End Protocol |Home Agent / | 211 | Node |<-------------------->|Diameter Client| 212 +---------+ IKEv2 or RFC 4285 +---------------+ 214 Figure 1: Architecture Overview 216 Mobile IPv6 signaling between the MN and the HA can be protected 217 using two different mechanisms, namely using IPSec or Authentication 218 Protocol for Mobile IPv6 [3]. For these two approaches several 219 different authentication and key exchange solutions are available. 220 When IPSec is used to protect Mobile IPv6 signaling messages, IKEv2 221 is used [4]. IKEv2 supports EAP-based authentication, certificates 222 and pre-shared secrets. Alternatively, Authentication Protocol for 223 Mobile IPv6 uses a mechanism that is very similar to the one used for 224 protecting Mobile IPv4 signaling messages. 226 The ability to use different credentials has an impact on the 227 interaction between the HA (acting as a Diameter client) and the 228 Diameter Server. For that reason this document illustrates the usage 229 of these authentication mechanisms with different subsections for: 231 o IKEv2 usage with EAP 232 o IKEv2 usage with certificates and pre-shared secrets 233 o Mobile IPv6 Authentication Protocol 235 For accounting of Mobile IPv6 services provided to the MN, this 236 specification uses the Diameter Base Protocol accounting defined in 237 RFC 3588 [5]. 239 2. Terminology 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 243 document are to be interpreted as described in RFC 2119 [6]. 245 The Mobile IPv6 bootstrapping terminology is taken from [15]. 247 3. Application Identifiers 249 This specification defines two new Diameter applications and their 250 respective Application Identifiers: 252 Diameter Mobile IPv6 IKE (MIP6I) TBD by IANA 253 Diameter Mobile IPv6 Auth (MIP6A) TBD by IANA 255 The MIP6I Application Identifier is used when the MN is authenticated 256 and authorized using IKEv2. The MIP6A Application Identifier is used 257 when the MN is authenticated and authorized using Mobile IPv6 258 Authentication Protocol. 260 Mobile IPv6 related accounting generated by the HA uses either MIP6I 261 or MIP6A Application Identifier in the case of coupled accounting 262 model. Diameter Base Accounting Application Identifier (value of 3) 263 is used in the case of split accounting model. Refer Section 4.6 for 264 more information regarding the accounting models. 266 4. Protocol Description 268 4.1. Support for Mobile IPv6 with IKEv2 and EAP 270 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 271 authenticate the MN. When EAP is used with IKEv2, the Diameter EAP 272 application logic and procedures, as defined in [7], are re-used. 273 EAP methods that do not establish a shared key SHOULD NOT be used, as 274 they are subject to a number of man-in-the-middle attacks as stated 275 in Section 2.16 and Section 5 of RFC 4306 [8]. AVPs specific to 276 Mobile IPv6 bootstrapping are added to the EAP application commands. 278 Figure 3 shows the message flow involved during the authentication 279 phase when EAP is used. 281 Mobile Home Diameter 282 Node Agent Server 283 | | | 284 | HDR, SAi1, KEi, Ni (1) | | 285 |-------------------------------->| | 286 | | | 287 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 288 |<--------------------------------| | 289 | | | 290 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 291 | [CP(CFG_REQUEST),] | | 292 | SAi2, TSi, TSr} (3) | | 293 |-------------------------------->| DER (EAP-Response) (4) | 294 | |------------------------->| 295 | | | 296 | | DEA (EAP-Request) (5) | 297 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------| 298 |<------------------------------- | | 299 | | | 300 | HDR, SK{EAP} | | 301 |-------------------------------->| DER (EAP-Response) | 302 | |------------------------->| 303 | | | 304 | | DEA (EAP-Request) | 305 | HDR, SK{EAP-Request} |<-------------------------| 306 |<--------------------------------| | 307 | | | 308 | HDR, SK{EAP-Response} | | 309 |-------------------------------->| DER (EAP-Response) | 310 | |------------------------->| 311 | ... | ... | 312 | | | 313 | | DEA (EAP-Success) | 314 | |<-------------------------| 315 | HDR, SK{EAP-Success} | | 316 |<--------------------------------| | 317 | | | 318 | HDR, SK{AUTH} | | 319 |-------------------------------->| | 320 | | | 321 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 322 | SAr2, TSi, TSr} | | 323 |<--------------------------------| | 324 | | | 326 Figure 3: Mobile IPv6 bootstrapping using IKEv2 and EAP 328 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 330 In this phase cryptographic algorithms are negotiated, nonces and 331 Diffie-Hellman parameters are exchanged. Message (3) starts the 332 IKE_AUTH phase. This second phase authenticates the previous 333 messages, exchanges identities and certificates and establishes the 334 first CHILD_SA. It is used to mutually authenticate the MN (acting 335 as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). 336 The identity of the user/MN is provided in the IDi field. The MN 337 indicates its willingness to be authenticated via EAP by omitting the 338 AUTH field in message (3) (see Section 2.16 of [8]). 340 As part of the authentication process, the MN MAY request a Home- 341 Address, a Home Prefix or suggests one, see [4], using a CFG_REQUEST 342 payload in the message (3). 344 The HA extracts the IDi field from the message (3) and sends a 345 Diameter-EAP-Request (DER) message (4) towards the authenticating 346 Diameter server. The EAP-Payload AVP contains a EAP-Response/ 347 Identity with the identity extracted from the IDi field. 349 This message is routed to the MN's Diameter server/EAP server. The 350 Diameter server selects the EAP method and replies with the Diameter- 351 EAP-Answer (DEA) Message. Depending on the type of EAP method 352 chosen, a number of DER and DEA messages carry the method specific 353 exchanges between the MN and the Diameter server/EAP server. 355 At the end of the EAP authentication phase, the Diameter server 356 indicates the result of the authentication in the Result-Code AVP and 357 provides the corresponding EAP packet (EAP Success or EAP Failure). 358 The last IKEv2 message sent by the HA contains the Home Address or 359 the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 360 necessary to setup IPSec SAs for Mobile IPv6 signaling. 362 In some deployment scenarios, the HA may also acts as a IKEv2 363 Responder for IPSec VPN access. A problem in this case is that the 364 IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service 365 or for IPSec VPN access service. A network operator needs to be 366 aware of this limitation. The MN may provide a hint of the intended 367 service, for example, by using different identities in the IKE_AUTH 368 message for the IPSec VPN service and Mobile IPv6 service. However, 369 the use of different identities during the IKEv2 negotiation is 370 deployment specific. Another possibility is to make the distinction 371 on the MN subscription basis. In this case the Diameter server can 372 inform the HA during the IKEv2 negotiation whether the MN is 373 provisioned with an IPSec VPN access service or Mobile IPv6 service. 375 Eventually, when the HA receives a Binding Update (BU), the HA 376 authenticates and authorizes the MN. It is RECOMMENDED that the HA 377 sends an accounting request message every time it receives a BU. 379 4.2. Support for Mobile IPv6 with IKEv2 and Certificates 381 When IKEv2 is used with certificate-based authentication, the 382 Diameter NASREQ application logic and procedures, as defined in [9], 383 are re-used to authorize the MN for the Mobile IPv6 service. The IDi 384 payload extracted from the IKE_AUTH message MUST correspond to the 385 identity in the MN's certificate. This identity is then used by the 386 HA to populate the User-Name AVP in the succeeding AA-Request 387 message. Further PKI-related procedures such as certificate 388 revocation checking are out of scope of this document. 390 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets 392 When IKEv2 is used with PSK-based initiator authentication, the 393 Diameter NASREQ application [9] is re-used to authorize the MN for 394 the Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 395 message has to contain an identity that is meaningful for the 396 Diameter infrastructure, such as a Network Access Identifier (NAI), 397 and is then used by the HA to populate the User-Name AVP in the 398 succeeding AA-Request message. 400 4.4. Support for the Mobile IPv6 Authentication Protocol 402 Figure 4 shows the message sequence between the MN, the HA and the 403 Diameter server during the registration when Mobile IPv6 404 Authentication Protocol is used. A BU and a Binding Acknowledgement 405 (BA) messages are used in the binding registration process. 407 Receiving a BU at the HA initiates a MIP6-Request to be sent to the 408 Diameter server. The Diameter server in turn responds with a MIP6- 409 Answer. The HA may assign a Home Address to the MN and provide it to 410 the Diameter server in the MIP-Mobile-Node-Address AVP. 412 According to [3] the MN uses the Mobile Node Identifier Option, 413 specifically the MN-NAI mobility option (as defined in [18]) to 414 identify itself. The HA MUST copy the MN-NAI mobility option value 415 to the User-Name AVP in the subsequent request messages. 417 The procedure described in this specification for the Mobile IPv6 418 Authentication Protocol is only needed for the initial BU received by 419 the HA. When the HA receives subsequent BUs, they are processed 420 locally in the HA. It is RECOMMENDED that the HA sends an accounting 421 request message every time it receives a Binding Update. However, 422 the HA MAY re-authorize the MN with the Diameter server at any time 423 depending on the deployment and the local policy. 425 In some architectures and network deployments the MN-HA security 426 associations may be established as a result of a successful network 427 access authentication. In such deployments, both MN and Diameter 428 server share the keying material required for computation and 429 validation of the MN-HA Authentication Option, and a Security 430 Parameter Index (SPI) for indexing an appropriate security 431 association. Upon receiving a BU with a MN-HA Authentication Option, 432 the HA retrieves the keying material required for the computation and 433 validation of the MN-HA Authentication Option from the Diameter 434 server. The Diameter request message sent by the HA must contain 435 enough information (such as SPI, MN-NAI, etc) so that the Diameter 436 server is able to locate the matching MN-HA security association and 437 return correct keying material back to the HA. 439 Mobile Home Diameter 440 Node Agent Server 441 | | | 442 | | | 443 | Binding Update |MIP6-Request | 444 |------------------------------------>|-------------------->| 445 | (Mobile Node Identifier Option, | | 446 | Mobility Message Replay Protection | | 447 | Option, Authentication Option) | | 448 | | | 449 | | | 450 | Binding Acknowledgement |MIP6-Answer | 451 |<------------------------------------|<--------------------| 452 | (Mobile Node Identifier Option | | 453 | Mobility Message Replay Protection | | 454 | Option, Authentication Option) | | 456 Figure 4: Mobile IPv6 Bootstrapping using the Mobile IPv6 457 Authentication Protocol 459 4.5. Mobile IPv6 Session Management 461 The Diameter server may maintain state or may be stateless. This is 462 indicated in the Auth-Session-State AVP (or its absence). The HA 463 MUST support the Authorization Session State Machine defined in [5]. 464 Moreover, the following four commands may be exchanged between the HA 465 and the Diameter server. 467 4.5.1. Session-Termination-Request 469 The Session-Termination-Request (STR) message [5] is sent by the HA 470 to inform the Diameter server that an authorized session is being 471 terminated. 473 4.5.2. Session-Termination-Answer 475 The Session-Termination-Answer (STA) message [5] is sent by the 476 Diameter server to acknowledge the notification that the session has 477 been terminated. 479 4.5.3. Abort-Session-Request 481 The Abort-Session-Request (ASR) message [5] is sent by the Diameter 482 server to terminate the session. This fulfills one of the 483 requirement described in [16]. 485 4.5.4. Abort-Session-Answer 487 The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent 488 in response to an ASR message. 490 4.6. Accounting for Mobile IPv6 services 492 The HA MUST be able act as a Diameter client collecting accounting 493 records needed for service control and charging. The HA MUST support 494 the accounting procedures (specifically the command codes mentioned 495 below) and the Accounting Session State Machine as defined in [5]. 496 The command codes, exchanged between the HA and Diameter server for 497 accounting purposes, are provided in the following subsections. 499 The Diameter application design guideline [19] defines two separate 500 models for accounting: 502 Split accounting model: 504 According to this model, the accounting messages use the Diameter 505 Base Accounting Application Identifier (value of 3). Since 506 accounting is treated as an independent application, accounting 507 commands may be routed separately from the rest of application 508 messages and thus the accounting messages generally end up in a 509 central accounting server. Since Diameter Mobile IPv6 application 510 does not define its own unique accounting commands, this is the 511 preferred choice, since it permits use of centralized accounting 512 for several applications. 514 Coupled accounting model: 516 In this model, the accounting messages will use either the Mobile 517 IPv6 Split or the Mobile IPv6 Auth Application Identifiers. This 518 means that accounting messages will be routed like any other 519 Mobile IPv6 application messages. This requires the Diameter 520 server in charge of Mobile IPv6 application to handle the 521 accounting records (e.g., sends them to a proper accounting 522 server). 524 As mentioned above, the preferred choice is to use the split 525 accounting model and thus to choose Diameter Base Accounting 526 Application Identifier (value of 3) for accounting messages. 528 4.6.1. Accounting-Request 530 The Accounting-Request command [5] is sent by the HA to the Diameter 531 server to exchange accounting information regarding the MN with the 532 Diameter server. 534 4.6.2. Accounting-Answer 536 The Accounting-Answer command [5] is sent by the Diameter server to 537 the HA to acknowledge receiving an Accounting-Request. 539 5. Command Codes 541 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP 543 For the use of Mobile IPv6 with IKEv2 and EAP this document reuses 544 the Diameter EAP application [7] commands: Diameter-EAP-Request (DER) 545 and Diameter-EAP-Answer (DEA). This specification extends the 546 existing DER and DEA command ABNFs with a number AVPs to support 547 Mobile IPv6 split scenario bootstrapping. Other than new additional 548 AVPs and the corresponding additions to the command ABNFs, the 549 Diameter EAP application command ABNFs remain unchanged. 551 Command-Name Abbrev. Code Reference Application 552 --------------------------------------------------------------------- 553 Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE 554 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE 556 Figure 5: Command Codes 558 5.1.1. Diameter-EAP-Request 560 The Diameter-EAP-Request (DER) message, indicated by the Command-Code 561 field set to 268 and the 'R' bit set in the Command Flags field, is 562 sent by the HA to the Diameter server to initiate a Mobile IPv6 563 service authentication and authorization procedure. The 564 Application-ID field of the Diameter Header MUST be set to the 565 Diameter Mobile IPv6 IKE Application ID (value of TDB). 567 ::= < Diameter Header: 268, REQ, PXY > 568 < Session-Id > 569 { Auth-Application-Id } 570 { Origin-Host } 571 { Origin-Realm } 572 { Destination-Realm } 573 { Auth-Request-Type } 574 [ Destination-Host ] 575 [ NAS-Identifier ] 576 [ NAS-IP-Address ] 577 [ NAS-IPv6-Address ] 578 [ NAS-Port-Type ] 579 [ User-Name ] 580 ... 581 { EAP-Payload } 582 ... 583 [ MIP6-Feature-Vector ] 584 *2[ MIP6-Agent-Info ] 585 *2[ MIP-Mobile-Node-Address ] 586 [ Chargeable-User-Identity ] 587 [ Service-Selection ] 588 [ QoS-Capability ] 589 * [ QoS-Resources ] 590 ... 591 * [ AVP ] 593 5.1.2. Diameter-EAP-Answer 595 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 596 field set to 268 and 'R' bit cleared in the Command Flags field, is 597 sent in response to the Diameter-EAP-Request message (DER). The 598 Application-Id field in the Diameter message header MUST be set to 599 the Diameter Mobile IPv6 IKE Application-Id (value of TBD). If the 600 Mobile IPv6 authentication procedure was successful then the response 601 MAY include any set of bootstrapping AVPs. 603 ::= < Diameter Header: 268, PXY > 604 < Session-Id > 605 { Auth-Application-Id } 606 { Auth-Request-Type } 607 { Result-Code } 608 { Origin-Host } 609 { Origin-Realm } 610 [ User-Name ] 611 [ EAP-Payload ] 612 [ EAP-Reissued-Payload ] 613 [ EAP-Master-Session-Key ] 614 [ EAP-Key-Name ] 615 [ Multi-Round-Time 616 ... 617 *2[ MIP-Mobile-Node-Address ] 618 [ MIP6-Feature-Vector ] 619 *2[ MIP6-Agent-Info ] 620 * [ QoS-Resources ] 621 [ Chargeable-User-Identity ] 622 ... 623 * [ AVP ] 625 5.2. Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK- 626 based Authentication 628 For the use of Mobile IPv6 with IKEv2, and certificate- and PSK-based 629 authentication this document reuses the Diameter NASREQ application 630 [9] commands: AA-Request (AAR) and AA-Answer (AAA). This 631 specification extends the existing AAR and AAA command ABNFs with a 632 number AVPs to support Mobile IPv6 split scenario bootstrapping. 633 Other than new additional AVPs and the corresponding additions to the 634 command ABNFs, the Diameter NASREQ application command ABNFs remain 635 unchanged. 637 Command-Name Abbrev. Code Reference Application 638 --------------------------------------------------------------------- 639 AA-Request AAR 265 RFC 4005 Diameter Mobile IPv6 IKE 640 AA-Answer AAA 265 RFC 4005 Diameter Mobile IPv6 IKE 642 Figure 8: Command Codes 644 5.2.1. AA-Request 646 The AA-Request (AAR) message, indicated by the Command-Code field set 647 to 265 and the 'R' bit set in the Command Flags field, is sent by the 648 HA to the Diameter server to initiate a Mobile IPv6 service 649 authentication and authorization procedure. The Application-ID field 650 of the Diameter Header MUST be set to the Diameter Mobile IPv6 IKE 651 Application ID (value of TBD). 653 ::= < Diameter Header: 265, REQ, PXY > 654 < Session-Id > 655 { Auth-Application-Id } 656 { Origin-Host } 657 { Origin-Realm } 658 { Destination-Realm } 659 { Auth-Request-Type } 660 [ Destination-Host ] 661 [ NAS-Identifier ] 662 [ NAS-IP-Address ] 663 [ NAS-IPv6-Address ] 664 [ NAS-Port-Type ] 665 [ User-Name ] 666 ... 667 [ MIP6-Feature-Vector ] 668 *2[ MIP5-Agent-Info ] 669 *2[ MIP-Mobile-Node-Address ] 670 [ Chargeable-User-Identity ] 671 [ Service-Selection ] 672 [ QoS-Capability ] 673 * [ QoS-Resources ] 674 ... 675 * [ AVP ] 677 5.2.2. AA-Answer 679 The AA-Answer (AAA) message, indicated by the Command-Code field set 680 to 265 and 'R' bit cleared in the Command Flags field, is sent in 681 response to the AA-Request message (AAR). If the Mobile IPv6 682 authentication procedure was successful then the response MAY include 683 any set of bootstrapping AVPs. The Application-Id field in the 684 Diameter header MUST be set to the Diameter Mobile IPv6 IKE 685 Application-Id (value of TBD). 687 ::= < Diameter Header: 265, PXY > 688 < Session-Id > 689 { Auth-Application-Id } 690 { Auth-Request-Type } 691 { Result-Code } 692 { Origin-Host } 693 { Origin-Realm } 694 [ User-Name ] 695 [ Authorization-Lifetime ] 696 ... 697 *2[ MIP-Mobile-Node-Address ] 698 *2[ MIP6-Agent-Info ] 699 [ MIP6-Feature-Vector ] 700 [ MIP-MN-HA-MSA ] 701 * [ QoS-Resources ] 702 [ Chargeable-User-Identity ] 703 ... 704 * [ AVP ] 706 When IKEv2 is used with PSK-based initiator authentication, the pre- 707 shared secret is carried inside the MIP-MN-HA-MSA AVP. The pre- 708 shared secret SHOULD NOT be user's long term secret and it is 709 RECOMMENDED that a short-term keying material specifically created 710 for this purpose is used instead. 712 5.3. Command Codes for Mobile IPv6 Authentication Protocol Support 714 This section defines the commands that are used for support with the 715 Mobile IPv6 Authentication Protocol. 717 Command-Name Abbrev. Code Reference Application 718 --------------------------------------------------------------------- 719 MIP6-Request MIR TBD 5.3.1 Diameter Mobile IPv6 Auth 720 MIP6-Answer MIA TBD 5.3.2 Diameter Mobile IPv6 Auth 722 Command Codes 724 5.3.1. MIP6-Request 726 The MIP6-Request (MIR), indicated by the Command-Code field set to 727 TBD and the 'R' bit set in the Command Flags field, is sent by the 728 HA, acting as a Diameter client, in order to request the 729 authentication and authorization of a MN. 731 Although the HA provides the Diameter server with a replay protection 732 related information, the HA is responsible for the replay protection. 734 The message format is shown below. 736 ::= < Diameter Header: XXX, REQ, PXY > 737 < Session-ID > 738 { Auth-Application-Id } 739 { User-Name } 740 { Destination-Realm } 741 { Origin-Host } 742 { Origin-Realm } 743 [ Destination-Host ] 744 [ Origin-State-Id ] 745 [ NAS-Identifier ] 746 [ NAS-IP-Address ] 747 [ NAS-IPv6-Address ] 748 [ NAS-Port-Type ] 749 [ Called-Station-Id ] 750 [ Calling-Station-Id ] 751 [ MIP6-Feature-Vector ] 752 [ MIP-MN-AAA-SPI ] 753 [ MIP-MN-HA-SPI ] 754 { MIP-Mobile-Node-Address } 755 { MIP6-Agent-Info } 756 [ MIP-Careof-Address ] 757 [ MIP-Authenticator ] 758 [ MIP-MAC-Mobility-Data ] 759 [ MIP-Timestamp ] 760 [ QoS-Capability ] 761 * [ QoS-Resources ] 762 [ Chargeable-User-Identity ] 763 [ Service-Selection ] 764 [ Authorization-Lifetime ] 765 [ Auth-Session-State ] 766 * [ Proxy-Info ] 767 * [ Route-Record ] 768 * [ AVP ] 770 5.3.2. MIP6-Answer 772 The MIP6-Answer (MIA) message, indicated by the Command-Code field 773 set to TBD and the 'R' bit cleared in the Command Flags field, is 774 sent by the Diameter server in response to the MIP6-Request message. 775 The User-Name MAY be included in the MIA if it is present in the MIR. 776 The Result-Code AVP MAY contain one of the values defined in 777 Section 7, in addition to the values defined in RFC 3588 [5]. 779 An MIA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 780 include the MIP-Mobile-Node-Address AVP. 782 The message format is shown below. 784 ::= < Diameter Header: XXX, PXY > 785 < Session-Id > 786 { Auth-Application-Id } 787 { Result-Code } 788 { Origin-Host } 789 { Origin-Realm } 790 [ Acct-Multi-Session-Id ] 791 [ User-Name ] 792 [ Authorization-Lifetime ] 793 [ Auth-Session-State ] 794 [ Error-Message ] 795 [ Error-Reporting-Host ] 796 [ Re-Auth-Request-Type ] 797 [ MIP6-Feature-Vector ] 798 [ MIP-Agent-Info ] 799 [ MIP-Mobile-Node-Address ] 800 [ MIP-MN-HA-MSA ] 801 * [ QoS-Resources ] 802 [ Chargeable-User-Identity ] 803 [ Origin-State-Id ] 804 * [ Proxy-Info ] 805 * [ Redirect-Host ] 806 [ Redirect-Host-Usage ] 807 [ Redirect-Max-Cache-Time ] 808 * [ Failed-AVP ] 809 * [ AVP ] 811 6. AVPs 813 To provide support for RFC 4285 [3] and for RFC 4877 [4] the AVPs in 814 the following subsections are needed. RFC 3588, RFC 4004 and RFC 815 4005 defined AVPs are reused whenever possible without changing the 816 existing semantics of those AVPs. 818 +--------------------------+ 819 | AVP Flag rules | 820 +----+-----+----+-----+----+ 821 AVP Defined | | |SHLD| MUST|MAY | 822 Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr| 823 +-----------------------------------------+----+-----+----+-----+----+ 824 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 825 | Vector | | | | | | 826 +-----------------------------------------+----+-----+----+-----+----+ 827 |MIP-Mobile- | M | P | | V | Y | 828 | Node-Address 334 RFC4004 Address | | | | | | 829 +-----------------------------------------+----+-----+----+-----+----+ 830 |MIP6-Agent-Info TBD Note 3 Grouped | M | P | | V | Y | 831 +-----------------------------------------+----+-----+----+-----+----+ 832 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 833 +-----------------------------------------+----+-----+----+-----+----+ 834 |Service- TBD 6.2 UTF8String | M | P | | V | Y | 835 | Selection | | | | | | 836 +-----------------------------------------+----+-----+----+-----+----+ 837 |QoS-Capability TBD Note 2 Grouped | M | P | | V | Y | 838 +-----------------------------------------+----+-----+----+-----+----+ 839 |QoS-Resources TBD Note 2 Grouped | M | P | | V | Y | 840 +-----------------------------------------+----+-----+----+-----+----+ 841 |MIP-MN-HA-MSA TBD 6.12. Grouped | M | P | | V | Y | 842 +-----------------------------------------+----+-----+----+-----+----+ 843 |Chargeable-User- OctetString| | M,P | | V | Y | 844 | Identity 89 6.19 | | | | | | 845 +-----------------------------------------+----+-----+----+-----+----+ 847 AVPs for Mobile IPv6 IKE Application 849 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 851 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 852 Sections 4.1 and 4.3 of [11]. 854 Note 3: The MIP6-Agent-Info is defined in Section 4.5.1 of [10]. 856 +--------------------------+ 857 | AVP Flag rules | 858 +----+-----+----+-----+----+ 859 AVP Section | | |SHLD| MUST|MAY | 860 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 861 +-----------------------------------------+----+-----+----+-----+----+ 862 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 863 | Vector | | | | | | 864 +-----------------------------------------+----+-----+----+-----+----+ 865 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 866 +-----------------------------------------+----+-----+----+-----+----+ 867 |Service- TBD 6.2 UTF8String | M | P | | V | Y | 868 | Selection | | | | | | 869 +-----------------------------------------+----+-----+----+-----+----+ 870 |MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | | M,P | | V | Y | 871 +-----------------------------------------+----+-----+----+-----+----+ 872 |MIP-MN-HA-SPI TBD 6.4 Unsigned32 | M | P | | V | Y | 873 +-----------------------------------------+----+-----+----+-----+----+ 874 |MIP-Mobile- 333 RFC4004 Address | M | P | | V | Y | 875 | Node-Address | | | | | | 876 +-----------------------------------------+----+-----+----+-----+----+ 877 |MIP6-Agent-Info TBD Note 3 Grouped | M | P | | V | Y | 878 +-----------------------------------------+----+-----+----+-----+----+ 879 |MIP-Careof- TBD 6.7 Address | M | P | | V | Y | 880 | Address | | | | | | 881 +-----------------------------------------+----+-----+----+-----+----+ 882 |MIP- TBD 6.8 OctetString| | M,P | | V | Y | 883 | Authenticator | | | | | | 884 +-----------------------------------------+----+-----+----+-----+----+ 885 |MIP-MAC- TBD 6.9 OctetString| | M,P | | V | Y | 886 | Mobility-Data | | | | | | 887 +-----------------------------------------+----+-----+----+-----+----+ 888 |MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y | 889 +-----------------------------------------+----+-----+----+-----+----+ 890 |MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y | 891 | Lifetime | | | | | | 892 +-----------------------------------------+----+-----+----+-----+----+ 893 |MIP-MN-HA-MSA TBD 6.12 Grouped | M | P | | V | Y | 894 +-----------------------------------------+----+-----+----+-----+----+ 895 |MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y | 896 | Type | | | | | | 897 +-----------------------------------------+----+-----+----+-----+----+ 898 |MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y | 899 +-----------------------------------------+----+-----+----+-----+----+ 900 |MIP-Timestamp TBD 6.16 Time | | M,P | | V | Y | 901 +-----------------------------------------+----+-----+----+-----+----+ 902 |QoS-Capability TBD Note 2 Grouped | | M,P | | M | Y | 903 +-----------------------------------------+----+-----+----+-----+----+ 904 |QoS-Resources TBD Note 2 Grouped | | M,P | | V | Y | 905 +-----------------------------------------+----+-----+----+-----+----+ 906 |Chargeable-User- OctetString| | M,P | | V | Y | 907 | Identity 89 6.19 | | | | | | 908 +-----------------------------------------+----+-----+----+-----+----+ 909 |Rest of the AVPs RFC3588 | M | P | | V | Y | 910 |in the MIR & MIA RFC4005 | | | | | | 911 |excluding *[AVP] | | | | | | 912 +-----------------------------------------+----+-----+----+-----+----+ 913 AVPs for the Mobile IPv6 Auth Application 915 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 917 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 918 Sections 4.1 and 4.3 of [11]. 920 Note 3: The MIP6-Agent-Info is defined in Section 4.5.1 of [10]. 922 6.1. User-Name AVP 924 The User-Name AVP (AVP Code 1) is of type UTF8String and contains an 925 NAI extracted from the MN-NAI mobility option included in the 926 received BU message. Alternatively, the NAI can be extracted from 927 the IKEv2 IDi payload included in the IKE_AUTH message sent by the 928 IKE initiator. 930 6.2. Service-Selection AVP 932 The Service-Selection AVP (AVP Code TBD) is of type UTF8String and 933 contains the string extracted from the IKEv2 IDr payload, if 934 available in the IKE_AUTH message sent by the IKE initiator. If the 935 Mobile IPv6 Authentication Protocol is used, then the Service- 936 Selection AVP contains the string extracted from the Service 937 Selection Mobility Option [20], if available in the received BU. 939 6.3. MIP-MN-AAA-SPI AVP 941 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 942 contains an SPI code extracted from the Mobility Message 943 Authentication Option included in the received BU message. The HA 944 includes this AVP in the MIR message when the MN-AAA Mobility Message 945 Authentication Option is available in the received BU. The HA sets 946 the 'M'-bit for this AVP when the Diameter server is expected to 947 return the key material required for the calculation and validation 948 of the Mobile IPv6 MN-HA Authentication Option. 950 This AVP is re-used from [12]. 952 6.4. MIP-MN-HA-SPI AVP 954 The MIP-MN-HA-SPI AVP (AVP Code TBD) is of type Unsigned32 and 955 contains an SPI code which can be used with other parameters for 956 identifying the security association required for the validation of 957 the Mobile IPv6 MN-HA Authentication Option. 959 When included in the MIR message, the Diameter server needs to return 960 a valid MIP-MN-HA-MSA AVP in the corresponding MIA message. Either 961 the MIP-MN-HA-SPI AVP or the MIP-MN-AAA-SPI AVP MUST be present in 962 the MIR message, but not both. 964 6.5. MIP-Mobile-Node-Address AVP 966 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 967 contains the HA assigned IPv6 or IPv4 Home Address of the Mobile 968 Node. 970 If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address 971 (0::0) or all zeroes IPv4 address (0.0.0.0) in a request message, 972 then the HA expects the Diameter server to assign the Home Address in 973 a subsequent answer message. If the Diameter server assigns only an 974 IPv6 Home Network Prefix to the Mobile Node the lower 64 bits of the 975 MIP-Mobile-Node-Address AVP provided address MUST be set to zero. 977 This AVP is re-used from [12]. 979 6.6. MIP6-Agent-Info AVP 981 The MIP6-Agent-Info AVP is defined in Section 4.5.1 of [10] and 982 contains the IPv6 or the IPv4 address information of the HA. The HA 983 address in a request message is the same as in the received BU 984 message that triggered the authentication and authorization procedure 985 towards the Diameter server. 987 If the MIP6-Agent-Info AVP is present in an answer message and the 988 Result-Code AVP is set to DIAMETER_SUCCESS_RELOCATE_HA, then the 989 Diameter server is indicating to the HA that it MUST initiate a HA 990 switch procedure towards the MN (e.g., using the procedure defined in 991 [13]). If the Result-Code AVP is set to any other value, then the HA 992 SHOULD initiate the HA switch procedure towards the MN. The address 993 information of the assigned HA is defined in the MIP6-Agent-Info AVP. 995 6.7. MIP-Careof-Address AVP 997 The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and 998 contains the IPv6 Care-of Address of the Mobile Node. The HA 999 extracts this IP address from the received BU message. 1001 6.8. MIP-Authenticator AVP 1003 The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and 1004 contains the Authenticator Data from the received BU message. The HA 1005 extracts this data from the MN-AAA Mobility Message Authentication 1006 Option included in the received BU message. The HA includes this AVP 1007 in the MIR message and sets the 'M'-bit when the Diameter server is 1008 expected to return the key material required for the calculation and 1009 validation of the Mobile IPv6 MN-HA Authentication Option. 1011 6.9. MIP-MAC-Mobility-Data AVP 1013 The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString 1014 and contains the calculated MAC_Mobility_Data, as defined in [3]. 1015 The HA includes this AVP in the MIR message when the MN-AAA Mobility 1016 Message Authentication Option is available in the received BU. The 1017 HA sets the 'M'-bit for this AVP when the Diameter server is expected 1018 to return the key material required for the calculation and 1019 validation of the Mobile IPv6 MN-HA Authentication Option. 1021 6.10. MIP-Session-Key AVP 1023 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1024 contains the MN-HA shared secret (i.e., the session key) for the 1025 associated Mobile IPv6 MH-HA authentication option. When the 1026 Diameter server computes the session key it is placed in this AVP. 1028 The MIP-Session-Key AVP may also be used to convey a pre-shared 1029 secret when IKEv2 is used with PSK-based initiator authentication. 1031 This AVP is re-used from [12]. 1033 6.11. MIP-MSA-Lifetime AVP 1035 The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1036 represents the period of time (in seconds) for which the session key 1037 (see Section 6.10) is valid. The associated session key MUST NOT be 1038 used if the lifetime has expired. 1040 This AVP is re-used from [12]. 1042 6.12. MIP-MN-HA-MSA AVP 1044 The MIP-MN-HA-MSA AVP (AVP Code TBD) is of type Grouped and contains 1045 the session related information for use with the Mobile IPv6 1046 Authentication Protocol. 1048 MIP-MN-HA-MSA ::= < AVP Header: TBD > 1049 { MIP-Session-Key } 1050 { MIP-MSA-Lifetime } 1051 [ MIP-MN-HA-SPI ] 1052 [ MIP-Algorithm-Type ] 1053 [ MIP-Replay-Mode ] 1054 * [ AVP ] 1056 The MIP-MN-HA-SPI sub-AVP within the MIP-MN-HA-MSA grouped AVP 1057 identifies the security association required for the validation of 1058 the Mobile IPv6 MN-HA Authentication Option. 1060 6.13. MIP-Algorithm-Type AVP 1062 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and 1063 contains Algorithm identifier for the associated Mobile IPv6 MN-HA 1064 Authentication Option. The Diameter server selects the algorithm 1065 type. Existing algorithm types are defined in RFC 4004 that also 1066 fulfill current RFC 4285 requirements. 1068 This AVP is re-used from [12]. 1070 6.14. MIP-Replay-Mode AVP 1072 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1073 contains the replay mode the HA for authenticating the mobile node. 1074 The replay modes, defined in RFC 4004 [12], are supported. 1076 This AVP is re-used from [12]. 1078 6.15. MIP6-Feature-Vector AVP 1080 This AVP is defined in [10]. This document defines a new capability 1081 bit for signaling the support of Mobile IPv6 route optimization. The 1082 following capability is defined in this document: 1084 MIP6_SPLIT (0x0000000100000000) 1086 When this flag is set by the NAS then it means that the Mobile 1087 IPv6 split scenario bootstrapping functionality is supported by 1088 the NAS. When this flag is set by the Diameter server then the 1089 Mobile IPv6 split scenario bootstrapping is supported by the 1090 Diameter server. 1092 RO_SUPPORTED (0x0000000200000000) 1094 Route optimization is supported. When the HA sets this bit, it 1095 indicates support for the route optimization. If this bit is 1096 unset in the returned Mobility-Capability AVP, the AAAH does not 1097 authorize route optimization for the MN. 1099 In a case the HA or the AAAH cannot authorize the use of route 1100 optimization then the HA SHOULD send a Binding Acknowledgement 1101 with a Status Code set to ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION 1102 (status code TBD). This Status Code indicates that the binding 1103 registration succeeded but the HA will fail all possible 1104 subsequent route optimization attempts because of subscription or 1105 operator policy. 1107 USER_TRAFFIC_ENCRYPTION (0x0000000400000000) 1109 User plane traffic encryption is supported. When the HA sets this 1110 bit, it indicates support for the user plane traffic encryption 1111 between the MN and the HA. If this bit is unset in the returned 1112 Mobility-Capability AVP, the AAAH does not authorize user plane 1113 traffic encryption because of subscription or operator policy. 1115 In the case the AAAH cannot authorize the use of user plane 1116 traffic encryption then the HA SHOULD send a Binding 1117 Acknowledgement with a Status Code set to 1118 ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION (status code TBD). This Status 1119 Code indicates that the binding registration succeeded but the HA 1120 will silently discard all encrypted user plane packets sent by the 1121 MN to the HA. 1123 VPN_GW_MODE (0x0000000800000000) 1125 The HA is supposed to act as a IPSec VPN gateway for the user. 1126 When the HA sets this bit, it indicates support for acting as a 1127 standalone IPSec VPN gateway. If this bit is unset in the 1128 returned Mobility-Capability AVP, the AAAH does not authorize the 1129 HA to act as a standalone IPSec VPN gateway for the MN because of 1130 subscription or operator policy. 1132 MCOA_SUPPORTED (0x0000001000000000) 1134 Multiple Care-of Addresses (MCoA) [21] are supported. When the HA 1135 sets this bit, it indicates support for the MCoA. If this bit is 1136 unset in the returned Mobility-Capability AVP, the AAAH does not 1137 authorize the use of MCoA for the MN. 1139 In a case the HA or the AAAH cannot authorize the use of the MCoA 1140 then the HA SHOULD send a Binding Acknowledgement with a Status 1141 Code set to ACCEPTED_BUT_NO_MCOA (status code TBD). This Status 1142 Code indicates that the binding registration succeeded but the HA 1143 will fail all possible subsequent attempts to use MCoA because of 1144 subscription or operator policy. 1146 6.16. MIP-Timestamp AVP 1148 The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain 1149 the timestamp value from the Mobility message replay protection 1150 option, defined in [3]. The HA extracts this value from the received 1151 BU message, if available. The HA includes this AVP in the MIR 1152 message when the MN-AAA Mobility Message Authentication Option is 1153 available in the received BU. The HA sets the 'M'-bit for this AVP 1154 when the Diameter server is expected to return the key material 1155 required for the calculation and validation of the Mobile IPv6 MN-HA 1156 Authentication Option. 1158 6.17. QoS-Capability AVP 1160 The QoS-Capability AVP is defined in [11] and contains a list of 1161 supported Quality of Service profiles. The HA sets the 'M'-bit for 1162 this AVP in the request message if it requires the Diameter server to 1163 understand and support QoS treatment for MNs. In all other occasions 1164 the HA MUST NOT set the 'M'-bit. 1166 6.18. QoS-Resources AVP 1168 The QoS-Resources AVP is defined in [11] and provides QoS and packet 1169 filtering capabilities. The HA sets the 'M'-bit for this AVP in the 1170 request message if it requires the Diameter server to understand and 1171 support QoS treatment for MNs. The Diameter server sets the 'M'-bit 1172 for this AVP only if the corresponding request message had the 1173 'M'-bit set for the QoS-Resources AVP. In all other occasions the HA 1174 or the Diameter MUST NOT set the 'M'-bit. 1176 6.19. Chargeable-User-Identity AVP 1178 The Chargeable-User-Identity AVP (AVP code 89) is of type OctetString 1179 and contains an unique temporary handle of the user. The Chargeable- 1180 User-Identity is defined in RFC 4372 [14]. 1182 The HA sets the 'M'-bit for the Chargeable-User-Id AVP if the 1183 Diameter server is required to understand this AVP and the HA expects 1184 the Diameter server to return a meaningful identity back to the HA. 1185 The Diameter server sets the 'M'-bit for the returned Chargeable- 1186 User-Id AVP only if the corresponding request message had the 'M'-bit 1187 set for the Chargeable-User-Id AVP. In all other occasions the HA or 1188 the Diameter MUST NOT set the 'M'-bit. 1190 6.20. Coupled Accounting Model Accounting AVPs 1192 Diameter Mobile IPv6 application is used in the case of the coupled 1193 account model. Diameter Mobile IPv4 application [12] accounting AVPs 1194 are reused in this document. The following AVPs SHOULD be included 1195 in the accounting request message: 1197 o Accounting-Input-Octets: Number of octets in IP packets received 1198 from the mobile node. 1199 o Accounting-Output-Octets: Number of octets in IP packets sent by 1200 the mobile node 1201 o Accounting-Input-Packets: Number of IP packets received from the 1202 mobile node. 1203 o Accounting-Output-Packets: Number of IP packets sent by the mobile 1204 node. 1205 o Acct-Multi-Session-Id: Used to link together multiple related 1206 accounting sessions, where each session would have a unique 1207 Session-Id, but the same Acct-Multi-Session-Id AVP. 1208 o Acct-Session-Time: Indicates the length of the current session in 1209 seconds. 1210 o MIP6-Feature-Vector: The supported features for this mobility 1211 service session. 1212 o MIP-Mobile-Node-Address: The Home Address of the mobile node. 1213 o MIP-Agent-Info: The current home agent of the mobile node. 1214 o Chargeable-User-Identity: The unique temporary identity of the 1215 user. This AVP MUST be included if it is available in the home 1216 agent. 1217 o Service-Selection: Currently selected mobility service. 1218 o QoS-Resources: Assigned QoS resources for the mobile node. 1219 o QoS-Capability: The QoS capability related to the assigned QoS- 1220 Resources. 1221 o MIP-Careof-Address: The current Care-of Address of the mobile 1222 node. 1224 7. Result-Code AVP Values 1226 This section defines new Result-Code [5] values that MUST be 1227 supported by all Diameter implementations that conform to this 1228 specification. 1230 7.1. Success 1232 Errors that fall within the Success category are used to inform a 1233 peer that a request has been successfully completed. 1235 DIAMETER_SUCCESS_RELOCATE_HA (Status Code TBD) 1237 This result code is used by the Diameter server to inform the HA 1238 that the MN MUST be switched to another HA. 1240 7.2. Permanent Failures 1242 Errors that fall within the permanent failures category are used to 1243 inform the peer that the request failed and SHOULD NOT be attempted 1244 again. 1246 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION (Status Code TBD) 1248 This error is used by the Diameter server to inform the peer that 1249 the requested Mobile IPv6 session keys could not be delivered via 1250 a security association. 1252 8. AVP Occurrence Tables 1254 The following tables present the AVPs defined in this document and 1255 their occurrences in Diameter messages. Note that AVPs that can only 1256 be present within a Grouped AVP are not represented in this table. 1258 The table uses the following symbols: 1260 0: 1262 The AVP MUST NOT be present in the message. 1264 0+: 1266 Zero or more instances of the AVP MAY be present in the message. 1268 0-1: 1270 Zero or one instance of the AVP MAY be present in the message. 1272 1: 1274 One instance of the AVP MUST be present in the message. 1276 8.1. AAR, AAA, DER, DEA, MIR and MIA AVP/Command-Code Table 1277 +-----------------------------------+ 1278 | Command-Code | 1279 |-----+-----+-----+-----+-----+-----+ 1280 AVP Name | AAR | AAA | DER | DEA | MIR | MIA | 1281 -------------------------------|-----+-----|-----+-----+-----+-----+ 1282 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1283 MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 | 1 | 0-1 | 1284 MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1285 MIP-MN-HA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1286 MIP6-Agent-Info | 1-2 | 0-2 | 1-2 | 0-2 | 1 | 0-1 | 1287 MIP-Careof-Address | 0 | 0 | 0 | 0 | 0-1 | 0 | 1288 MIP-Authenticator | 0 | 0 | 0 | 0 | 0-1 | 0 | 1289 MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 0-1 | 0 | 1290 MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 | 1291 MIP-MN-HA-MSA | 0 | 0-1 | 0 | 0 | 0 | 0-1 | 1292 MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1293 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 1 | 0-1 | 1294 Service-Selection | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1295 QoS-Resources | *0 | *0 | *0 | *0 | *0 | *0 | 1296 QoS-Capability | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1297 Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1298 +-----+-----+-----+-----+-----+-----+ 1300 8.2. Coupled Accounting Model AVP Table 1302 The table in this section is used to represent which AVPs defined in 1303 this document are to be present in the Accounting messages, as 1304 defined in [5]. 1306 +-------------+ 1307 | Command-Code| 1308 |------+------+ 1309 Attribute Name | ACR | ACA | 1310 -------------------------------------|------+------+ 1311 Accounting-Input-Octets | 0-1 | 0-1 | 1312 Accounting-Input-Packets | 0-1 | 0-1 | 1313 Accounting-Output-Octets | 0-1 | 0-1 | 1314 Accounting-Output-Packets | 0-1 | 0-1 | 1315 Acct-Multi-Session-Id | 0-1 | 0-1 | 1316 Acct-Session-Time | 0-1 | 0-1 | 1317 MIP6-Feature-Vector | 0-1 | 0-1 | 1318 MIP6-Agent-Info | 0-1 | 0-1 | 1319 MIP-Mobile-Node-Address | 0-1 | 0-1 | 1320 Event-Timestamp | 0-1 | 0 | 1321 MIP-Careof-Address | 0-1 | 0 | 1322 Service-Selection | 0-1 | 0 | 1323 QoS-Capability | *0 | *0 | 1324 QoS-Resources | *0 | *0 | 1325 Chargeable-User-Identity | 0-1 | 0 | 1326 -------------------------------------|------+------+ 1328 9. IANA Considerations 1330 This section contains the namespaces that have either been created in 1331 this specification or had their values assigned to existing 1332 namespaces managed by IANA. 1334 9.1. Command Codes 1336 IANA is requested to allocate a command code values for the following 1337 new commands from the Command Code namespace defined in [5]. See 1338 Section 5 for the assignment of the namespace in this specification. 1340 Command Code | Value 1341 -----------------------------------+------ 1342 MIP6-Request (MIR) | TBD 1343 MIP6-Answer (MIA) | TBD 1345 9.2. AVP Codes 1347 This specification requires IANA to register the following new AVPs 1348 from the AVP Code namespace defined in [5]. 1350 o MIP-Careof-Address 1351 o MIP-Authenticator 1352 o MIP-MAC-Mobility-Data 1353 o MIP-Timestamp 1354 o MIP-MN-HA-SPI 1355 o MIP-MN-HA-MSA 1356 o Service-Selection 1358 The AVPs are defined in Section 6. 1360 9.3. Result-Code AVP Values 1362 This specification requests IANA to allocate new values to the 1363 Result-Code AVP (AVP Code 268) namespace defined in [5]. See 1364 Section 7 for the assignment of the namespace in this specification. 1366 Result-Code | Value 1367 ----------------------------------------------+------ 1368 DIAMETER_SUCCESS_RELOCATE_HA | TBD 1369 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION | TBD 1371 9.4. Application Identifier 1373 This specification requires IANA to allocate two new values "Diameter 1374 Mobile IPv6 IKE" and "Diameter Mobile IPv6 Auth" from the Application 1375 Identifier namespace defined in [5]. 1377 Application Identifier | Value 1378 -----------------------------------+------ 1379 Diameter Mobile IPv6 IKE (MIP6I) | TBD 1380 Diameter Mobile IPv6 Auth (MIP6A) | TBD 1382 9.5. Namespaces 1384 This specification defines a new value to the Mobility Capability 1385 registry (see [10]) for use with the MIP6-Feature-Vector AVP: 1387 Token | Value | Description 1388 ---------------------------------+----------------------+------------ 1389 MIP6_SPLIT | 0x0000000100000000 | RFC TBD 1390 RO_SUPPORTED | 0x0000000200000000 | RFC TBD 1391 USER_TRAFFIC_ENCRYPTION | 0x0000000400000000 | RFC TBD 1392 VPN_GW_MODE | 0x0000000800000000 | RFC TBD 1393 MCOA_SUPPORTED | 0x0000001000000000 | RFC TBD 1395 9.6. Mobile IPv6 Status Codes 1397 This specification defines new Mobile IPv6 [1] Status Code values. 1398 The Status Code must be allocated from the range 0-127: 1400 Status Code | Value | Description 1401 ----------------------------------------+---------------+------------ 1402 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD 1403 ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION | is set to TBD | RFC TBD 1404 ACCEPTED_BUT_NO_MCOA | is set to TBD | RFC TBD 1406 10. Security Considerations 1408 The security considerations for the Diameter interaction required to 1409 accomplish the split scenario are described in in [2]. Additionally, 1410 the security considerations of the Diameter Base protocol [5], 1411 Diameter EAP application [7] are applicable to this document. This 1412 document does not introduce new security vulnerabilities. 1414 11. Acknowledgements 1416 The authors would like to thank Jari Arkko, Tolga Asversen, Pasi 1417 Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John 1418 Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay 1419 Devarapalli, Lionel Morand, Domagoj Premec, Semyon Mizikovsky and 1420 Yoshihiro Ohba for all the useful discussions. Ahmad Muhanna 1421 provided a detailed review of the document in August 2007. 1423 We would also like to thank our Area Director, Dan Romascanu, for his 1424 support. 1426 Hannes Tschofenig would like to thank the European Commission support 1427 in the co-funding of the ENABLE project, where this work is partly 1428 being developed. 1430 Julien Bournelle would like to thank GET/INT since he began this work 1431 while he was under their employ. 1433 Madjid Nakhjiri would like to thank Huawei USA as most of his 1434 contributions to this draft were possible while he was under their 1435 employ. 1437 12. References 1438 12.1. Normative References 1440 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1441 IPv6", RFC 3775, June 2004. 1443 [2] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1444 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1446 [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1447 "Authentication Protocol for Mobile IPv6", 1448 draft-ietf-mip6-rfc4285bis-02 (work in progress), 1449 December 2007. 1451 [4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1452 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1453 April 2007. 1455 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1456 "Diameter Base Protocol", RFC 3588, September 2003. 1458 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1459 Levels", BCP 14, RFC 2119, March 1997. 1461 [7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1462 Authentication Protocol (EAP) Application", RFC 4072, 1463 August 2005. 1465 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1466 RFC 4306, December 2005. 1468 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1469 Network Access Server Application", RFC 4005, August 2005. 1471 [10] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1472 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1473 Server to Diameter Server Interaction", 1474 draft-ietf-dime-mip6-integrated-09 (work in progress), 1475 May 2008. 1477 [11] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and 1478 A. Lior, "Quality of Service Attributes for Diameter", 1479 draft-ietf-dime-qos-attributes-07 (work in progress), 1480 June 2008. 1482 [12] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 1483 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1484 August 2005. 1486 [13] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility 1487 Header Home Agent Switch Message", RFC 5142, January 2008. 1489 [14] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 1490 "Chargeable User Identity", RFC 4372, January 2006. 1492 12.2. Informative References 1494 [15] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1495 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1497 [16] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 1498 Lopez, "AAA Goals for Mobile IPv6", 1499 draft-ietf-mext-aaa-ha-goals-01 (work in progress), May 2008. 1501 [17] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1502 Routers", draft-ietf-mext-nemo-v4traversal-04 (work in 1503 progress), June 2008. 1505 [18] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1506 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1507 RFC 4283, November 2005. 1509 [19] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. 1510 Loughney, "Diameter Applications Design Guidelines", 1511 draft-ietf-dime-app-design-guide-06 (work in progress), 1512 January 2008. 1514 [20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 1515 Selection for Mobile IPv6", RFC 5149, February 2008. 1517 [21] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1518 "Multiple Care-of Addresses Registration", 1519 draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. 1521 Authors' Addresses 1523 Jouni Korhonen 1524 TeliaSonera 1525 P.O.Box 970 1526 Sonera FIN-00051 1527 Finland 1529 Email: jouni.korhonen@teliasonera.com 1530 Hannes Tschofenig 1531 Nokia Siemens Networks 1532 Linnoitustie 6 1533 Espoo 02600 1534 Finland 1536 Phone: +358 (50) 4871445 1537 Email: Hannes.Tschofenig@gmx.net 1538 URI: http://www.tschofenig.priv.at 1540 Julien Bournelle 1541 Orange Labs 1542 38-4O rue du general Leclerc 1543 Issy-Les-Moulineaux 92794 1544 France 1546 Email: julien.bournelle@orange-ftgroup.com 1548 Gerardo Giaretta 1549 Qualcomm 1550 5775 MoreHouse Dr 1551 San Diego, CA 92121 1552 USA 1554 Email: gerardo.giaretta@gmail.com 1556 Madjid Nakhjiri 1557 Motorola 1558 USA 1560 Email: madjid.nakhjiri@motorola.com 1562 Full Copyright Statement 1564 Copyright (C) The IETF Trust (2008). 1566 This document is subject to the rights, licenses and restrictions 1567 contained in BCP 78, and except as set forth therein, the authors 1568 retain all their rights. 1570 This document and the information contained herein are provided on an 1571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1573 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1574 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1575 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1578 Intellectual Property 1580 The IETF takes no position regarding the validity or scope of any 1581 Intellectual Property Rights or other rights that might be claimed to 1582 pertain to the implementation or use of the technology described in 1583 this document or the extent to which any license under such rights 1584 might or might not be available; nor does it represent that it has 1585 made any independent effort to identify any such rights. Information 1586 on the procedures with respect to rights in RFC documents can be 1587 found in BCP 78 and BCP 79. 1589 Copies of IPR disclosures made to the IETF Secretariat and any 1590 assurances of licenses to be made available, or the result of an 1591 attempt made to obtain a general license or permission for the use of 1592 such proprietary rights by implementers or users of this 1593 specification can be obtained from the IETF on-line IPR repository at 1594 http://www.ietf.org/ipr. 1596 The IETF invites any interested party to bring to its attention any 1597 copyrights, patents or patent applications, or other proprietary 1598 rights that may cover technology that may be required to implement 1599 this standard. Please address the information to the IETF at 1600 ietf-ipr@ietf.org. 1602 Acknowledgment 1604 Funding for the RFC Editor function is provided by the IETF 1605 Administrative Support Activity (IASA).