idnits 2.17.1 draft-ietf-dime-mip6-integrated-11.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 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 784. 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 (November 18, 2008) is 5637 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 592, 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-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) 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, Ed. 3 Extensions (DIME) TeliaSonera 4 Internet-Draft J. Bournelle 5 Intended status: Standards Track Orange Labs 6 Expires: May 22, 2009 H. Tschofenig 7 Nokia Siemens Networks 8 C. Perkins 9 WiChorus 10 K. Chowdhury 11 Starent Networks 12 November 18, 2008 14 Diameter Mobile IPv6: Support for Network Access Server to Diameter 15 Server Interaction 16 draft-ietf-dime-mip6-integrated-11.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 May 22, 2009. 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 MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to 54 home Authentication, Authorization and Accounting server (HAAA) 55 interface. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Commands, Attribute Value Pairs and Advertising 63 Application Support . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Advertising Application Support . . . . . . . . . . . . . 7 65 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 7 66 4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 7 67 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 8 68 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 8 69 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 8 70 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 10 73 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 11 74 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 12 75 6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 14 78 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . . . 19 87 1. Introduction 89 The Mobile IPv6 (MIPv6) specification [RFC3775] requires a Mobile 90 Node (MN) to perform registration with a home agent (HA) with 91 information about its current point of attachment (care-of address). 92 The HA creates and maintains the binding between the MN's Home 93 Address and the MN's Care-of Address. 95 In order to register with a HA, the MN needs to know some information 96 such as the Home Link prefix, the HA address, the Home Address(es), 97 the Home Link prefix length and security association related 98 information. 100 The aforementioned information may be statically configured. 101 However, static provisioning becomes an administrative burden for an 102 operator. Moreover, it does not address load balancing, failover, 103 opportunistic home link assignment or assignment of local HAs in 104 close proximity to the MN. Also the ability to react to sudden 105 environmental or topological changes is minimal. Static provisioning 106 may not be desirable, in light of these limitations. 108 Dynamic assignment of MIPv6 home registration information is a 109 desirable feature for ease of deployment and network maintenance. 110 For this purpose, the AAA infrastructure, which is used for access 111 authentication, can be leveraged to assign some or all of the 112 necessary parameters. The Diameter server in the Access Service 113 Provider's (ASP) or in the Mobility Service Provider's (MSP) network 114 may return these parameters to the AAA client. Regarding the 115 bootstrapping procedures, the AAA client might either be the NAS, in 116 case of the integrated scenario, or the HA, in case of the split 117 scenario [RFC5026]. The terms integrated and split are described in 118 the terminology section and were introduced in [RFC4640] and 119 [I-D.ietf-mext-aaa-ha-goals]. 121 2. Terminology and Abbreviations 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC2119 [RFC2119]. 127 General mobility terminology can be found in [RFC3753]. The 128 following additional terms below are either borrowed from 129 [RFC4640][RFC5026] or introduced 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 (see Figure 1). 181 3. Overview 183 This document addresses the Authentication, Authorization and 184 Accounting (AAA) functionality required for the MIPv6 bootstrapping 185 solutions outlined in [RFC4640] 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 +-------+ IKEv2, | +-----------+ +-------+ | 215 DHCP,... +---------------------------+ 216 (+) 218 Legend: 219 (*): Functionality in scope of this specification 220 (+): Extensions described in other documents. 222 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 224 In a typical MIPv6 access scenario, a MN is attached to an ASP's 225 network. During the network attachment procedure, the MN interacts 226 with the NAS/Diameter client. Subsequently, the NAS/Diameter client 227 interacts with the Diameter server over the NAS to HAAA interface. 229 When the Diameter server performs the authentication and 230 authorization for the network access it also determines whether the 231 user is authorized to the MIPv6 service. Based on the MIPv6 service 232 authorization and user's policy profile, the Diameter server may 233 return several MIPv6 bootstrapping related parameters to the NAS. 234 The NAS to HAAA interface described in this document is not tied to 235 DHCPv6 as the only mechanism to convey MIPv6 related configuration 236 parameters from the NAS/Diameter client to the mobile node. 238 While this specification addresses the bootstrapping of MIPv6 HA 239 information and possibly the assignment of the home link prefix, it 240 does not address how the Security Association (SA) between the MN and 241 the HA for MIPv6 purposes is created. The creation or the use of the 242 SA between the MN and the HA takes places after the procedures 243 described in this specification, and therefore are out of scope. 245 4. Commands, Attribute Value Pairs and Advertising Application Support 247 4.1. Advertising Application Support 249 This document does not define a new application. On the other hand 250 it defines a number of AVPs used in the interface between NAS to HAAA 251 for the integrated scenario of MIPv6 bootstrapping. These AVPs can 252 be used with any present and future Diameter applications, where 253 permitted by the command ABNF. The examples using existing 254 applications and their commands in the following sections are for 255 informational purposes only. The examples in this document reuse the 256 EAP [RFC4072] application and its respective commands. 258 4.2. Attribute Value Pair Definitions 260 4.2.1. MIP6-Agent-Info 262 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 263 contains necessary information to assign a HA to the MN. When the 264 MIP6-Agent-Info AVP is present in a message, it MUST contain either 265 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 266 both AVPs. The grouped AVP has the following ABNF (as defined in 267 [RFC3588]): 269 ::= < AVP Header: TBD > 270 *2[ MIP-Home-Agent-Address ] 271 [ MIP-Home-Agent-Host ] 272 * [ AVP ] 274 If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are 275 present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD 276 have a precedence over the MIP-Home-Agent-Host. The reason for this 277 recommendation is that the MIP-Home-Agent-Address points to a 278 specific home agent, where as the MIP-Home-Agent-Host may point to a 279 group of HAs located at within the same realm. A Diameter client or 280 an agent may use the MIP-Home-Agent-Host AVP, for instance, to find 281 out the realm where the HA is located. 283 The ABNF allows returning up to two MIPv6 HA addresses. This is an 284 useful feature for deployments where the HA has both IPv6 and IPv4 285 addresses, and particularly addresses Dual Stack Mobile IPv6 286 (DSMIPv6) deployment scenarios [I-D.ietf-mext-nemo-v4traversal]. 288 This AVP MAY also be attached by the NAS or by intermediating 289 Diameter proxies in a request message when sent to the Diameter 290 server as a hint of a locally assigned HA. This AVP MAY also be 291 attached by the intermediating Diameter proxies in a reply message 292 from the Diameter server, if locally assigned HAs are authorized by 293 the Diameter server. There MAY be multiple instances of the MIP6- 294 Agent-Info AVPs in Diameter messages, for example in cases where the 295 NAS receives a HA information from MN's home network and a locally 296 allocated HA information from the visited network. See Section 4.2.5 297 for further discussion on possible scenarios. 299 4.2.2. MIP-Home-Agent-Address AVP 301 The MIP-Home-Agent-Address AVP (AVP Code 334 [RFC4004]) is of type 302 Address and contains IPv6 or IPv4 address of the MIPv6 HA. The 303 Diameter server MAY decide to assign a HA to the MN that is in close 304 proximity to the point of attachment (e.g., determined by the NAS- 305 Identifier AVP). There may be other reasons for dynamically 306 assigning HAs to the MN, for example to share the traffic load. 308 4.2.3. MIP-Home-Agent-Host AVP 310 The MIP-Home-Agent-Host AVP (AVP Code 348 [RFC4004]) is of type 311 Grouped and contains the identity of the assigned MIPv6 HA. Both the 312 Destination-Realm and the Destination-Host AVPs of the HA are 313 included in the grouped AVP. The usage of the MIP-Home-Agent-Host 314 AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an 315 additional level of indirection by using the DNS infrastructure. The 316 Destination-Host AVP is used to identify a HA and the Destination- 317 Realm AVP is used to identify the realm where the HA is located. 319 Depending on the actual deployment and DNS configuration the 320 Destination-Host AVP MAY represent one or more home agents. It is 321 RECOMMENDED that the Destination-Host AVP identifies exactly one HA. 323 It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included 324 in the MIP6-Agent-Info AVP. In this way the HA IP address can be 325 associated with the corresponding realm the HA belongs to using the 326 Destination-Realm AVP included in the MIP-Home-Agent-Host AVP. 328 4.2.4. MIP6-Home-Link-Prefix AVP 330 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 331 and contains the Mobile IPv6 home network prefix information in a 332 network byte order. The home network prefix MUST be encoded as the 333 8-bit prefix length information (one octet) followed by the 128-bit 334 field (16 octets) for the available home network prefix. The 335 trailing bits of the IPv6 prefix after the prefix length bits MUST be 336 set to zero (e.g., if the prefix length is 60, then the remaining 68 337 bits MUST be set to zero). 339 The HAAA MAY act as a central entity managing prefixes for MNs. In 340 this case, the HAAA returns the prefix allocated for the MN and 341 returns it the NAS. The NAS/ASP uses then, for example, mechanisms 342 described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver 343 the home link prefix to the MN. 345 4.2.5. MIP6-Feature-Vector AVP 347 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 348 contains a 64 bit flags field of supported capabilities of the NAS/ 349 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 350 MUST be supported, although that does not provide much guidance about 351 specific needs of bootstrapping. 353 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 354 to the Diameter server. For example, the NAS may indicate that a 355 local HA can be provided. Similarly, the Diameter server MAY include 356 this AVP to inform the NAS/ASP about which of the NAS/ASP indicated 357 capabilities are supported or authorized by the ASA/MSA(/MSP). 359 The following capabilities are defined in this document: 361 MIP6_INTEGRATED (0x0000000000000001) 363 When this flag is set by the NAS then it means that the Mobile 364 IPv6 integrated scenario bootstrapping functionality is supported 365 by the NAS. When this flag is set by the Diameter server then the 366 Mobile IPv6 integrated scenario bootstrapping is supported by the 367 Diameter server. 369 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 371 When this flag is set in the request message, a local home agent 372 outside the home realm is requested and may be assigned to the MN. 373 When this flag is set by the Diameter server in the answer 374 message, then the assignment of local HAs is authorized by the 375 Diameter server. 377 A local HA may be assigned by the NAS, LAAA or VAAA depending on 378 the network architecture and the deployment. 380 The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT 381 (referred as LOCAL-bit in the examples) capability and the MIP-Agent- 382 Info AVP (referred as HA-Info in the examples) are used to assign 383 HAs, either a local HA (L-HA) or a home network HA (H-HA). Below is 384 an example of a request message combinations as seen by the HAAA: 386 LOCAL-bit HA-Info Meaning 388 0 - ASP or [LV]AAA is not able to assign a L-HA 389 0 L-HA Same as above. HA-Info must be ignored 390 1 - ASP or [LV]AAA can/wishes to assign a L-HA 391 1 L-HA Same as above but ASP or [LV]AAA also 392 provides a hint of the assigned L-HA 394 Then the same as above for an answer message combinations as seen by 395 the NAS: 397 LOCAL-bit HA-Info Meaning 399 0 - No HA assignment allowed for HAAA or [LV]AAA 400 0 H-HA L-HA is not allowed. HAAA assigns a H-HA 401 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 402 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 403 1 H-HA L-HA is allowed. HAAA also assigns a HA 404 1 H-HA L-HA is allowed. HAAA assigns a H-HA and 405 + L-HA [LV]AAA also assigns also a L-HA 407 A NAS should expect to possible receive multiple of the MIP6-Agent- 408 Info AVPs. 410 5. Examples 412 5.1. Home Agent Assignment by the NAS 414 In this scenario we consider the case where the NAS wishes to 415 allocate a local HA to the MN. The NAS will also inform the Diameter 416 server about the HA address it has assigned to the visiting MN (e.g., 417 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 418 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 419 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 420 Agent-Address AVP with the address of the proposed HA. 422 Diameter 423 NAS/VAAA Server 424 | | 425 | Diameter-EAP-Request | 426 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 427 | | MIP6_INTEGRATED) | 428 | MIP6-Agent-Info{ | 429 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 430 | } | 431 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 432 | EAP-Payload(EAP Start) | 433 |---------------------------------------------------------------->| 434 | | 435 | | 436 : ...more EAP Request/Response pairs... : 437 | | 438 | | 439 | Diameter-EAP-Answer | 440 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 441 | | MIP6_INTEGRATED) | 442 | Result-Code=DIAMETER_SUCCESS | 443 | EAP-Payload(EAP Success) | 444 | EAP-Master-Session-Key | 445 | (authorization AVPs) | 446 | ... | 447 |<----------------------------------------------------------------| 448 | | 450 Figure 2: Home Agent Assignment by NAS 452 Depending on the Diameter server configuration and user's 453 subscription profile, the Diameter server either accepts or rejects 454 the local HA allocated by the NAS. In our example, the Diameter 455 server accepts the proposal and the the MIP6-Feature-Vector AVP with 456 LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED 457 flag) is set and returned to the NAS. 459 5.2. Home Agent Assignment by the Diameter Server 461 In this scenario we consider the case where the NAS supports the 462 Diameter MIPv6 integrated scenario as defined in this document but 463 does not offer local HA assignment. Hence, the MIP6-Feature-Vector 464 AVP only has the MIP6_INTEGRATED flag set. The Diameter server 465 allocates a HA to the mobile node and conveys the address in the MIP- 466 Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info 467 AVP. Additionally, the MIP6-Feature-Vector AVP has the 468 MIP6_INTEGRATED flag set. 470 Diameter 471 NAS Server 472 | | 473 | Diameter-EAP-Request | 474 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 475 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 476 | EAP-Payload(EAP Start) | 477 |---------------------------------------------------------------->| 478 | | 479 | | 480 : ...more EAP Request/Response pairs... : 481 | | 482 | | 483 | Diameter-EAP-Answer | 484 | MIP6-Agent-Info{ | 485 | MIP-Home-Agent-Address(2001:db8:6000:302::1) | 486 | } | 487 | MIP6-Feature-Vector=(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 Diameter Server 498 5.3. Home Agent Assignment by NAS or Diameter Server 500 This section shows another message flow for the MIPv6 integrated 501 scenario bootstrapping where the NAS informs the Diameter server that 502 it is able to locally assign a HA to the MN. The Diameter server is 503 able to provide a HA to the MN but also authorizes the assignment of 504 local HA. The Diameter server then replies to the NAS with HA 505 related bootstrapping information. 507 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 508 server assigned HA to the MN is, in this example, based on the local 509 ASP policy. 511 Diameter 512 NAS/VAAA Server 513 | | 514 | Diameter-EAP-Request | 515 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 516 | | MIP6_INTEGRATED) | 517 | MIP6-Agent-Info{ | 518 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 519 | } | 520 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 521 | EAP-Payload(EAP Start) | 522 |---------------------------------------------------------------->| 523 | | 524 | | 525 : ...more EAP Request/Response pairs... : 526 | | 527 | | 528 | Diameter-EAP-Answer | 529 | MIP6-Agent-Info{ | 530 | MIP-Home-Agent-Address(2001:db8:6000:302::1)} | 531 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 532 | | MIP6_INTEGRATED) | 533 | Result-Code=DIAMETER_SUCCESS | 534 | EAP-Payload(EAP Success) | 535 | EAP-Master-Session-Key | 536 | (authorization AVPs) | 537 | ... | 538 |<----------------------------------------------------------------| 539 | | 541 Figure 4: Home Agent Assignment by NAS or Diameter Server 543 If the Diameter server does not allow the MN to use a locally 544 assigned HA, the Diameter returns the MIP6-Feature-Vector AVP with 545 the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it allocated 546 to the MN. 548 6. Attribute Value Pair Occurrence Tables 550 Figure 5 lists the MIPv6 bootstrapping NAS to HAAA interface AVPs, 551 along with a specification determining how many of each new AVP may 552 be included in a Diameter command. They may be present in any 553 Diameter application request and answer commands, where permitted by 554 the command ABNF. 556 +-----------+ 557 | Command | 558 |-----+-----+ 559 Attribute Name | Req | Ans | 560 -------------------------------|-----+-----| 561 MIP6-Agent-Info | 0+ | 0+ | 562 MIP6-Feature-Vector | 0-1 | 0-1 | 563 MIP6-Home-Link-Prefix | 0+ | 0+ | 564 +-----+-----+ 566 Figure 5: Generic Request and Answer Commands AVP Table 568 7. IANA Considerations 570 7.1. Registration of new AVPs 572 This specification defines the following new AVPs to be allocated 573 from a normal Diameter AVP Code space (values >= 256): 575 MIP6-Agent-Info is set to TBD 577 The following new AVPs are to be allocated from RADIUS Type Code 578 [RFC2685] space so that they are RADIUS backward compatible (AVP Code 579 values between 0-255): 581 MIP6-Feature-Vector is set to TBD 582 MIP6-Home-Link-Prefix is set to TBD 584 7.2. New Registry: Mobility Capability 586 IANA is requested to create a new registry for the Mobility 587 Capability as described in Section 4.2.5. 589 Token | Value | Description 590 ----------------------------------+----------------------+------------ 591 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 592 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 593 Available for Assignment via IANA | 2^x | 595 Allocation rule: Only numeric values that are 2^x (power of two, 596 where x >= 2) are allowed based on the allocation policy described 597 below. 599 Following the example policies described in [RFC5226] new values for 600 the MIP6-Feature-Vector AVP will be assigned based on the 601 "Specification Required" policy. No mechanism to mark entries as 602 "deprecated" is envisioned. 604 8. Security Considerations 606 The security considerations for the Diameter interaction required to 607 accomplish the integrated scenario are described in 608 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. Additionally, the 609 security considerations of the Diameter base protocol [RFC3588], 610 Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] 611 application (with respect to network access authentication and the 612 transport of keying material) are applicable to this document. 613 Developers should insure that special attention is paid to 614 configuring the security associations protecting the messages that 615 enables the global positioning and allocation of home agents, for 616 instance, as outlined in section 5. 618 Furthermore, the Diameter messages may be transported between the NAS 619 and the RADIUS server via one or more AAA brokers or Diameter agents 620 (such as proxies). In this case the NAS to the Diameter server AAA 621 communication rely on the security properties of the intermediate AAA 622 brokers and Diameter agents. 624 9. Acknowledgements 626 This document is heavily based on the ongoing work for RADIUS MIPv6 627 interaction. Hence, credits go to respective authors for their work 628 with draft-ietf-mip6-radius. Furthermore, the author would like to 629 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 630 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 631 in context of MIPv6 Diameter interworking. Their work influenced 632 this document. Jouni Korhonen would like to thank Academy of Finland 633 and TEKES MERCoNe Project for providing funding to work on this 634 document. Julien Bournelle would like to thank GET/INT since he 635 began to work on this document while he was in their employ. Authors 636 would also like to acknowledge Raymond Hsu for his valuable feedback 637 on local HA assignment and Wolfgang Fritsche for his thorough review. 638 Finally, we would like to Domagoj Premec for his review comments. 640 We would like to thank Alper Yegin, Robert Marks, David Frascone for 641 their comments at the second WGLC. 643 10. References 645 10.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks 651 Identifier", RFC 2685, September 1999. 653 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 654 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 656 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 657 in IPv6", RFC 3775, June 2004. 659 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 660 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 661 August 2005. 663 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 664 "Diameter Network Access Server Application", RFC 4005, 665 August 2005. 667 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 668 Authentication Protocol (EAP) Application", RFC 4072, 669 August 2005. 671 10.2. Informative References 673 [I-D.ietf-mext-aaa-ha-goals] 674 Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., 675 and R. Lopez, "AAA Goals for Mobile IPv6", 676 draft-ietf-mext-aaa-ha-goals-01 (work in progress), 677 May 2008. 679 [I-D.ietf-mext-nemo-v4traversal] 680 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 681 Routers", draft-ietf-mext-nemo-v4traversal-06 (work in 682 progress), November 2008. 684 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 685 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 686 Integrated Scenario", 687 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 688 progress), April 2008. 690 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 691 RFC 3753, June 2004. 693 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 694 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 695 September 2006. 697 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 698 Bootstrapping in Split Scenario", RFC 5026, October 2007. 700 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 701 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 702 May 2008. 704 Authors' Addresses 706 Jouni Korhonen (editor) 707 TeliaSonera 708 Teollisuuskatu 13 709 Sonera FIN-00051 710 Finland 712 Email: jouni.nospam@gmail.com 714 Julien Bournelle 715 Orange Labs 716 38-4O rue du general Leclerc 717 Issy-Les-Moulineaux 92794 718 France 720 Email: julien.bournelle@orange-ftgroup.com 722 Hannes Tschofenig 723 Nokia Siemens Networks 724 Linnoitustie 6 725 Espoo 02600 726 Finland 728 Phone: +358 (50) 4871445 729 Email: Hannes.Tschofenig@nsn.com 730 URI: http://www.tschofenig.priv.at 732 Charles E. Perkins 733 WiChorus 735 Phone: +1-650-496-4402 736 Email: charliep@wichorus.com 737 Kuntal Chowdhury 738 Starent Networks 739 30 International Place 740 Tewksbury MA 01876 741 US 743 Phone: +1 214 550 1416 744 Email: kchowdhury@starentnetworks.com 746 Full Copyright Statement 748 Copyright (C) The IETF Trust (2008). 750 This document is subject to the rights, licenses and restrictions 751 contained in BCP 78, and except as set forth therein, the authors 752 retain all their rights. 754 This document and the information contained herein are provided on an 755 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 756 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 757 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 758 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 759 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 762 Intellectual Property 764 The IETF takes no position regarding the validity or scope of any 765 Intellectual Property Rights or other rights that might be claimed to 766 pertain to the implementation or use of the technology described in 767 this document or the extent to which any license under such rights 768 might or might not be available; nor does it represent that it has 769 made any independent effort to identify any such rights. Information 770 on the procedures with respect to rights in RFC documents can be 771 found in BCP 78 and BCP 79. 773 Copies of IPR disclosures made to the IETF Secretariat and any 774 assurances of licenses to be made available, or the result of an 775 attempt made to obtain a general license or permission for the use of 776 such proprietary rights by implementers or users of this 777 specification can be obtained from the IETF on-line IPR repository at 778 http://www.ietf.org/ipr. 780 The IETF invites any interested party to bring to its attention any 781 copyrights, patents or patent applications, or other proprietary 782 rights that may cover technology that may be required to implement 783 this standard. Please address the information to the IETF at 784 ietf-ipr@ietf.org.