idnits 2.17.1 draft-ietf-dime-mip6-integrated-09.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 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. 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 (May 26, 2008) is 5807 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 630 ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3588 (ref. '4') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (ref. '6') (Obsoleted by RFC 7155) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: November 27, 2008 H. Tschofenig 7 Nokia Siemens Networks 8 C. Perkins 10 K. Chowdhury 11 Starent Networks 12 May 26, 2008 14 Diameter Mobile IPv6: Support for Network Access Server to Diameter 15 Server Interaction 16 draft-ietf-dime-mip6-integrated-09.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 November 27, 2008. 43 Abstract 45 A Mobile IPv6 node requires a home agent address, a home address, and 46 a security association with its home agent before it can start 47 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 48 parameters are statically configured. Mobile IPv6 bootstrapping work 49 aims to make this information dynamically available to the Mobile 50 Node. An important aspect of the Mobile IPv6 bootstrapping solution 51 is to support interworking with existing authentication, 52 authorization and accounting infrastructure. This document describes 53 the MIPv6 bootstrapping using the Diameter Network Access Server 54 (NAS) to home Authentication, Authorization and Accounting server 55 (HAAA) interface. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Commands, AVPs and Advertising Application Support . . . . . . 6 63 4.1. Advertising Application Support . . . . . . . . . . . . . 6 64 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 7 66 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 7 67 4.5. Attribute Value Pair Definitions . . . . . . . . . . . . . 8 68 4.5.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 8 69 4.5.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 9 70 4.5.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 9 71 4.5.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 9 72 4.5.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 73 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 11 75 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 12 76 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 12 77 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14 80 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Intellectual Property and Copyright Statements . . . . . . . . . . 18 89 1. Introduction 91 The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) 92 to perform registration with a home agent (HA) with information about 93 its current point of attachment (care-of address). The HA creates 94 and maintains binding between the MN's Home Address and the MN's 95 Care-of Address. 97 In order to register with a HA, the MN needs to know some information 98 such as the Home Link prefix, the HA address, the Home Address(es), 99 the Home Link prefix length and security association related 100 information. 102 The aforementioned information may be statically configured. 103 However, static provisioning becomes an administrative burden for an 104 operator. Moreover, it does not address load balancing, failover, 105 opportunistic home link assignment and assignment of local HAs in 106 close proximity to the MN. Also the ability to react to sudden 107 environmental or topological changes is minimal. Static provisioning 108 may not be desirable, in light of these limitations. 110 Dynamic assignment of MIPv6 home registration information is a 111 desirable feature for ease of deployment and network maintenance. 112 For this purpose, the AAA infrastructure, which is used for access 113 authentication, can be leveraged to assign some or all of the 114 necessary parameters. The Diameter server in Access Service 115 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 116 return these parameters to the AAA client. Regarding the 117 bootstrapping procedures, the AAA client might either be the NAS, in 118 case of the integrated scenario, or the HA, in case of the split 119 scenario [7]. The terms integrated and split are described in the 120 terminology section and were introduced in [8] and [9]. 122 2. Terminology and Abbreviations 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC2119 [2]. 128 General mobility terminology can be found in [10]. The following 129 additional terms, as defined in [8], are used in this document: 131 Access Service Authorizer (ASA): 133 A network operator that authenticates a MN and establishes the 134 MN's authorization to receive Internet service. 136 Access Service Provider (ASP): 138 A network operator that provides direct IP packet forwarding to 139 and from the MN. 141 Mobility Service Authorizer (MSA): 143 A service provider that authorizes MIPv6 service. 145 Mobility Service Provider (MSP): 147 A service provider that provides MIPv6 service. In order to 148 obtain such service, the MN must be authenticated and authorized 149 to obtain the MIPv6 service. 151 Split scenario: 153 A scenario where the mobility service and the network access 154 service are authorized by different entities. 156 Integrated Scenario: 158 A scenario where the mobility service and the network access 159 service are authorized by the same entity. 161 Network Access Server (NAS): 163 A device that provides an access service for a user to a network. 165 Home AAA (HAAA): 167 An authentication, authorization and accounting server located in 168 user's home network i.e., in the home realm. 170 Local AAA (LAAA): 172 An authentication, authorization and accounting proxy located in 173 the local (ASP) network. 175 Visited AAA (VAAA): 177 An authentication, authorization and accounting proxy located in a 178 visited network i.e., in the visited realm. In a roaming case, 179 the local Diameter proxy has the VAAA role. 181 3. Overview 183 This document addresses the authentication, authorization and 184 accounting functionality required for the MIPv6 bootstrapping 185 solutions outlined in [8] and focuses on the Diameter based AAA 186 functionality for the NAS to HAAA communication. 188 In the integrated scenario MIPv6 bootstrapping is provided as part of 189 the network access authentication procedure. Figure 1 shows the 190 participating entities. 192 +---------------------------+ +-----------------+ 193 |Access Service Provider | |ASA/MSA/(MSP) | 194 |(Mobility Service Provider)| | | 195 | | | | 196 | +--------+ | | +--------+ | 197 | |Local | Diameter | | |Home | | 198 | |Diameter|<---------------------->|Diameter| | 199 | |Proxy | (*) | | |Server | | 200 | +--------+ | | +--------+ | 201 | ^ ^ | | ^ | 202 | | | | | |(+) | 203 | | | | | | | 204 | Diameter | | v | 205 | | |(+) +-------+ | | +-------+ | 206 | | | |Home | | | |Home | | 207 | | +-------->|Agent | | | |Agent | | 208 | (*)| |in ASP | | | |in MSP | | 209 | v +-------+ | | +-------+ | 210 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 211 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 212 |Node |------------|Diameter |---|Server | | 213 | | PANA,... | |Client |(+)| | | 214 +-------+ DHCP | +-----------+ +-------+ | 215 (+) +---------------------------+ 217 Legend: 218 (*): Functionality in scope of this specification 219 (+): Extensions described in other documents. 221 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 223 In a typical MIPv6 access scenario, a MN is attached to an ASP's 224 network. During the network attachment procedure, the MN interacts 225 with the NAS/Diameter client. Subsequently, the NAS/Diameter client 226 interacts with the Diameter server over the NAS to HAAA interface. 228 When the Diameter server performs the authentication and 229 authorization for the network access it also determines whether the 230 user is authorized to the MIPv6 service. Based on the MIPv6 service 231 authorization and user's policy profile, the Diameter server may 232 return several MIPv6 bootstrapping related parameters to the NAS. 233 The NAS to HAAA interface described in this document is not tied to 234 DHCPv6 as the only mechanism to convey MIPv6 related configuration 235 parameters from the NAS/Diameter client to the mobile node. 237 4. Commands, AVPs and Advertising Application Support 239 4.1. Advertising Application Support 241 This document does not define a new application. On the other hand 242 it defines a number of MIPv6 bootstrapping NAS to HAAA interface 243 (integrated scenario) related AVPs. These AVPs can be used with 244 present and future Diameter applications, where permitted by the 245 command ABNF. The examples using existing applications and their 246 commands in the following sections are for informational purposes 247 only. The examples in this document reuse EAP [3] application and 248 its respective commands. 250 4.2. Command Codes 252 This document shows re-use of the Diameter EAP application commands 253 [3] as an example of the MIPv6 bootstrapping NAS to HAAA interface. 254 Refer to Section 6 and Figure 6 for AVP occurance definitions in 255 Diameter commands. The following commands are used to carry MIPv6 256 related bootstrapping AVPs: 258 Command-Name Abbrev. Code Reference Application 260 Diameter-EAP-Request DER 268 RFC 4072 EAP 261 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 263 Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 265 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 266 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 267 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 268 (ACR), and Accounting-Answer (ACA) commands are used together with 269 the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules 270 defined in RFC 3588 [4] and the rules for the specific Diameter 271 application the AVPs defined in this document are used with. The 272 accounting commands use the Application Identifier value of 3 273 (Diameter Base Accounting); the others use 0 (Diameter Common 274 Messages). 276 All request messages SHOULD contain the User-Name AVP containing the 277 identity of the MN in NAI format. It is out of scope how the NAS 278 finds out the MN identity. The NAS could, for example, use the MN 279 identity provided by the network access authentication mechanism. 281 4.3. Diameter-EAP-Request (DER) 283 The Diameter-EAP-Request (DER) message [3], indicated by the Command- 284 Code field set to 268 and the 'R' bit set in the Command Flags field, 285 is sent by the NAS to the Diameter server to initiate a network 286 access authentication and authorization procedure. The DER message 287 format is the same as defined in [3]. The message MAY include 288 optional MIPv6 bootstrapping AVPs: 290 ::= < Diameter Header: 268, REQ, PXY > 291 < Session-Id > 292 { Auth-Application-Id } 293 { Origin-Host } 294 { Origin-Realm } 295 { Destination-Realm } 296 { Auth-Request-Type } 298 * [ MIP6-Agent-Info ] 299 * [ MIP6-Home-Link-Prefix ] 300 [ MIP6-Feature-Vector ] 302 [ User-Name ] 303 [ Destination-Host ] 304 ... 305 * [ AVP ] 307 4.4. Diameter-EAP-Answer (DEA) 309 The Diameter-EAP-Answer (DEA) message defined in [3], indicated by 310 the Command-Code field set to 268 and 'R' bit cleared in the Command 311 Flags field, is sent in response to the Diameter-EAP-Request message 312 (DER). If the network access authentication procedure was successful 313 then the response MAY include any set of bootstrapping AVPs. 315 The DEA message format is the same as defined in [3] with an addition 316 of optional MIPv6 bootstrapping AVPs: 318 ::= < Diameter Header: 268, PXY > 319 < Session-Id > 320 { Auth-Application-Id } 321 { Auth-Request-Type } 322 { Result-Code } 323 { Origin-Host } 324 { Origin-Realm } 326 * [ MIP6-Agent-Info ] 327 * [ MIP6-Home-Link-Prefix ] 328 [ MIP6-Feature-Vector ] 330 [ User-Name ] 331 ... 332 * [ AVP ] 334 4.5. Attribute Value Pair Definitions 336 4.5.1. MIP6-Agent-Info 338 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 339 contains necessary information to assign a HA to the MN. When the 340 MIP6-Agent-Info AVP is present in a message, it MUST contain either 341 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 342 both AVPs. The grouped AVP has the following grammar: 344 ::= < AVP Header: TBD > 345 [ MIP-Home-Agent-Address ] 346 [ MIP-Home-Agent-Host ] 347 * [ AVP ] 349 If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are 350 present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD 351 have a precedence over the MIP-Home-Agent-Host. The reason for this 352 recommendation is that the MIP-Home-Agent-Address points to a 353 specific home agent, where as the MIP-Home-Agent-Host may point to a 354 group of HAs located at within the same realm. A Diameter client or 355 an agent may use the MIP-Home-Agent-Host AVP, for instance, to find 356 out the realm where the HA is located. 358 This AVP MAY also be attached by the NAS or by intermediating 359 Diameter proxies in a request message when sent to the Diameter 360 server as a hint of a locally assigned HA. This AVP MAY also be 361 attached by the intermediating Diameter proxies in a reply message 362 from the Diameter server, if locally assigned HAs are authorized by 363 the Diameter server. 365 4.5.2. MIP-Home-Agent-Address AVP 367 The MIP-Home-Agent-Address AVP (AVP Code 334 [5]) is of type Address 368 and contains the HA address. The Diameter server MAY decide to 369 assign a HA to the MN that is in close proximity to the point of 370 attachment (e.g., determined by the NAS-Identifier AVP). There may 371 be other reasons for dynamically assigning HAs to the MN, for example 372 to share the traffic load. 374 4.5.3. MIP-Home-Agent-Host AVP 376 The MIP-Home-Agent-Host AVP (AVP Code 348 [5]) is of type Grouped and 377 contains the identity of the assigned HA. Both the Destination-Realm 378 and the Destination-Host AVP of the HA are included in the grouped 379 AVP. The usage of this AVP is equivalent to the MIP-Home-Agent- 380 Address AVP but offers an additional level of indirection by using 381 the DNS infrastructure. 383 Depending on the actual deployment and DNS configuration the 384 Destination-Host AVP MAY represent one or more home agents. It is 385 RECOMMENDED that the Destination-Host AVP identifies exactly one HA. 387 4.5.4. MIP6-Home-Link-Prefix AVP 389 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 390 and contains the Mobile IPv6 home network prefix information in 391 network byte order. The home network prefix MUST be encoded as the 392 8-bit prefix length information followed by the 128-bit field for the 393 available home network prefix. 395 4.5.5. MIP6-Feature-Vector AVP 397 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 398 contains a 64 bit flags field of supported capabilities of the NAS/ 399 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 400 MUST be supported, although that does not provide much guidance about 401 specific needs of bootstrapping. 403 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 404 to the Diameter server. For example, the NAS may indicate that a 405 local HA can be provided. Similarly, the Diameter server MAY include 406 this AVP to inform the NAS/ASP about which of the NAS/ASP indicated 407 capabilities are supported or authorized by the ASA/MSA(/MSP). 409 The following capabilities are defined in this document: 411 MIP6_INTEGRATED (0x0000000000000001) 413 When this flag is set by the NAS then it means that the Mobile 414 IPv6 integrated scenario bootstrapping functionality is supported 415 by the NAS. When this flag is set by the Diameter server then the 416 Mobile IPv6 integrated scenario bootstrapping is supported by the 417 Diameter server. 419 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 421 When this flag is set in the request message, a local home agent 422 outside the home realm is requested and may be assigned to the MN. 423 When this flag is set by the Diameter server in the answer 424 message, then the assignment of local HAs is authorized by the 425 Diameter server. 427 A local HA may be assigned by the NAS, LAAA or VAAA depending on 428 the network architecture and the deployment. 430 The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT 431 capability and the MIP-Agent-Info AVP are used to assign HAs, either 432 a local HA (L-HA) or a home network HA (H-HA). Below is an example 433 of a request message combinations as seen by the HAAA: 435 LOCAL-bit HA-Info Meaning 437 0 - ASP or [LV]AAA is not able to assign a L-HA 438 0 L-HA Same as above. HA-Info must be ignored 439 1 - ASP or [LV]AAA can/wishes to assign a L-HA 440 1 L-HA Same as above but ASP or [LV]AAA also 441 provides a hint of the assigned L-HA 443 Then the same as above for an answer message combinations as seen by 444 the NAS: 446 LOCAL-bit HA-Info Meaning 448 0 - No HA allowed -> no mobility 449 0 H-HA L-HA is not allowed. HAAA assigns a H-HA 450 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 451 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 452 1 H-HA L-HA is allowed. HAAA also assigns a HA 453 1 H-HA L-HA is allowed. HAAA assigns a H-HA and 454 + L-HA [LV]AAA also assigns also a L-HA 456 5. Examples 458 5.1. Home Agent Assignment by the NAS 460 In this scenario we consider the case where the NAS wishes to 461 allocate a local HA to the MN. The NAS will also inform the Diameter 462 server about the HA address it has assigned to the visiting MN (e.g., 463 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 464 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 465 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 466 Agent-Address AVP with the address of the proposed HA. 468 Diameter 469 NAS Server 470 | | 471 | Diameter-EAP-Request | 472 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 473 | | MIP6_INTEGRATED) | 474 | MIP6-Agent-Info{ | 475 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 476 | } | 477 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 478 | EAP-Payload(EAP Start) | 479 |---------------------------------------------------------------->| 480 | | 481 | | 482 : ...more EAP Request/Response pairs... : 483 | | 484 | | 485 | Diameter-EAP-Answer | 486 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 487 | | MIP6_INTEGRATED) | 488 | Result-Code=DIAMETER_SUCCESS | 489 | EAP-Payload(EAP Success) | 490 | EAP-Master-Session-Key | 491 | (authorization AVPs) | 492 | ... | 493 |<----------------------------------------------------------------| 494 | | 496 Figure 3: Home Agent Assignment by NAS 498 Depending on the Diameter server configuration and user's 499 subscription profile, the Diameter server either accepts or rejects 500 the proposal of locally HA allocated by the NAS will be used. In our 501 example, the Diameter server accepts the proposal and the the MIP6- 502 Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together 503 with the MIP6_INTEGRATED flag) is set and returned to the NAS. 505 5.2. Home Agent Assignment by the Diameter Server 507 In this scenario we consider the case where the NAS supports the 508 Diameter MIPv6 integrated scenario as defined in this document but 509 does not offer local HA assignment. Hence, the MIP6-Feature-Vector 510 AVP only has the MIP6_INTEGRATED flag set. The Diameter server 511 allocates a HA to the mobile node and conveys the address in the MIP- 512 Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info 513 AVP. Additionally, the MIP6-Feature-Vector AVP has the 514 MIP6_INTEGRATED flag set. 516 Diameter 517 NAS Server 518 | | 519 | Diameter-EAP-Request | 520 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 521 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 522 | EAP-Payload(EAP Start) | 523 |---------------------------------------------------------------->| 524 | | 525 | | 526 : ...more EAP Request/Response pairs... : 527 | | 528 | | 529 | Diameter-EAP-Answer | 530 | MIP6-Agent-Info{ | 531 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64) | 532 | } | 533 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 534 | Result-Code=DIAMETER_SUCCESS | 535 | EAP-Payload(EAP Success) | 536 | EAP-Master-Session-Key | 537 | (authorization AVPs) | 538 | ... | 539 |<----------------------------------------------------------------| 540 | | 542 Figure 4: Home Agent Assignment by Diameter Server 544 5.3. Home Agent Assignment by NAS or Diameter Server 546 This section shows a message flow for the MIPv6 integrated scenario 547 bootstrapping where the NAS informs the Diameter server that it is 548 able to locally assign a HA to the MN. The Diameter server is able 549 to provide a HA to the MN but also authorizes the assignment of local 550 HA. The Diameter server then replies to the NAS with HA related 551 bootstrapping information. 553 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 554 server assigned HA to the MN is, in this example, based on the local 555 ASP policy. 557 Diameter 558 NAS Server 559 | | 560 | Diameter-EAP-Request | 561 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 562 | | MIP6_INTEGRATED) | 563 | MIP6-Agent-Info{ | 564 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 565 | } | 566 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 567 | EAP-Payload(EAP Start) | 568 |---------------------------------------------------------------->| 569 | | 570 | | 571 : ...more EAP Request/Response pairs... : 572 | | 573 | | 574 | Diameter-EAP-Answer | 575 | MIP6-Agent-Info{ | 576 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} | 577 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 578 | | MIP6_INTEGRATED) | 579 | Result-Code=DIAMETER_SUCCESS | 580 | EAP-Payload(EAP Success) | 581 | EAP-Master-Session-Key | 582 | (authorization AVPs) | 583 | ... | 584 |<----------------------------------------------------------------| 585 | | 587 Figure 5: Home Agent Assignment by NAS or Diameter Server 589 If the Diameter server does not accept locally assigned HA, the 590 Diameter returns the MIP6-Feature-Vector AVP with 591 LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it plans to 592 allocate for the MN. 594 6. AVP Occurrence Tables 596 The following table lists the additional MIPv6 bootstrapping NAS to 597 HAAA interface AVPs that may be present in any Diameter application 598 request and answer commands, where permitted by the command ABNF. 600 +-----------+ 601 | Command | 602 |-----+-----+ 603 Attribute Name | Req | Ans | 604 -------------------------------|-----+-----| 605 MIP6-Agent-Info | 0+ | 0+ | 606 MIP6-Feature-Vector | 0-1 | 0-1 | 607 MIP6-Home-Link-Prefix | 0+ | 0+ | 608 +-----+-----+ 610 Figure 6: Generic Request and Answer Commands AVP Table 612 7. IANA Considerations 614 7.1. Registration of new AVPs 616 This specification defines the following new AVPs: 618 MIP6-Agent-Info is set to TBD 619 MIP6-Feature-Vector is set to TBD 620 MIP6-Home-Link-Prefix is set to TBD 622 7.2. New Registry: Mobility Capability 624 IANA is requested to create a new registry for the Mobility 625 Capability as described in Section 4.5.5. 627 Token | Value | Description 628 ----------------------------------+----------------------+------------ 629 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 630 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 631 Available for Assignment via IANA | 2^x | 633 Allocation rule: Only numeric values that are 2^x (power of two) are 634 allowed based on the allocation policy described below. 636 Following the policies outlined in [1] new values with a description 637 of their semantic for usage with the MIP6-Feature-Vector AVP together 638 with a Token will be assigned after Expert Review initiated by the 639 O&M Area Directors in consultation with the DIME working group chairs 640 or the working group chairs of a designated successor working group. 641 Updates can be provided based on expert approval only. A designated 642 expert will be appointed by the O&M Area Directors. No mechanism to 643 mark entries as "deprecated" is envisioned. Based on expert approval 644 it is possible to delete entries from the registry. 646 8. Security Considerations 648 The security considerations for the Diameter interaction required to 649 accomplish the integrated scenario are described in [11]. 650 Additionally, the security considerations of the Diameter base 651 protocol [4], Diameter NASREQ application [6] / Diameter EAP [3] 652 application (with respect to network access authentication and the 653 transport of keying material) are applicable to this document. This 654 document does not introduce new security vulnerabilities. 656 9. Acknowledgements 658 This document is heavily based on the ongoing work for RADIUS MIPv6 659 interaction. Hence, credits go to respective authors for their work 660 with draft-ietf-mip6-radius. Furthermore, the author would like to 661 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 662 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 663 in context of MIPv6 Diameter interworking. Their work influenced 664 this document. Jouni Korhonen would like to thank Academy of Finland 665 and TEKES MERCoNe Project for providing funding to work on this 666 document. Julien Bournelle would like to thank GET/INT since he 667 began to work on this document while he was in their employ. Authors 668 would also like to acknowledge Raymond Hsu for his valuable feedback 669 on local HA assignment and Wolfgang Fritsche for his thorough review. 670 Finally, we would like to Domagoj Premec for his review comments. 672 We would like to thank Alper Yegin, Robert Marks, David Frascone for 673 their comments at the second WGLC. 675 10. References 677 10.1. Normative References 679 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 680 IPv6", RFC 3775, June 2004. 682 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 683 Levels", BCP 14, RFC 2119, March 1997. 685 [3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 686 Authentication Protocol (EAP) Application", RFC 4072, 687 August 2005. 689 [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 690 "Diameter Base Protocol", RFC 3588, September 2003. 692 [5] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 693 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 694 August 2005. 696 [6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 697 Network Access Server Application", RFC 4005, August 2005. 699 10.2. Informative References 701 [7] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 702 Bootstrapping in Split Scenario", RFC 5026, October 2007. 704 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 705 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 707 [9] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 708 Lopez, "AAA Goals for Mobile IPv6", 709 draft-ietf-mext-aaa-ha-goals-01 (work in progress), May 2008. 711 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 712 RFC 3753, June 2004. 714 [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 715 Integrated Scenario", 716 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 717 progress), April 2008. 719 Authors' Addresses 721 Jouni Korhonen 722 TeliaSonera 723 Teollisuuskatu 13 724 Sonera FIN-00051 725 Finland 727 Email: jouni.korhonen@teliasonera.com 728 Julien Bournelle 729 Orange Labs 730 38-4O rue du general Leclerc 731 Issy-Les-Moulineaux 92794 732 France 734 Email: julien.bournelle@orange-ftgroup.com 736 Hannes Tschofenig 737 Nokia Siemens Networks 738 Linnoitustie 6 739 Espoo 02600 740 Finland 742 Phone: +358 (50) 4871445 743 Email: Hannes.Tschofenig@nsn.com 744 URI: http://www.tschofenig.priv.at 746 Charles E. Perkins 748 Phone: +1-650-496-4402 749 Email: charliep@computer.org 751 Kuntal Chowdhury 752 Starent Networks 753 30 International Place 754 Tewksbury MA 01876 755 US 757 Phone: +1 214 550 1416 758 Email: kchowdhury@starentnetworks.com 760 Full Copyright Statement 762 Copyright (C) The IETF Trust (2008). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Intellectual Property 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org.