idnits 2.17.1 draft-ietf-dime-mip6-integrated-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 (January 9, 2009) is 5557 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) == Missing Reference: 'RFC TBD' is mentioned on line 605, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) Nokia Siemens Networks 4 Internet-Draft J. Bournelle 5 Intended status: Standards Track Orange Labs 6 Expires: July 13, 2009 H. Tschofenig 7 Nokia Siemens Networks 8 C. Perkins 9 WiChorus 10 K. Chowdhury 11 Starent Networks 12 January 9, 2009 14 Diameter Mobile IPv6: Support for Network Access Server to Diameter 15 Server Interaction 16 draft-ietf-dime-mip6-integrated-12.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 13, 2009. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Abstract 55 A Mobile IPv6 node requires a home agent address, a home address, and 56 a security association with its home agent before it can start 57 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 58 parameters are statically configured. Mobile IPv6 bootstrapping work 59 aims to make this information dynamically available to the Mobile 60 Node. An important aspect of the Mobile IPv6 bootstrapping solution 61 is to support interworking with existing authentication, 62 authorization and accounting infrastructure. This document describes 63 MIPv6 bootstrapping using the Diameter Network Access Server to home 64 Authentication, Authorization and Accounting server interface. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Commands, Attribute Value Pairs and Advertising 72 Application Support . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Advertising Application Support . . . . . . . . . . . . . 7 74 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7 75 4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7 76 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8 77 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8 78 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 9 79 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 80 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 11 82 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 12 83 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 13 84 6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 14 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14 87 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 The Mobile IPv6 (MIPv6) specification [RFC3775] requires a Mobile 98 Node (MN) to perform registration with a home agent (HA) with 99 information about its current point of attachment (care-of address). 100 The HA creates and maintains the binding between the MN's Home 101 Address and the MN's Care-of Address. 103 In order to register with a HA, the MN needs to know some information 104 such as the Home Link prefix, the HA address, the Home Address(es), 105 the Home Link prefix length and security association related 106 information. 108 The aforementioned information may be statically configured. 109 However, static provisioning becomes an administrative burden for an 110 operator. Moreover, it does not address load balancing, failover, 111 opportunistic home link assignment or assignment of local HAs in 112 close proximity to the MN. Also the ability to react to sudden 113 environmental or topological changes is minimal. Static provisioning 114 may not be desirable, in light of these limitations. 116 Dynamic assignment of MIPv6 home registration information is a 117 desirable feature for ease of deployment and network maintenance. 118 For this purpose, the AAA infrastructure, which is used for access 119 authentication, can be leveraged to assign some or all of the 120 necessary parameters. The Diameter server in the Access Service 121 Provider's (ASP) or in the Mobility Service Provider's (MSP) network 122 may return these parameters to the AAA client. Regarding the 123 bootstrapping procedures, the AAA client might either be the Network 124 Access Server, in case of the integrated scenario, or the HA, in case 125 of the split scenario [RFC5026]. The terms integrated and split are 126 described in the terminology section and were introduced in [RFC4640] 127 and [I-D.ietf-mext-aaa-ha-goals]. 129 2. Terminology and Abbreviations 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC2119 [RFC2119]. 135 General mobility terminology can be found in [RFC3753]. The 136 following additional terms below are either borrowed from 137 [RFC4640][RFC5026] or introduced 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 (see Figure 1). 189 3. Overview 191 This document addresses the Authentication, Authorization and 192 Accounting (AAA) functionality required for the MIPv6 bootstrapping 193 solutions outlined in [RFC4640] and focuses on the Diameter based AAA 194 functionality for the NAS to home AAA server (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 +-------+ IKEv2, | +-----------+ +-------+ | 223 DHCP,... +---------------------------+ 224 (+) 226 Legend: 227 (*): Functionality in scope of this specification 228 (+): Extensions described in other documents. 230 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 232 In a typical MIPv6 access scenario, a MN is attached to an ASP's 233 network. During the network attachment procedure, the MN interacts 234 with the NAS/Diameter client. Subsequently, the NAS/Diameter client 235 interacts with the Diameter server over the NAS to HAAA interface. 237 When the Diameter server performs the authentication and 238 authorization for the network access it also determines whether the 239 user is authorized to the MIPv6 service. Based on the MIPv6 service 240 authorization and user's policy profile, the Diameter server may 241 return several MIPv6 bootstrapping related parameters to the NAS. 242 The NAS to HAAA interface described in this document is not tied to 243 DHCPv6 as the only mechanism to convey MIPv6 related configuration 244 parameters from the NAS/Diameter client to the mobile node. 246 While this specification addresses the bootstrapping of MIPv6 HA 247 information and possibly the assignment of the home link prefix, it 248 does not address how the Security Association (SA) between the MN and 249 the HA for MIPv6 purposes is created. The creation or the use of the 250 SA between the MN and the HA takes places after the procedures 251 described in this specification, and therefore are out of scope. 253 4. Commands, Attribute Value Pairs and Advertising Application Support 255 4.1. Advertising Application Support 257 This document does not define a new application. On the other hand 258 it defines a number of AVPs used in the interface between NAS to HAAA 259 for the integrated scenario of MIPv6 bootstrapping. These AVPs can 260 be used with any present and future Diameter applications, where 261 permitted by the command ABNF. The examples using existing 262 applications and their commands in the following sections are for 263 informational purposes only. The examples in this document reuse the 264 EAP [RFC4072] application and its respective commands. 266 4.2. Attribute Value Pair Definitions 268 4.2.1. MIP6-Agent-Info 270 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 271 contains necessary information to assign a HA to the MN. When the 272 MIP6-Agent-Info AVP is present in a message, it MUST contain either 273 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 274 both AVPs. The grouped AVP has the following ABNF (as defined in 275 [RFC3588]): 277 ::= < AVP Header: TBD > 278 *2[ MIP-Home-Agent-Address ] 279 [ MIP-Home-Agent-Host ] 280 [ MIP6-Home-Link-Prefix ] 281 * [ AVP ] 283 If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are 284 present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD 285 have a precedence over the MIP-Home-Agent-Host. The reason for this 286 recommendation is that the MIP-Home-Agent-Address points to a 287 specific home agent, where as the MIP-Home-Agent-Host may point to a 288 group of HAs located at within the same realm. A Diameter client or 289 an agent may use the MIP-Home-Agent-Host AVP, for instance, to find 290 out the realm where the HA is located. 292 The ABNF allows returning up to two MIPv6 HA addresses. This is an 293 useful feature for deployments where the HA has both IPv6 and IPv4 294 addresses, and particularly addresses Dual Stack Mobile IPv6 295 (DSMIPv6) deployment scenarios [I-D.ietf-mext-nemo-v4traversal]. 297 This AVP MAY also be attached by the NAS or by intermediating 298 Diameter proxies in a request message when sent to the Diameter 299 server as a hint of a locally assigned HA. This AVP MAY also be 300 attached by the intermediating Diameter proxies in a reply message 301 from the Diameter server, if locally assigned HAs are authorized by 302 the Diameter server. There MAY be multiple instances of the MIP6- 303 Agent-Info AVPs in Diameter messages, for example in cases where the 304 NAS receives a HA information from MN's home network and a locally 305 allocated HA information from the visited network. See Section 4.2.5 306 for further discussion on possible scenarios. 308 4.2.2. MIP-Home-Agent-Address AVP 310 The MIP-Home-Agent-Address AVP (AVP Code 334 [RFC4004]) is of type 311 Address and contains IPv6 or IPv4 address of the MIPv6 HA. The 312 Diameter server MAY decide to assign a HA to the MN that is in close 313 proximity to the point of attachment (e.g., determined by the NAS- 314 Identifier AVP). There may be other reasons for dynamically 315 assigning HAs to the MN, for example to share the traffic load. 317 4.2.3. MIP-Home-Agent-Host AVP 319 The MIP-Home-Agent-Host AVP (AVP Code 348 [RFC4004]) is of type 320 Grouped and contains the identity of the assigned MIPv6 HA. Both the 321 Destination-Realm and the Destination-Host AVPs of the HA are 322 included in the grouped AVP. The usage of the MIP-Home-Agent-Host 323 AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an 324 additional level of indirection by using the DNS infrastructure. The 325 Destination-Host AVP is used to identify a HA and the Destination- 326 Realm AVP is used to identify the realm where the HA is located. 328 Depending on the actual deployment and DNS configuration the 329 Destination-Host AVP MAY represent one or more home agents. It is 330 RECOMMENDED that the Destination-Host AVP identifies exactly one HA. 332 It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included 333 in the MIP6-Agent-Info AVP. In this way the HA can be associated 334 with the corresponding realm of the Diameter entity that added the 335 MIP6-Agent-Info AVP using the Destination-Realm AVP included in the 336 MIP-Home-Agent-Host AVP. 338 4.2.4. MIP6-Home-Link-Prefix AVP 340 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 341 and contains the Mobile IPv6 home network prefix information in a 342 network byte order. The home network prefix MUST be encoded as the 343 8-bit prefix length information (one octet) followed by the 128-bit 344 field (16 octets) for the available home network prefix. The 345 trailing bits of the IPv6 prefix after the prefix length bits MUST be 346 set to zero (e.g., if the prefix length is 60, then the remaining 68 347 bits MUST be set to zero). 349 The HAAA MAY act as a central entity managing prefixes for MNs. In 350 this case, the HAAA returns to the NAS the prefix allocated to the 351 MN. The NAS/ASP delivers then the home link prefix to the MN using 352 e.g. mechanisms described in 353 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The NAS/ASP MAY 354 propose to the HAAA a specific prefix to allocate to the MN by 355 including the MIP6-Home-Link-Prefix AVP in the request message. 356 However, the HAAA MAY override the prefix allocation hint proposed by 357 the NAS/ASP and return a different prefix in the response message. 359 4.2.5. MIP6-Feature-Vector AVP 361 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 362 contains a 64 bit flags field of supported capabilities of the NAS/ 363 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 364 MUST be supported, although that does not provide much guidance about 365 specific needs of bootstrapping. 367 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 368 to the Diameter server. For example, the NAS may indicate that a 369 local HA can be provided. Similarly, the Diameter server MAY include 370 this AVP to inform the NAS/ASP about which of the NAS/ASP indicated 371 capabilities are supported or authorized by the ASA/MSA(/MSP). 373 The following capabilities are defined in this document: 375 MIP6_INTEGRATED (0x0000000000000001) 377 When this flag is set by the NAS then it means that the Mobile 378 IPv6 integrated scenario bootstrapping functionality is supported 379 by the NAS. When this flag is set by the Diameter server then the 380 Mobile IPv6 integrated scenario bootstrapping is supported by the 381 Diameter server. 383 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 385 When this flag is set in the request message, a local home agent 386 outside the home realm is requested and may be assigned to the MN. 387 When this flag is set by the Diameter server in the answer 388 message, then the assignment of local HAs is authorized by the 389 Diameter server. 391 A local HA may be assigned by the NAS, LAAA or VAAA depending on 392 the network architecture and the deployment. 394 The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT 395 (referred as LOCAL-bit in the examples) capability and the MIP-Agent- 396 Info AVP (referred as HA-Info in the examples) are used to assign 397 HAs, either a local HA (L-HA) or a home network HA (H-HA). Below is 398 an example of a request message combinations as seen by the HAAA: 400 LOCAL-bit HA-Info Meaning 402 0 - ASP or [LV]AAA is not able to assign a L-HA 403 0 L-HA Same as above. HA-Info must be ignored 404 1 - ASP or [LV]AAA can/wishes to assign a L-HA 405 1 L-HA Same as above but ASP or [LV]AAA also 406 provides a hint of the assigned L-HA 408 Then the same as above for an answer message combinations as seen by 409 the NAS: 411 LOCAL-bit HA-Info Meaning 413 0 - No HA assignment allowed for HAAA or [LV]AAA 414 0 H-HA L-HA is not allowed. HAAA assigns a H-HA 415 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 416 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 417 1 H-HA L-HA is allowed. HAAA also assigns a HA 418 1 H-HA L-HA is allowed. HAAA assigns a H-HA and 419 + L-HA [LV]AAA also assigns also a L-HA 421 A NAS should expect to possible receive multiple of the MIP6-Agent- 422 Info AVPs. 424 5. Examples 426 5.1. Home Agent Assignment by the NAS 428 In this scenario we consider the case where the NAS wishes to 429 allocate a local HA to the MN. The NAS will also inform the Diameter 430 server about the HA address it has assigned to the visiting MN (e.g., 431 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 432 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 433 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 434 Agent-Address AVP with the address of the proposed HA. 436 Diameter 437 NAS/VAAA Server 438 | | 439 | Diameter-EAP-Request | 440 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 441 | | MIP6_INTEGRATED) | 442 | MIP6-Agent-Info{ | 443 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 444 | } | 445 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 446 | EAP-Payload(EAP Start) | 447 |---------------------------------------------------------------->| 448 | | 449 | | 450 : ...more EAP Request/Response pairs... : 451 | | 452 | | 453 | Diameter-EAP-Answer | 454 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 455 | | MIP6_INTEGRATED) | 456 | Result-Code=DIAMETER_SUCCESS | 457 | EAP-Payload(EAP Success) | 458 | EAP-Master-Session-Key | 459 | (authorization AVPs) | 460 | ... | 461 |<----------------------------------------------------------------| 462 | | 464 Figure 2: Home Agent Assignment by NAS 466 Depending on the Diameter server configuration and user's 467 subscription profile, the Diameter server either accepts or rejects 468 the local HA allocated by the NAS. In our example, the Diameter 469 server accepts the proposal and the the MIP6-Feature-Vector AVP with 470 LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED 471 flag) is set and returned to the NAS. 473 5.2. Home Agent Assignment by the Diameter Server 475 In this scenario we consider the case where the NAS supports the 476 Diameter MIPv6 integrated scenario as defined in this document but 477 does not offer local HA assignment. Hence, the MIP6-Feature-Vector 478 AVP only has the MIP6_INTEGRATED flag set. The Diameter server 479 allocates a HA to the mobile node and conveys the address in the MIP- 480 Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info 481 AVP. Additionally, the MIP6-Feature-Vector AVP has the 482 MIP6_INTEGRATED flag set. 484 Diameter 485 NAS Server 486 | | 487 | Diameter-EAP-Request | 488 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 489 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 490 | EAP-Payload(EAP Start) | 491 |---------------------------------------------------------------->| 492 | | 493 | | 494 : ...more EAP Request/Response pairs... : 495 | | 496 | | 497 | Diameter-EAP-Answer | 498 | MIP6-Agent-Info{ | 499 | MIP-Home-Agent-Address(2001:db8:6000:302::1) | 500 | } | 501 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 502 | Result-Code=DIAMETER_SUCCESS | 503 | EAP-Payload(EAP Success) | 504 | EAP-Master-Session-Key | 505 | (authorization AVPs) | 506 | ... | 507 |<----------------------------------------------------------------| 508 | | 510 Figure 3: Home Agent Assignment by Diameter Server 512 5.3. Home Agent Assignment by NAS or Diameter Server 514 This section shows another message flow for the MIPv6 integrated 515 scenario bootstrapping where the NAS informs the Diameter server that 516 it is able to locally assign a HA to the MN. The Diameter server is 517 able to provide a HA to the MN but also authorizes the assignment of 518 local HA. The Diameter server then replies to the NAS with HA 519 related bootstrapping information. 521 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 522 server assigned HA to the MN is, in this example, based on the local 523 ASP policy. 525 Diameter 526 NAS/VAAA Server 527 | | 528 | Diameter-EAP-Request | 529 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 530 | | MIP6_INTEGRATED) | 531 | MIP6-Agent-Info{ | 532 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 533 | } | 534 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 535 | EAP-Payload(EAP Start) | 536 |---------------------------------------------------------------->| 537 | | 538 | | 539 : ...more EAP Request/Response pairs... : 540 | | 541 | | 542 | Diameter-EAP-Answer | 543 | MIP6-Agent-Info{ | 544 | MIP-Home-Agent-Address(2001:db8:6000:302::1)} | 545 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 546 | | MIP6_INTEGRATED) | 547 | Result-Code=DIAMETER_SUCCESS | 548 | EAP-Payload(EAP Success) | 549 | EAP-Master-Session-Key | 550 | (authorization AVPs) | 551 | ... | 552 |<----------------------------------------------------------------| 553 | | 555 Figure 4: Home Agent Assignment by NAS or Diameter Server 557 If the Diameter server does not allow the MN to use a locally 558 assigned HA, the Diameter returns the MIP6-Feature-Vector AVP with 559 the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it allocated 560 to the MN. 562 6. Attribute Value Pair Occurrence Tables 564 Figure 5 lists the MIPv6 bootstrapping NAS to HAAA interface AVPs, 565 along with a specification determining how many of each new AVP may 566 be included in a Diameter command. They may be present in any 567 Diameter application request and answer commands, where permitted by 568 the command ABNF. 570 +-----------+ 571 | Command | 572 |-----+-----+ 573 Attribute Name | Req | Ans | 574 -------------------------------|-----+-----| 575 MIP6-Agent-Info | 0+ | 0+ | 576 MIP6-Feature-Vector | 0-1 | 0-1 | 577 +-----+-----+ 579 Figure 5: Generic Request and Answer Commands AVP Table 581 7. IANA Considerations 583 7.1. Registration of new AVPs 585 This specification defines the following new AVPs to be allocated 586 from a normal Diameter AVP Code space (values >= 256): 588 MIP6-Agent-Info is set to TBD 590 The following new AVPs are to be allocated from RADIUS Type Code 591 [RFC2865] space so that they are RADIUS backward compatible (AVP Code 592 values between 0-255): 594 MIP6-Feature-Vector is set to TBD 595 MIP6-Home-Link-Prefix is set to TBD 597 7.2. New Registry: Mobility Capability 599 IANA is requested to create a new registry for the Mobility 600 Capability as described in Section 4.2.5. 602 Token | Value | Description 603 ----------------------------------+---------------------+------------ 604 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 605 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 606 Available for Assignment via IANA | 2^x | 608 Allocation rule: Only numeric values that are 2^x (power of two, 609 where x >= 2) are allowed based on the allocation policy described 610 below. 612 Following the example policies described in [RFC5226] new values for 613 the MIP6-Feature-Vector AVP will be assigned based on the 614 "Specification Required" policy. No mechanism to mark entries as 615 "deprecated" is envisioned. 617 8. Security Considerations 619 The security considerations for the Diameter interaction required to 620 accomplish the integrated scenario are described in 621 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. Additionally, the 622 security considerations of the Diameter base protocol [RFC3588], 623 Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] 624 application (with respect to network access authentication and the 625 transport of keying material) are applicable to this document. 626 Developers should insure that special attention is paid to 627 configuring the security associations protecting the messages that 628 enables the global positioning and allocation of home agents, for 629 instance, as outlined in section 5. 631 Furthermore, the Diameter messages may be transported between the NAS 632 and the Diameter server via one or more AAA brokers or Diameter 633 agents (such as proxies). In this case the NAS to the Diameter 634 server AAA communication rely on the security properties of the 635 intermediate AAA brokers and Diameter agents. 637 9. Acknowledgements 639 This document is heavily based on the ongoing work for RADIUS MIPv6 640 interaction. Hence, credits go to respective authors for their work 641 with draft-ietf-mip6-radius. Furthermore, the author would like to 642 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 643 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 644 in context of MIPv6 Diameter interworking. Their work influenced 645 this document. Jouni Korhonen would like to thank Academy of Finland 646 and TEKES MERCoNe Project for providing funding to work on this 647 document while he was with TeliaSonera. Julien Bournelle would like 648 to thank GET/INT since he began to work on this document while he was 649 in their employ. Authors would also like to acknowledge Raymond Hsu 650 for his valuable feedback on local HA assignment and Wolfgang 651 Fritsche for his thorough review. Finally, we would like to Domagoj 652 Premec for his review comments. 654 We would like to thank Alper Yegin, Robert Marks, David Frascone for 655 their comments at the second WGLC. 657 10. References 659 10.1. Normative References 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 665 "Remote Authentication Dial In User Service (RADIUS)", 666 RFC 2865, June 2000. 668 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 669 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 671 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 672 in IPv6", RFC 3775, June 2004. 674 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 675 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 676 August 2005. 678 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 679 "Diameter Network Access Server Application", RFC 4005, 680 August 2005. 682 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 683 Authentication Protocol (EAP) Application", RFC 4072, 684 August 2005. 686 10.2. Informative References 688 [I-D.ietf-mext-aaa-ha-goals] 689 Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., 690 and R. Lopez, "AAA Goals for Mobile IPv6", 691 draft-ietf-mext-aaa-ha-goals-01 (work in progress), 692 May 2008. 694 [I-D.ietf-mext-nemo-v4traversal] 695 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 696 Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 697 (work in progress), December 2008. 699 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 700 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 701 Integrated Scenario", 702 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 703 progress), April 2008. 705 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 706 RFC 3753, June 2004. 708 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 709 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 710 September 2006. 712 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 713 Bootstrapping in Split Scenario", RFC 5026, October 2007. 715 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 716 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 717 May 2008. 719 Authors' Addresses 721 Jouni Korhonen (editor) 722 Nokia Siemens Networks 723 Linnoitustie 6 724 Espoo FIN-02600 725 Finland 727 Email: jouni.nospam@gmail.com 729 Julien Bournelle 730 Orange Labs 731 38-4O rue du general Leclerc 732 Issy-Les-Moulineaux 92794 733 France 735 Email: julien.bournelle@orange-ftgroup.com 736 Hannes Tschofenig 737 Nokia Siemens Networks 738 Linnoitustie 6 739 Espoo 02600 740 Finland 742 Email: Hannes.Tschofenig@nsn.com 743 URI: http://www.tschofenig.priv.at 745 Charles E. Perkins 746 WiChorus 748 Email: charliep@wichorus.com 750 Kuntal Chowdhury 751 Starent Networks 752 30 International Place 753 Tewksbury MA 01876 754 US 756 Email: kchowdhury@starentnetworks.com