idnits 2.17.1 draft-ietf-dime-mip6-integrated-08.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 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 894. 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 14, 2008) is 5889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC TBD' on line 725 ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (ref. '3') (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) == Outdated reference: A later version (-01) exists of draft-ietf-mext-aaa-ha-goals-00 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 J. Bournelle 5 Intended status: Standards Track Orange Labs 6 Expires: August 17, 2008 H. Tschofenig 7 Nokia Siemens Networks 8 C. Perkins 10 K. Chowdhury 11 Starent Networks 12 February 14, 2008 14 Diameter Mobile IPv6: Support for Network Access Server to Diameter 15 Server Interaction 16 draft-ietf-dime-mip6-integrated-08.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 17, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 A Mobile IPv6 node requires a home agent address, a home address, and 50 a security association with its home agent before it can start 51 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 52 parameters are statically configured. Mobile IPv6 bootstrapping work 53 aims to make this information dynamically available to the Mobile 54 Node. An important aspect of the Mobile IPv6 bootstrapping solution 55 is to support interworking with existing authentication, 56 authorization and accounting infrastructure. This document describes 57 the MIPv6 bootstrapping using the Diameter Network Access Server 58 (NAS) to home Authentication, Authorization and Accounting server 59 (HAAA) interface. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Commands, AVPs and Advertising Application Support . . . . . . 7 67 4.1. Advertising Application Support . . . . . . . . . . . . . 7 68 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 8 70 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 8 71 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 9 72 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 9 73 4.7. Attribute Value Pair Definitions . . . . . . . . . . . . . 10 74 4.7.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 10 75 4.7.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 11 76 4.7.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 11 77 4.7.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 11 78 4.7.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 11 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 13 81 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 14 82 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 14 83 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 16 84 6.1. AAR, AAA, DER and DEA Commands AVP Table . . . . . . . . . 16 85 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs . . . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 17 88 8.2. New Registry: Mobility Capability . . . . . . . . . . . . 17 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 Intellectual Property and Copyright Statements . . . . . . . . . . 21 97 1. Introduction 99 The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) 100 to perform registration with a home agent (HA) with information about 101 its current point of attachment (care-of address). The HA creates 102 and maintains binding between the MN's Home Address and the MN's 103 Care-of Address. 105 In order to register with a HA, the MN needs to know some information 106 such as the Home Link prefix, the HA address, the Home Address(es), 107 the Home Link prefix length and security association related 108 information. 110 The aforementioned information may be statically configured. 111 However, static provisioning becomes an administrative burden for an 112 operator. Moreover, it does not address load balancing, failover, 113 opportunistic home link assignment and assignment of local HAs in 114 close proximity to the MN. Also the ability to react to sudden 115 environmental or topological changes is minimal. Static provisioning 116 may not be desirable, in light of these limitations. 118 Dynamic assignment of MIPv6 home registration information is a 119 desirable feature for ease of deployment and network maintenance. 120 For this purpose, the AAA infrastructure, which is used for access 121 authentication, can be leveraged to assign some or all of the 122 necessary parameters. The Diameter server in Access Service 123 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 124 return these parameters to the AAA client. Regarding the 125 bootstrapping procedures, the AAA client might either be the NAS, in 126 case of the integrated scenario, or the HA, in case of the split 127 scenario [7]. The terms integrated and split are described in the 128 terminology section and were introduced in [8] and [9]. 130 2. Terminology and Abbreviations 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC2119 [2]. 136 General mobility terminology can be found in [10]. The following 137 additional terms, as defined in [8], are used in this document: 139 Access Service Authorizer (ASA): 141 A network operator that authenticates a MN and establishes the 142 MN's authorization to receive Internet service. 144 Access Service Provider (ASP): 146 A network operator that provides direct IP packet forwarding to 147 and from the MN. 149 Mobility Service Authorizer (MSA): 151 A service provider that authorizes MIPv6 service. 153 Mobility Service Provider (MSP): 155 A service provider that provides MIPv6 service. In order to 156 obtain such service, the MN must be authenticated and authorized 157 to obtain the MIPv6 service. 159 Split scenario: 161 A scenario where the mobility service and the network access 162 service are authorized by different entities. 164 Integrated Scenario: 166 A scenario where the mobility service and the network access 167 service are authorized by the same entity. 169 Network Access Server (NAS): 171 A device that provides an access service for a user to a network. 173 Home AAA (HAAA): 175 An authentication, authorization and accounting server located in 176 user's home network i.e., in the home realm. 178 Local AAA (LAAA): 180 An authentication, authorization and accounting proxy located in 181 the local (ASP) network. 183 Visited AAA (VAAA): 185 An authentication, authorization and accounting proxy located in a 186 visited network i.e., in the visited realm. In a roaming case, 187 the local Diameter proxy has the VAAA role. 189 3. Overview 191 This document addresses the authentication, authorization and 192 accounting functionality required for the MIPv6 bootstrapping 193 solutions outlined in [8] and focuses on the Diameter based AAA 194 functionality for the NAS to HAAA communication. 196 In the integrated scenario MIPv6 bootstrapping is provided as part of 197 the network access authentication procedure. Figure 1 shows the 198 participating entities. 200 +---------------------------+ +-----------------+ 201 |Access Service Provider | |ASA/MSA/(MSP) | 202 |(Mobility Service Provider)| | | 203 | | | | 204 | +--------+ | | +--------+ | 205 | |Local | Diameter | | |Home | | 206 | |Diameter|<---------------------->|Diameter| | 207 | |Proxy | (*) | | |Server | | 208 | +--------+ | | +--------+ | 209 | ^ ^ | | ^ | 210 | | | | | |(+) | 211 | | | | | | | 212 | Diameter | | v | 213 | | |(+) +-------+ | | +-------+ | 214 | | | |Home | | | |Home | | 215 | | +-------->|Agent | | | |Agent | | 216 | (*)| |in ASP | | | |in MSP | | 217 | v +-------+ | | +-------+ | 218 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 219 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 220 |Node |------------|Diameter |---|Server | | 221 | | PANA,... | |Client |(+)| | | 222 +-------+ DHCP | +-----------+ +-------+ | 223 (+) +---------------------------+ 225 Legend: 226 (*): Functionality in scope of this specification 227 (+): Extensions described in other documents. 229 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 231 In a typical MIPv6 access scenario, a MN is attached to an ASP's 232 network. During the network attachment procedure, the MN interacts 233 with the NAS/Diameter client. Subsequently, the NAS/Diameter client 234 interacts with the Diameter server over the NAS to HAAA interface. 236 When the Diameter server performs the authentication and 237 authorization for the network access it also determines whether the 238 user is authorized to the MIPv6 service. Based on the MIPv6 service 239 authorization and user's policy profile, the Diameter server may 240 return several MIPv6 bootstrapping related parameters to the NAS. 241 The NAS to HAAA interface described in this document is not tied to 242 DHCPv6 as the only mechanism to convey MIPv6 related configuration 243 parameters from the NAS/Diameter client to the mobile node. 245 4. Commands, AVPs and Advertising Application Support 247 4.1. Advertising Application Support 249 This document defines a number of MIPv6 bootstrapping NAS to HAAA 250 interface (integrated scenario) related AVPs. These AVPs can be used 251 with present and future Diameter applications, where permitted by the 252 command ABNF. This document does not define a new application. All 253 examples in this document reuse NASREQ [3] and EAP [4] applications. 255 4.2. Command Codes 257 This document shows re-use of the Diameter NASREQ application [3] and 258 the EAP application commands [4] as an example of the MIPv6 259 bootstrapping NAS to HAAA interface. The following commands are used 260 to carry MIPv6 related bootstrapping AVPs: 262 Command-Name Abbrev. Code Reference Application 264 Diameter-EAP-Request DER 268 RFC 4072 EAP 265 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 267 AA-Request AAR 265 RFC 4005 NASREQ 268 AA-Answer AAA 265 RFC 4005 NASREQ 270 Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 272 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 273 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 274 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 275 (ACR), and Accounting-Answer (ACA) commands are used together with 276 the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules 277 defined in RFC 3588 [5] and the rules for the specific Diameter 278 application the AVPs defined in this document are used with. The 279 accounting commands use the Application Identifier value of 3 280 (Diameter Base Accounting); the others use 0 (Diameter Common 281 Messages). 283 All request messages SHOULD contain the User-Name AVP containing the 284 identity of the MN in NAI format. It is out of scope how the NAS 285 finds out the MN identity. The NAS could, for example, use the MN 286 identity provided by the network access authentication mechanism. 288 4.3. Diameter-EAP-Request (DER) 290 The Diameter-EAP-Request (DER) message [4], indicated by the Command- 291 Code field set to 268 and the 'R' bit set in the Command Flags field, 292 is sent by the NAS to the Diameter server to initiate a network 293 access authentication and authorization procedure. The DER message 294 format is the same as defined in [4]. The message MAY include 295 optional MIPv6 bootstrapping AVPs: 297 ::= < Diameter Header: 268, REQ, PXY > 298 < Session-Id > 299 { Auth-Application-Id } 300 { Origin-Host } 301 { Origin-Realm } 302 { Destination-Realm } 303 { Auth-Request-Type } 305 * [ MIP6-Agent-Info ] 306 * [ MIP6-Home-Link-Prefix ] 307 [ MIP6-Feature-Vector ] 309 [ User-Name ] 310 [ Destination-Host ] 311 ... 312 * [ AVP ] 314 4.4. Diameter-EAP-Answer (DEA) 316 The Diameter-EAP-Answer (DEA) message defined in [4], indicated by 317 the Command-Code field set to 268 and 'R' bit cleared in the Command 318 Flags field, is sent in response to the Diameter-EAP-Request message 319 (DER). If the network access authentication procedure was successful 320 then the response MAY include any set of bootstrapping AVPs. 322 The DEA message format is the same as defined in [4] with an addition 323 of optional MIPv6 bootstrapping AVPs: 325 ::= < Diameter Header: 268, PXY > 326 < Session-Id > 327 { Auth-Application-Id } 328 { Auth-Request-Type } 329 { Result-Code } 330 { Origin-Host } 331 { Origin-Realm } 333 * [ MIP6-Agent-Info ] 334 * [ MIP6-Home-Link-Prefix ] 335 [ MIP6-Feature-Vector ] 337 [ User-Name ] 338 ... 339 * [ AVP ] 341 4.5. AA-Request (AAR) 343 The AA-Request (AAR) message [3], indicated by the Command-Code field 344 set to 265 and 'R' bit set in the Command Flags field, is sent by the 345 NAS to the Diameter server to initiate a network access 346 authentication and authorization procedure. The AAR message format 347 is the same as defined in [3]. The message MAY include optional 348 MIPv6 bootstrapping AVPs: 350 ::= < Diameter Header: 265, REQ, PXY > 351 < Session-Id > 352 { Auth-Application-Id } 353 { Origin-Host } 354 { Origin-Realm } 355 { Destination-Realm } 356 { Auth-Request-Type } 358 * [ MIP6-Agent-Info ] 359 * [ MIP6-Home-Link-Prefix ] 360 [ MIP6-Feature-Vector ] 362 [ User-Name ] 363 [ Destination-Host ] 364 ... 365 * [ AVP ] 367 4.6. AA-Answer (AAA) 369 The AA-Answer (AAA) message, indicated by the Command-Code field set 370 to 265 and 'R' bit cleared in the Command Flags field is sent in 371 response to the AA-Request (AAR) message for confirmation of the 372 result of MIPv6 HA bootstrapping. If the network access 373 authentication procedure was successful then the response MAY include 374 any set of bootstrapping AVPs. 376 The AAA message format is the same as defined in [3] with an addition 377 of optional MIPv6 bootstrapping AVPs: 379 ::= < Diameter Header: 265, PXY > 380 < Session-Id > 381 { Auth-Application-Id } 382 { Auth-Request-Type } 383 { Result-Code } 384 { Origin-Host } 385 { Origin-Realm } 387 * [ MIP6-Agent-Info ] 388 * [ MIP6-Home-Link-Prefix ] 389 [ MIP6-Feature-Vector ] 391 [ User-Name ] 392 ... 393 * [ AVP ] 395 4.7. Attribute Value Pair Definitions 397 4.7.1. MIP6-Agent-Info 399 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 400 contains necessary information to assign a HA to the MN. When the 401 MIP6-Agent-Info AVP is present in a message, it MUST contain either 402 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 403 both AVPs. The grouped AVP has the following grammar: 405 ::= < AVP Header: TBD > 406 [ MIP-Home-Agent-Address ] 407 [ MIP-Home-Agent-Host ] 408 * [ AVP ] 410 If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are 411 present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD 412 have a precedence over the MIP-Home-Agent-Host. The reason for this 413 recommendation is that the MIP-Home-Agent-Address points to a 414 specific home agent, where as the MIP-Home-Agent-Host may point to a 415 group of HAs located at within the same realm. A Diameter client or 416 an agent may use the MIP-Home-Agent-Host AVP, for instance, to find 417 out the realm where the HA is located. 419 This AVP MAY also be attached by the NAS or by intermediating 420 Diameter proxies in a request message when sent to the Diameter 421 server as a hint of a locally assigned HA. This AVP MAY also be 422 attached by the intermediating Diameter proxies in a reply message 423 from the Diameter server, if locally assigned HAs are authorized by 424 the Diameter server. 426 4.7.2. MIP-Home-Agent-Address AVP 428 The MIP-Home-Agent-Address AVP (AVP Code 334 [6]) is of type Address 429 and contains the HA address. The Diameter server MAY decide to 430 assign a HA to the MN that is in close proximity to the point of 431 attachment (e.g., determined by the NAS-Identifier AVP). There may 432 be other reasons for dynamically assigning HAs to the MN, for example 433 to share the traffic load. 435 4.7.3. MIP-Home-Agent-Host AVP 437 The MIP-Home-Agent-Host AVP (AVP Code 348 [6]) is of type Grouped and 438 contains the identity of the assigned HA. Both the Destination-Realm 439 and the Destination-Host AVP of the HA are included in the grouped 440 AVP. The usage of this AVP is equivalent to the MIP-Home-Agent- 441 Address AVP but offers an additional level of indirection by using 442 the DNS infrastructure. 444 Depending on the actual deployment and DNS configuration the 445 Destination-Host AVP MAY represent one or more home agents. It is 446 RECOMMENDED that the Destination-Host AVP identifies exactly one HA. 448 4.7.4. MIP6-Home-Link-Prefix AVP 450 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 451 and contains the Mobile IPv6 home network prefix information in 452 network byte order. The home network prefix MUST be encoded as the 453 8-bit prefix length information followed by the 128-bit field for the 454 available home network prefix. 456 4.7.5. MIP6-Feature-Vector AVP 458 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 459 contains a 64 bit flags field of supported capabilities of the NAS/ 460 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 461 MUST be supported, although that does not provide much guidance about 462 specific needs of bootstrapping. 464 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 465 to the Diameter server. For example, the NAS may indicate that a 466 local HA can be provided. Similarly, the Diameter server MAY include 467 this AVP to inform the NAS/ASP about which of the NAS/ASP indicated 468 capabilities are supported or authorized by the ASA/MSA(/MSP). 470 The following capabilities are defined in this document: 472 MIP6_INTEGRATED (0x0000000000000001) 474 When this flag is set by the NAS then it means that the Mobile 475 IPv6 integrated scenario bootstrapping functionality is supported 476 by the NAS. When this flag is set by the Diameter server then the 477 Mobile IPv6 integrated scenario bootstrapping is supported by the 478 Diameter server. 480 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 482 When this flag is set in the request message, a local home agent 483 outside the home realm is requested and may be assigned to the MN. 484 When this flag is set by the Diameter server in the answer 485 message, then the assignment of local HAs is authorized by the 486 Diameter server. 488 A local HA may be assigned by the NAS, LAAA or VAAA depending on 489 the network architecture and the deployment. 491 The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT 492 capability and the MIP-Agent-Info AVP are used to assign HAs, either 493 a local HA (L-HA) or a home network HA (H-HA). Below is an example 494 of a request message combinations as seen by the HAAA: 496 LOCAL-bit HA-Info Meaning 498 0 - ASP or [LV]AAA is not able to assign a L-HA 499 0 L-HA Same as above. HA-Info must be ignored 500 1 - ASP or [LV]AAA can/wishes to assign a L-HA 501 1 L-HA Same as above but ASP or [LV]AAA also 502 provides a hint of the assigned L-HA 504 Then the same as above for an answer message combinations as seen by 505 the NAS: 507 LOCAL-bit HA-Info Meaning 509 0 - No HA allowed -> no mobility 510 0 H-HA L-HA is not allowed. HAAA assigns a H-HA 511 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 512 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 513 1 H-HA L-HA is allowed. HAAA also assigns a HA 514 1 H-HA L-HA is allowed. HAAA assigns a H-HA and 515 + L-HA [LV]AAA also assigns also a L-HA 517 5. Examples 519 5.1. Home Agent Assignment by the NAS 521 In this scenario we consider the case where the NAS wishes to 522 allocate a local HA to the MN. The NAS will also inform the Diameter 523 server about the HA address it has assigned to the visiting MN (e.g., 524 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 525 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 526 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 527 Agent-Address AVP with the address of the proposed HA. 529 Diameter 530 NAS Server 531 | | 532 | Diameter-EAP-Request | 533 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 534 | | MIP6_INTEGRATED) | 535 | MIP6-Agent-Info{ | 536 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 537 | } | 538 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 539 | EAP-Payload(EAP Start) | 540 |---------------------------------------------------------------->| 541 | | 542 | | 543 : ...more EAP Request/Response pairs... : 544 | | 545 | | 546 | Diameter-EAP-Answer | 547 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 548 | | MIP6_INTEGRATED) | 549 | Result-Code=DIAMETER_SUCCESS | 550 | EAP-Payload(EAP Success) | 551 | EAP-Master-Session-Key | 552 | (authorization AVPs) | 553 | ... | 554 |<----------------------------------------------------------------| 555 | | 557 Figure 3: Home Agent Assignment by NAS 559 Depending on the Diameter server configuration and user's 560 subscription profile, the Diameter server either accepts or rejects 561 the proposal of locally HA allocated by the NAS will be used. In our 562 example, the Diameter server accepts the proposal and the the MIP6- 563 Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together 564 with the MIP6_INTEGRATED flag) is set and returned to the NAS. 566 5.2. Home Agent Assignment by the Diameter Server 568 In this scenario we consider the case where the NAS supports the 569 Diameter MIPv6 integrated scenario as defined in this document but 570 does not offer local HA assignment. Hence, the MIP6-Feature-Vector 571 AVP only has the MIP6_INTEGRATED flag set. The Diameter server 572 allocates a HA to the mobile node and conveys the address in the MIP- 573 Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info 574 AVP. Additionally, the MIP6-Feature-Vector AVP has the 575 MIP6_INTEGRATED flag set. 577 Diameter 578 NAS Server 579 | | 580 | Diameter-EAP-Request | 581 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 582 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 583 | EAP-Payload(EAP Start) | 584 |---------------------------------------------------------------->| 585 | | 586 | | 587 : ...more EAP Request/Response pairs... : 588 | | 589 | | 590 | Diameter-EAP-Answer | 591 | MIP6-Agent-Info{ | 592 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64) | 593 | } | 594 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 595 | Result-Code=DIAMETER_SUCCESS | 596 | EAP-Payload(EAP Success) | 597 | EAP-Master-Session-Key | 598 | (authorization AVPs) | 599 | ... | 600 |<----------------------------------------------------------------| 601 | | 603 Figure 4: Home Agent Assignment by Diameter Server 605 5.3. Home Agent Assignment by NAS or Diameter Server 607 This section shows a message flow for the MIPv6 integrated scenario 608 bootstrapping where the NAS informs the Diameter server that it is 609 able to locally assign a HA to the MN. The Diameter server is able 610 to provide a HA to the MN but also authorizes the assignment of local 611 HA. The Diameter server then replies to the NAS with HA related 612 bootstrapping information. 614 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 615 server assigned HA to the MN is, in this example, based on the local 616 ASP policy. 618 Diameter 619 NAS Server 620 | | 621 | Diameter-EAP-Request | 622 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 623 | | MIP6_INTEGRATED) | 624 | MIP6-Agent-Info{ | 625 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 626 | } | 627 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 628 | EAP-Payload(EAP Start) | 629 |---------------------------------------------------------------->| 630 | | 631 | | 632 : ...more EAP Request/Response pairs... : 633 | | 634 | | 635 | Diameter-EAP-Answer | 636 | MIP6-Agent-Info{ | 637 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} | 638 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 639 | | MIP6_INTEGRATED) | 640 | Result-Code=DIAMETER_SUCCESS | 641 | EAP-Payload(EAP Success) | 642 | EAP-Master-Session-Key | 643 | (authorization AVPs) | 644 | ... | 645 |<----------------------------------------------------------------| 646 | | 648 Figure 5: Home Agent Assignment by NAS or Diameter Server 650 If the Diameter server does not accept locally assigned HA, the 651 Diameter returns the MIP6-Feature-Vector AVP with 652 LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it plans to 653 allocate for the MN. 655 6. AVP Occurrence Tables 657 6.1. AAR, AAA, DER and DEA Commands AVP Table 659 The following table lists the additional MIPv6 bootstrapping NAS to 660 HAAA interface AVPs that may optionally be present in the AAR and AAA 661 Commands [3] or in the DER and DEA Commands [4]. 663 +-----------------------+ 664 | Command-Code | 665 |-----+-----+-----+-----+ 666 Attribute Name | AAR | AAA | DER | DEA | 667 -------------------------------|-----+-----|-----+-----+ 668 MIP6-Agent-Info | 0+ | 0+ | 0+ | 0+ | 669 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 670 MIP6-Home-Link-Prefix | 0+ | 0+ | 0+ | 0+ | 671 +-----+-----+-----+-----+ 673 Figure 6: AAR, AAA, DER and DEA Commands AVP Table 675 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs 677 This section defines AVPs that are specific to Diameter MIPv6 678 bootstrapping NAS to HAAA interface and MAY be included in the 679 Diameter EAP [4] and the NASREQ [3] application messages. The 680 Diameter AVP rules are defined in the Diameter Base [5], Section 4. 681 These AVP rules are observed in AVPs defined in this section. 683 The following table describes the Diameter AVPs, their AVP Code 684 values, types, possible flag values, and whether the AVP MAY be 685 encrypted. The Diameter base [5] specifies the AVP Flag rules for 686 AVPs in Section 4.5. 688 +---------------------+ 689 | AVP Flag rules | 690 +----+-----+----+-----+----+ 691 AVP Section | | |SHLD|MUST | | 692 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 693 ------------------------------------------+----+-----+----+-----+----+ 694 MIP6-Agent-Info TBD 4.7.1 Grouped | | P | | V,M | Y | 695 MIP-Home-Agent- | | | | | | 696 Address 334 4.7.2 Address | | P | | V,M | Y | 697 MIP-Home-Agent- | | | | | | 698 Host 348 4.7.3 Grouped | | P | | V,M | Y | 699 MIP6-Feature- | | | | | | 700 Vector TBD 4.7.5 Unsigned64 | | P | | V,M | Y | 701 MIP6-Home-Link- TBD 4.7.4 OctetString| | P | | V,M | Y | 702 Prefix | | | | | | 703 ------------------------------------------+----+-----+----+-----+----+ 705 Figure 7: AVP Flag Rules Table 707 8. IANA Considerations 709 8.1. Registration of new AVPs 711 This specification defines the following new AVPs: 713 MIP6-Agent-Info is set to TBD 714 MIP6-Feature-Vector is set to TBD 715 MIP6-Home-Link-Prefix is set to TBD 717 8.2. New Registry: Mobility Capability 719 IANA is requested to create a new registry for the Mobility 720 Capability as described in Section 4.7.5. 722 Token | Value | Description 723 ----------------------------------+----------------------+------------ 724 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 725 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 726 Available for Assignment via IANA | 2^x | 728 Allocation rule: Only numeric values that are 2^x (power of two) are 729 allowed based on the allocation policy described below. 731 Following the policies outlined in [1] new values with a description 732 of their semantic for usage with the MIP6-Feature-Vector AVP together 733 with a Token will be assigned after Expert Review initiated by the 734 O&M Area Directors in consultation with the DIME working group chairs 735 or the working group chairs of a designated successor working group. 736 Updates can be provided based on expert approval only. A designated 737 expert will be appointed by the O&M Area Directors. No mechanism to 738 mark entries as "deprecated" is envisioned. Based on expert approval 739 it is possible to delete entries from the registry. 741 9. Security Considerations 743 The security considerations for the Diameter interaction required to 744 accomplish the integrated scenario are described in [11]. 745 Additionally, the security considerations of the Diameter base 746 protocol [5], Diameter NASREQ application [3] / Diameter EAP [4] 747 application (with respect to network access authentication and the 748 transport of keying material) are applicable to this document. This 749 document does not introduce new security vulnerabilities. 751 10. Acknowledgements 753 This document is heavily based on the ongoing work for RADIUS MIPv6 754 interaction. Hence, credits go to respective authors for their work 755 with draft-ietf-mip6-radius. Furthermore, the author would like to 756 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 757 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 758 in context of MIPv6 Diameter interworking. Their work influenced 759 this document. Jouni Korhonen would like to thank Academy of Finland 760 and TEKES MERCoNe Project for providing funding to work on this 761 document. Julien Bournelle would like to thank GET/INT since he 762 began to work on this document while he was in their employ. Authors 763 would also like to acknowledge Raymond Hsu for his valuable feedback 764 on local HA assignment and Wolfgang Fritsche for his thorough review. 765 Finally, we would like to Domagoj Premec for his review comments. 767 We would like to thank Alper Yegin, Robert Marks, David Frascone for 768 their comments at the second WGLC. 770 11. References 772 11.1. Normative References 774 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 775 IPv6", RFC 3775, June 2004. 777 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 778 Levels", BCP 14, RFC 2119, March 1997. 780 [3] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 781 Network Access Server Application", RFC 4005, August 2005. 783 [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 784 Authentication Protocol (EAP) Application", RFC 4072, 785 August 2005. 787 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 788 "Diameter Base Protocol", RFC 3588, September 2003. 790 [6] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 791 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 792 August 2005. 794 11.2. Informative References 796 [7] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 797 Bootstrapping in Split Scenario", RFC 5026, October 2007. 799 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 800 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 802 [9] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 803 Lopez, "AAA Goals for Mobile IPv6", 804 draft-ietf-mext-aaa-ha-goals-00 (work in progress), 805 December 2007. 807 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 808 RFC 3753, June 2004. 810 [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 811 Integrated Scenario", 812 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 813 progress), July 2007. 815 Authors' Addresses 817 Jouni Korhonen 818 TeliaSonera 819 Teollisuuskatu 13 820 Sonera FIN-00051 821 Finland 823 Email: jouni.korhonen@teliasonera.com 824 Julien Bournelle 825 Orange Labs 826 38-4O rue du general Leclerc 827 Issy-Les-Moulineaux 92794 828 France 830 Email: julien.bournelle@orange-ftgroup.com 832 Hannes Tschofenig 833 Nokia Siemens Networks 834 Linnoitustie 6 835 Espoo 02600 836 Finland 838 Phone: +358 (50) 4871445 839 Email: Hannes.Tschofenig@nsn.com 840 URI: http://www.tschofenig.com 842 Charles E. Perkins 844 Phone: +1-650-496-4402 845 Email: charliep@computer.org 847 Kuntal Chowdhury 848 Starent Networks 849 30 International Place 850 Tewksbury MA 01876 851 US 853 Phone: +1 214 550 1416 854 Email: kchowdhury@starentnetworks.com 856 Full Copyright Statement 858 Copyright (C) The IETF Trust (2008). 860 This document is subject to the rights, licenses and restrictions 861 contained in BCP 78, and except as set forth therein, the authors 862 retain all their rights. 864 This document and the information contained herein are provided on an 865 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 866 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 867 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 868 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 869 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 872 Intellectual Property 874 The IETF takes no position regarding the validity or scope of any 875 Intellectual Property Rights or other rights that might be claimed to 876 pertain to the implementation or use of the technology described in 877 this document or the extent to which any license under such rights 878 might or might not be available; nor does it represent that it has 879 made any independent effort to identify any such rights. Information 880 on the procedures with respect to rights in RFC documents can be 881 found in BCP 78 and BCP 79. 883 Copies of IPR disclosures made to the IETF Secretariat and any 884 assurances of licenses to be made available, or the result of an 885 attempt made to obtain a general license or permission for the use of 886 such proprietary rights by implementers or users of this 887 specification can be obtained from the IETF on-line IPR repository at 888 http://www.ietf.org/ipr. 890 The IETF invites any interested party to bring to its attention any 891 copyrights, patents or patent applications, or other proprietary 892 rights that may cover technology that may be required to implement 893 this standard. Please address the information to the IETF at 894 ietf-ipr@ietf.org. 896 Acknowledgment 898 Funding for the RFC Editor function is provided by the IETF 899 Administrative Support Activity (IASA).