idnits 2.17.1 draft-ietf-dime-mip6-integrated-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. 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 (September 5, 2008) is 5704 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 559 ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (ref. '6') (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '11') (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 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: March 9, 2009 H. Tschofenig 7 Nokia Siemens Networks 8 C. Perkins 9 WiChorus 10 K. Chowdhury 11 Starent Networks 12 September 5, 2008 14 Diameter Mobile IPv6: Support for Network Access Server to Diameter 15 Server Interaction 16 draft-ietf-dime-mip6-integrated-10.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on March 9, 2009. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 A Mobile IPv6 node requires a home agent address, a home address, and 50 a security association with its home agent before it can start 51 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 52 parameters are statically configured. Mobile IPv6 bootstrapping work 53 aims to make this information dynamically available to the Mobile 54 Node. An important aspect of the Mobile IPv6 bootstrapping solution 55 is to support interworking with existing authentication, 56 authorization and accounting infrastructure. This document describes 57 MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to 58 home Authentication, Authorization and Accounting server (HAAA) 59 interface. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Commands, Attribute Value Pairs and Advertising 67 Application Support . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Advertising Application Support . . . . . . . . . . . . . 6 69 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 6 70 4.2.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 6 71 4.2.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 7 72 4.2.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 7 73 4.2.4. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 7 74 4.2.5. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 8 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 9 77 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 10 78 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 11 79 6. Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 13 82 7.2. New Registry: Mobility Capability . . . . . . . . . . . . 13 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 Intellectual Property and Copyright Statements . . . . . . . . . . 17 91 1. Introduction 93 The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) 94 to perform registration with a home agent (HA) with information about 95 its current point of attachment (care-of address). The HA creates 96 and maintains the binding between the MN's Home Address and the MN's 97 Care-of Address. 99 In order to register with a HA, the MN needs to know some information 100 such as the Home Link prefix, the HA address, the Home Address(es), 101 the Home Link prefix length and security association related 102 information. 104 The aforementioned information may be statically configured. 105 However, static provisioning becomes an administrative burden for an 106 operator. Moreover, it does not address load balancing, failover, 107 opportunistic home link assignment or assignment of local HAs in 108 close proximity to the MN. Also the ability to react to sudden 109 environmental or topological changes is minimal. Static provisioning 110 may not be desirable, in light of these limitations. 112 Dynamic assignment of MIPv6 home registration information is a 113 desirable feature for ease of deployment and network maintenance. 114 For this purpose, the AAA infrastructure, which is used for access 115 authentication, can be leveraged to assign some or all of the 116 necessary parameters. The Diameter server in the Access Service 117 Provider's (ASP) or in the Mobility Service Provider's (MSP) network 118 may return these parameters to the AAA client. Regarding the 119 bootstrapping procedures, the AAA client might either be the NAS, in 120 case of the integrated scenario, or the HA, in case of the split 121 scenario [7]. The terms integrated and split are described in the 122 terminology section and were introduced in [8] and [9]. 124 2. Terminology and Abbreviations 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [2]. 130 General mobility terminology can be found in [10]. The following 131 additional terms below are either borrowed from [8][7] or introduced 132 in this document: 134 Access Service Authorizer (ASA): 136 A network operator that authenticates a MN and establishes the 137 MN's authorization to receive Internet service. 139 Access Service Provider (ASP): 141 A network operator that provides direct IP packet forwarding to 142 and from the MN. 144 Mobility Service Authorizer (MSA): 146 A service provider that authorizes MIPv6 service. 148 Mobility Service Provider (MSP): 150 A service provider that provides MIPv6 service. In order to 151 obtain such service, the MN must be authenticated and authorized 152 to obtain the MIPv6 service. 154 Split scenario: 156 A scenario where the mobility service and the network access 157 service are authorized by different entities. 159 Integrated Scenario: 161 A scenario where the mobility service and the network access 162 service are authorized by the same entity. 164 Network Access Server (NAS): 166 A device that provides an access service for a user to a network. 168 Home AAA (HAAA): 170 An authentication, authorization and accounting server located in 171 user's home network i.e., in the home realm. 173 Local AAA (LAAA): 175 An authentication, authorization and accounting proxy located in 176 the local (ASP) network. 178 Visited AAA (VAAA): 180 An authentication, authorization and accounting proxy located in a 181 visited network i.e., in the visited realm. In a roaming case, 182 the local Diameter proxy has the VAAA role (see Figure 1). 184 3. Overview 186 This document addresses the authentication, authorization and 187 accounting functionality required for the MIPv6 bootstrapping 188 solutions outlined in [8] and focuses on the Diameter based AAA 189 functionality for the NAS to HAAA communication. 191 In the integrated scenario MIPv6 bootstrapping is provided as part of 192 the network access authentication procedure. Figure 1 shows the 193 participating entities. 195 +---------------------------+ +-----------------+ 196 |Access Service Provider | |ASA/MSA/(MSP) | 197 |(Mobility Service Provider)| | | 198 | | | | 199 | +--------+ | | +--------+ | 200 | |Local | Diameter | | |Home | | 201 | |Diameter|<---------------------->|Diameter| | 202 | |Proxy | (*) | | |Server | | 203 | +--------+ | | +--------+ | 204 | ^ ^ | | ^ | 205 | | | | | |(+) | 206 | | | | | | | 207 | Diameter | | v | 208 | | |(+) +-------+ | | +-------+ | 209 | | | |Home | | | |Home | | 210 | | +-------->|Agent | | | |Agent | | 211 | (*)| |in ASP | | | |in MSP | | 212 | v +-------+ | | +-------+ | 213 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 214 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 215 |Node |------------|Diameter |---|Server | | 216 | | PANA,... | |Client |(+)| | | 217 +-------+ DHCP | +-----------+ +-------+ | 218 (+) +---------------------------+ 220 Legend: 221 (*): Functionality in scope of this specification 222 (+): Extensions described in other documents. 224 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 226 In a typical MIPv6 access scenario, a MN is attached to an ASP's 227 network. During the network attachment procedure, the MN interacts 228 with the NAS/Diameter client. Subsequently, the NAS/Diameter client 229 interacts with the Diameter server over the NAS to HAAA interface. 231 When the Diameter server performs the authentication and 232 authorization for the network access it also determines whether the 233 user is authorized to the MIPv6 service. Based on the MIPv6 service 234 authorization and user's policy profile, the Diameter server may 235 return several MIPv6 bootstrapping related parameters to the NAS. 236 The NAS to HAAA interface described in this document is not tied to 237 DHCPv6 as the only mechanism to convey MIPv6 related configuration 238 parameters from the NAS/Diameter client to the mobile node. 240 4. Commands, Attribute Value Pairs and Advertising Application Support 242 4.1. Advertising Application Support 244 This document does not define a new application. On the other hand 245 it defines a number of AVPs used in the interface between NAS to HAAA 246 for the integrated scenario of MIPv6 bootstrapping. These AVPs can 247 be used with any present and future Diameter applications, where 248 permitted by the command ABNF. The examples using existing 249 applications and their commands in the following sections are for 250 informational purposes only. The examples in this document reuse the 251 EAP [3] application and its respective commands. 253 4.2. Attribute Value Pair Definitions 255 4.2.1. MIP6-Agent-Info 257 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 258 contains necessary information to assign a HA to the MN. When the 259 MIP6-Agent-Info AVP is present in a message, it MUST contain either 260 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 261 both AVPs. The grouped AVP has the following grammar: 263 ::= < AVP Header: TBD > 264 *2[ MIP-Home-Agent-Address ] 265 [ MIP-Home-Agent-Host ] 266 * [ AVP ] 268 If both MIP-Home-Agent-Address and MIP-Home-Agent-Host APVs are 269 present in the MIP6-Agent-Info, the MIP-Home-Agent-Address SHOULD 270 have a precedence over the MIP-Home-Agent-Host. The reason for this 271 recommendation is that the MIP-Home-Agent-Address points to a 272 specific home agent, where as the MIP-Home-Agent-Host may point to a 273 group of HAs located at within the same realm. A Diameter client or 274 an agent may use the MIP-Home-Agent-Host AVP, for instance, to find 275 out the realm where the HA is located. 277 This AVP MAY also be attached by the NAS or by intermediating 278 Diameter proxies in a request message when sent to the Diameter 279 server as a hint of a locally assigned HA. This AVP MAY also be 280 attached by the intermediating Diameter proxies in a reply message 281 from the Diameter server, if locally assigned HAs are authorized by 282 the Diameter server. 284 4.2.2. MIP-Home-Agent-Address AVP 286 The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address 287 and contains IPv6 or IPv6 address of the HA. The Diameter server MAY 288 decide to assign a HA to the MN that is in close proximity to the 289 point of attachment (e.g., determined by the NAS-Identifier AVP). 290 There may be other reasons for dynamically assigning HAs to the MN, 291 for example to share the traffic load. 293 4.2.3. MIP-Home-Agent-Host AVP 295 The MIP-Home-Agent-Host AVP (AVP Code 348 [4]) is of type Grouped and 296 contains the identity of the assigned HA. Both the Destination-Realm 297 and the Destination-Host AVPs of the HA are included in the grouped 298 AVP. The usage of the MIP-Home-Agent-Host AVP is equivalent to the 299 MIP-Home-Agent-Address AVP but offers an additional level of 300 indirection by using the DNS infrastructure. 302 Depending on the actual deployment and DNS configuration the 303 Destination-Host AVP MAY represent one or more home agents. It is 304 RECOMMENDED that the Destination-Host AVP identifies exactly one HA. 306 It is RECOMMENDED that the MIP-Home-Agent-Host AVP is always included 307 in the MIP6-Agent-Info AVP. In this way the HA address can be 308 associated with the corresponding realm the HA belongs to. 310 4.2.4. MIP6-Home-Link-Prefix AVP 312 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 313 and contains the Mobile IPv6 home network prefix information in 314 network byte order. The home network prefix MUST be encoded as the 315 8-bit prefix length information followed by the 128-bit field for the 316 available home network prefix. 318 4.2.5. MIP6-Feature-Vector AVP 320 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 321 contains a 64 bit flags field of supported capabilities of the NAS/ 322 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 323 MUST be supported, although that does not provide much guidance about 324 specific needs of bootstrapping. 326 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 327 to the Diameter server. For example, the NAS may indicate that a 328 local HA can be provided. Similarly, the Diameter server MAY include 329 this AVP to inform the NAS/ASP about which of the NAS/ASP indicated 330 capabilities are supported or authorized by the ASA/MSA(/MSP). 332 The following capabilities are defined in this document: 334 MIP6_INTEGRATED (0x0000000000000001) 336 When this flag is set by the NAS then it means that the Mobile 337 IPv6 integrated scenario bootstrapping functionality is supported 338 by the NAS. When this flag is set by the Diameter server then the 339 Mobile IPv6 integrated scenario bootstrapping is supported by the 340 Diameter server. 342 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 344 When this flag is set in the request message, a local home agent 345 outside the home realm is requested and may be assigned to the MN. 346 When this flag is set by the Diameter server in the answer 347 message, then the assignment of local HAs is authorized by the 348 Diameter server. 350 A local HA may be assigned by the NAS, LAAA or VAAA depending on 351 the network architecture and the deployment. 353 The following examples show how the LOCAL_HOME_AGENT_ASSIGNMENT 354 (referred as LOCAL-bit in the examples) capability and the MIP-Agent- 355 Info AVP (referred as HA-Info in the examples) are used to assign 356 HAs, either a local HA (L-HA) or a home network HA (H-HA). Below is 357 an example of a request message combinations as seen by the HAAA: 359 LOCAL-bit HA-Info Meaning 361 0 - ASP or [LV]AAA is not able to assign a L-HA 362 0 L-HA Same as above. HA-Info must be ignored 363 1 - ASP or [LV]AAA can/wishes to assign a L-HA 364 1 L-HA Same as above but ASP or [LV]AAA also 365 provides a hint of the assigned L-HA 367 Then the same as above for an answer message combinations as seen by 368 the NAS: 370 LOCAL-bit HA-Info Meaning 372 0 - No HA allowed -> no mobility 373 0 H-HA L-HA is not allowed. HAAA assigns a H-HA 374 1 - L-HA is allowed. No HAAA or [LV]AAA assigned HA 375 1 L-HA L-HA is allowed. [LV]AAA also assigns a L-HA 376 1 H-HA L-HA is allowed. HAAA also assigns a HA 377 1 H-HA L-HA is allowed. HAAA assigns a H-HA and 378 + L-HA [LV]AAA also assigns also a L-HA 380 A NAS should expect to possible receive multiple of the MIP6-Agent- 381 Info AVPs. 383 5. Examples 385 5.1. Home Agent Assignment by the NAS 387 In this scenario we consider the case where the NAS wishes to 388 allocate a local HA to the MN. The NAS will also inform the Diameter 389 server about the HA address it has assigned to the visiting MN (e.g., 390 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 391 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 392 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 393 Agent-Address AVP with the address of the proposed HA. 395 Diameter 396 NAS/VAAA Server 397 | | 398 | Diameter-EAP-Request | 399 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 400 | | MIP6_INTEGRATED) | 401 | MIP6-Agent-Info{ | 402 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 403 | } | 404 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 405 | EAP-Payload(EAP Start) | 406 |---------------------------------------------------------------->| 407 | | 408 | | 409 : ...more EAP Request/Response pairs... : 410 | | 411 | | 412 | Diameter-EAP-Answer | 413 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 414 | | MIP6_INTEGRATED) | 415 | Result-Code=DIAMETER_SUCCESS | 416 | EAP-Payload(EAP Success) | 417 | EAP-Master-Session-Key | 418 | (authorization AVPs) | 419 | ... | 420 |<----------------------------------------------------------------| 421 | | 423 Figure 2: Home Agent Assignment by NAS 425 Depending on the Diameter server configuration and user's 426 subscription profile, the Diameter server either accepts or rejects 427 the local HA allocated by the NAS. In our example, the Diameter 428 server accepts the proposal and the the MIP6-Feature-Vector AVP with 429 LOCAL_HOME_AGENT_ASSIGNMENT flag (together with the MIP6_INTEGRATED 430 flag) is set and returned to the NAS. 432 5.2. Home Agent Assignment by the Diameter Server 434 In this scenario we consider the case where the NAS supports the 435 Diameter MIPv6 integrated scenario as defined in this document but 436 does not offer local HA assignment. Hence, the MIP6-Feature-Vector 437 AVP only has the MIP6_INTEGRATED flag set. The Diameter server 438 allocates a HA to the mobile node and conveys the address in the MIP- 439 Home-Agent-Address AVP that is encapsulated in the MIP6-Agent-Info 440 AVP. Additionally, the MIP6-Feature-Vector AVP has the 441 MIP6_INTEGRATED flag set. 443 Diameter 444 NAS Server 445 | | 446 | Diameter-EAP-Request | 447 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 448 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 449 | EAP-Payload(EAP Start) | 450 |---------------------------------------------------------------->| 451 | | 452 | | 453 : ...more EAP Request/Response pairs... : 454 | | 455 | | 456 | Diameter-EAP-Answer | 457 | MIP6-Agent-Info{ | 458 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64) | 459 | } | 460 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 461 | Result-Code=DIAMETER_SUCCESS | 462 | EAP-Payload(EAP Success) | 463 | EAP-Master-Session-Key | 464 | (authorization AVPs) | 465 | ... | 466 |<----------------------------------------------------------------| 467 | | 469 Figure 3: Home Agent Assignment by Diameter Server 471 5.3. Home Agent Assignment by NAS or Diameter Server 473 This section shows another message flow for the MIPv6 integrated 474 scenario bootstrapping where the NAS informs the Diameter server that 475 it is able to locally assign a HA to the MN. The Diameter server is 476 able to provide a HA to the MN but also authorizes the assignment of 477 local HA. The Diameter server then replies to the NAS with HA 478 related bootstrapping information. 480 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 481 server assigned HA to the MN is, in this example, based on the local 482 ASP policy. 484 Diameter 485 NAS/VAAA Server 486 | | 487 | Diameter-EAP-Request | 488 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 489 | | MIP6_INTEGRATED) | 490 | MIP6-Agent-Info{ | 491 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 492 | } | 493 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 494 | EAP-Payload(EAP Start) | 495 |---------------------------------------------------------------->| 496 | | 497 | | 498 : ...more EAP Request/Response pairs... : 499 | | 500 | | 501 | Diameter-EAP-Answer | 502 | MIP6-Agent-Info{ | 503 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} | 504 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 505 | | MIP6_INTEGRATED) | 506 | Result-Code=DIAMETER_SUCCESS | 507 | EAP-Payload(EAP Success) | 508 | EAP-Master-Session-Key | 509 | (authorization AVPs) | 510 | ... | 511 |<----------------------------------------------------------------| 512 | | 514 Figure 4: Home Agent Assignment by NAS or Diameter Server 516 If the Diameter server does not allow the MN to use a locally 517 assigned HA, the Diameter returns the MIP6-Feature-Vector AVP with 518 the LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it allocated 519 to the MN. 521 6. Attribute Value Pair Occurrence Tables 523 Figure 5 lists the MIPv6 bootstrapping NAS to HAAA interface AVPs, 524 along with a specification determining how many of each new AVP may 525 be included in a Diameter command. They may be present in any 526 Diameter application request and answer commands, where permitted by 527 the command ABNF. 529 +-----------+ 530 | Command | 531 |-----+-----+ 532 Attribute Name | Req | Ans | 533 -------------------------------|-----+-----| 534 MIP6-Agent-Info | 0+ | 0+ | 535 MIP6-Feature-Vector | 0-1 | 0-1 | 536 MIP6-Home-Link-Prefix | 0+ | 0+ | 537 +-----+-----+ 539 Figure 5: Generic Request and Answer Commands AVP Table 541 7. IANA Considerations 543 7.1. Registration of new AVPs 545 This specification defines the following new AVPs: 547 MIP6-Agent-Info is set to TBD 548 MIP6-Feature-Vector is set to TBD 549 MIP6-Home-Link-Prefix is set to TBD 551 7.2. New Registry: Mobility Capability 553 IANA is requested to create a new registry for the Mobility 554 Capability as described in Section 4.2.5. 556 Token | Value | Description 557 ----------------------------------+----------------------+------------ 558 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 559 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 560 Available for Assignment via IANA | 2^x | 562 Allocation rule: Only numeric values that are 2^x (power of two, 563 where x >= 2) are allowed based on the allocation policy described 564 below. 566 Following the example policies described in [11] new values for the 567 MIP6-Feature-Vector AVP will be assigned based on the "Specification 568 Required" policy. No mechanism to mark entries as "deprecated" is 569 envisioned. 571 8. Security Considerations 573 The security considerations for the Diameter interaction required to 574 accomplish the integrated scenario are described in [12]. 576 Additionally, the security considerations of the Diameter base 577 protocol [5], Diameter NASREQ application [6] / Diameter EAP [3] 578 application (with respect to network access authentication and the 579 transport of keying material) are applicable to this document. 580 Developers should insure that special attention is paid to 581 configuring the security associations protecting the messages that 582 enables the global positioning and allocation of home agents, for 583 instance, as outlined in section 5. 585 9. Acknowledgements 587 This document is heavily based on the ongoing work for RADIUS MIPv6 588 interaction. Hence, credits go to respective authors for their work 589 with draft-ietf-mip6-radius. Furthermore, the author would like to 590 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 591 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 592 in context of MIPv6 Diameter interworking. Their work influenced 593 this document. Jouni Korhonen would like to thank Academy of Finland 594 and TEKES MERCoNe Project for providing funding to work on this 595 document. Julien Bournelle would like to thank GET/INT since he 596 began to work on this document while he was in their employ. Authors 597 would also like to acknowledge Raymond Hsu for his valuable feedback 598 on local HA assignment and Wolfgang Fritsche for his thorough review. 599 Finally, we would like to Domagoj Premec for his review comments. 601 We would like to thank Alper Yegin, Robert Marks, David Frascone for 602 their comments at the second WGLC. 604 10. References 606 10.1. Normative References 608 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 609 IPv6", RFC 3775, June 2004. 611 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 612 Levels", BCP 14, RFC 2119, March 1997. 614 [3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 615 Authentication Protocol (EAP) Application", RFC 4072, 616 August 2005. 618 [4] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 619 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 620 August 2005. 622 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 623 "Diameter Base Protocol", RFC 3588, September 2003. 625 [6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 626 Network Access Server Application", RFC 4005, August 2005. 628 10.2. Informative References 630 [7] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 631 Bootstrapping in Split Scenario", RFC 5026, October 2007. 633 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 634 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 636 [9] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 637 Lopez, "AAA Goals for Mobile IPv6", 638 draft-ietf-mext-aaa-ha-goals-01 (work in progress), May 2008. 640 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 641 RFC 3753, June 2004. 643 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 644 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 646 [12] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 647 Integrated Scenario", 648 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 649 progress), April 2008. 651 Authors' Addresses 653 Jouni Korhonen 654 TeliaSonera 655 Teollisuuskatu 13 656 Sonera FIN-00051 657 Finland 659 Email: jouni.korhonen@teliasonera.com 660 Julien Bournelle 661 Orange Labs 662 38-4O rue du general Leclerc 663 Issy-Les-Moulineaux 92794 664 France 666 Email: julien.bournelle@orange-ftgroup.com 668 Hannes Tschofenig 669 Nokia Siemens Networks 670 Linnoitustie 6 671 Espoo 02600 672 Finland 674 Phone: +358 (50) 4871445 675 Email: Hannes.Tschofenig@nsn.com 676 URI: http://www.tschofenig.priv.at 678 Charles E. Perkins 679 WiChorus 681 Phone: +1-650-496-4402 682 Email: charliep@wichorus.com 684 Kuntal Chowdhury 685 Starent Networks 686 30 International Place 687 Tewksbury MA 01876 688 US 690 Phone: +1 214 550 1416 691 Email: kchowdhury@starentnetworks.com 693 Full Copyright Statement 695 Copyright (C) The IETF Trust (2008). 697 This document is subject to the rights, licenses and restrictions 698 contained in BCP 78, and except as set forth therein, the authors 699 retain all their rights. 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 704 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 705 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 706 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Intellectual Property 711 The IETF takes no position regarding the validity or scope of any 712 Intellectual Property Rights or other rights that might be claimed to 713 pertain to the implementation or use of the technology described in 714 this document or the extent to which any license under such rights 715 might or might not be available; nor does it represent that it has 716 made any independent effort to identify any such rights. Information 717 on the procedures with respect to rights in RFC documents can be 718 found in BCP 78 and BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the use of 723 such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights that may cover technology that may be required to implement 730 this standard. Please address the information to the IETF at 731 ietf-ipr@ietf.org. 733 Acknowledgment 735 Funding for the RFC Editor function is provided by the IETF 736 Administrative Support Activity (IASA).