idnits 2.17.1 draft-ietf-dime-mip6-integrated-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 834. 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 6, 2007) is 6006 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 667 ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3588 (ref. '3') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (ref. '4') (Obsoleted by RFC 7155) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 Summary: 4 errors (**), 0 flaws (~~), 2 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 France Telecom R&D 6 Expires: May 9, 2008 H. Tschofenig 7 C. Perkins 8 Nokia Siemens Networks 9 K. Chowdhury 10 Starent Networks 11 November 6, 2007 13 Diameter Mobile IPv6: Support for Network Access Server to Diameter 14 Server Interaction 15 draft-ietf-dime-mip6-integrated-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 9, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 A Mobile IPv6 node requires a Home Agent address, a home address, and 49 a security association with its Home Agent before it can start 50 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 51 parameters are statically configured. Mobile IPv6 bootstrapping work 52 aims to make this information dynamically available to the Mobile 53 Node. An important aspect of the Mobile IPv6 bootstrapping solution 54 is to support interworking with existing authentication, 55 authorization and accounting infrastructure. This document describes 56 the MIPv6 bootstrapping using the Diameter Network Access Server 57 (NAS) to home Authentication, Authorization and Accounting server 58 (HAAA) interface. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Commands, AVPs and Advertising Application Support . . . . . . 6 66 4.1. Advertising Application Support . . . . . . . . . . . . . 6 67 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 7 69 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 7 70 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 8 71 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 72 4.7. Attribute Value Pair Definitions . . . . . . . . . . . . . 9 73 4.7.1. MIP6-Agent-Info . . . . . . . . . . . . . . . . . . . 9 74 4.7.2. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . 9 75 4.7.3. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . 10 76 4.7.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . 10 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1. Home Agent Assignment by the NAS . . . . . . . . . . . . . 11 79 5.2. Home Agent Assignment by the Diameter Server . . . . . . . 12 80 5.3. Home Agent Assignment by NAS or Diameter Server . . . . . 13 81 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 14 82 6.1. AAR, AAA, DER and DEA Commands AVP Table . . . . . . . . . 14 83 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 16 86 8.2. New Registry: Mobility Capability . . . . . . . . . . . . 16 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 Intellectual Property and Copyright Statements . . . . . . . . . . 20 95 1. Introduction 97 The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN) 98 to perform registration with a Home Agent (HA) with information about 99 its current point of attachment (care-of address). The HA creates 100 and maintains binding between the MN's Home Address and the MN's 101 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. However, static 109 provisioning of this information becomes an administrative burden for 110 an operator. Moreover, it does not address load balancing, failover, 111 opportunistic home link assignment and assignment of local home 112 agents in close proximity to the MN. Also the ability to react on 113 sudden environmental or topological changes is minimal. Static 114 provisioning may not be desirable, in light of the mentioned 115 limitations. 117 Dynamic assignment of MIPv6 home registration information is a 118 desirable feature for ease of deployment and network maintenance. 119 For this purpose, the AAA infrastructure, which is used for access 120 authentication, can be leveraged to assign some or all of the 121 necessary parameters. The Diameter server in Access Service 122 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 123 return these parameters to the AAA client. Regarding the 124 bootstrapping procedures, the AAA client might either be the NAS, in 125 case of the integrated scenario, or the HA, in case of the split 126 scenario [7]. The terms integrated and split are described in the 127 terminology section and were introduced in [8] and [9]. 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 [2]. 135 General mobility terminology can be found in [10]. The following 136 additional terms, as defined in [8], are used in this document: 138 Access Service Authorizer (ASA): 140 A network operator that authenticates a MN and establishes the 141 MN's authorization to receive Internet service. 143 Access Service Provider (ASP): 145 A network operator that provides direct IP packet forwarding to 146 and from the MN. 148 Mobility Service Authorizer (MSA): 150 A service provider that authorizes MIPv6 service. 152 Mobility Service Provider (MSP): 154 A service provider that provides MIPv6 service. In order to 155 obtain such service, the MN must be authenticated and authorized 156 to obtain the MIPv6 service. 158 Split scenario: 160 A scenario where the mobility service and the network access 161 service are authorized by different entities. 163 Integrated Scenario: 165 A scenario where the mobility service and the network access 166 service are authorized by the same entity. 168 Network Access Server (NAS): 170 A device that provides an access service for a user to a network. 172 Home AAA (HAAA): 174 An authentication, authorization and accounting server located in 175 user's home network. 177 3. Overview 179 This document addresses the authentication, authorization and 180 accounting functionality required by for the MIPv6 bootstrapping as 181 outlined in the MIPv6 bootstrapping problem statement document [8]. 182 This document focuses on the Diameter based AAA functionality for the 183 NAS to HAAA interface. 185 In the integrated scenario MIPv6 bootstrapping is provided as part of 186 the network access authentication procedure. Figure 1 shows the 187 participating entities. This document, however, only concentrates on 188 the NAS, possible local Diameter proxies and the home Diameter 189 server. 191 +---------------------------+ +-----------------+ 192 |Access Service Provider | |ASA/MSA/(MSP) | 193 |(Mobility Service Provider)| | | 194 | | | | 195 | +--------+ | | +--------+ | 196 | |Local | Diameter | | |Home | | 197 | |Diameter|<---------------------->|Diameter| | 198 | |Proxy | | | |Server | | 199 | +--------+ | | +--------+ | 200 | ^ ^ | | ^ | 201 | | | | | | | 202 | | | | | | | 203 | Diameter | | v | 204 | | | +-------+ | | +-------+ | 205 | | | |Home | | | |Home | | 206 | | +-------->|Agent | | | |Agent | | 207 | | |in ASP | | | |in MSP | | 208 | v +-------+ | | +-------+ | 209 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 210 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 211 |Node |------------|Diameter |---|Server | | 212 | | PANA,... | |Client | | | | 213 +-------+ DHCP | +-----------+ +-------+ | 214 +---------------------------+ 216 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 218 In a typical MIPv6 access scenario the MN is attached to an ASP's 219 network. During the network attachment procedure, the NAS/Diameter 220 client interacts with the MN. 222 During the time of authentication the Diameter server in the ASA/MSA 223 detects that the user is also authorized for MIPv6 access. Based on 224 the MSA's policy, the Diameter server may return several MIPv6 225 bootstrapping related parameters. 227 Depending on the details of the bootstrapping solution interaction 228 with the DHCPv6 server may be required, as described in [11]. 229 However, the Diameter based NAS to HAAA interface described in this 230 document is not tied to DHCPv6 as the only possible way to convey 231 MIPv6 related configuration parameters from the Diameter client to 232 the mobile node. 234 4. Commands, AVPs and Advertising Application Support 236 This section describes command codes, defines AVPs and advertised 237 application identifiers for the Diameter MIPv6 bootstrapping in the 238 NAS to HAAA interface. 240 4.1. Advertising Application Support 242 Diameter nodes conforming to this specification MUST include the 243 value of 1 (NASREQ application) or 5 (EAP application) in the Auth- 244 Application-Id and the Acct-Application-Id AVP of the Capabilities- 245 Exchange-Request / Capabilities-Exchange-Answer commands [3]. 247 4.2. Command Codes 249 This document re-uses the Diameter NASREQ application [4] and the EAP 250 application commands [5]. The following commands are used to carry 251 MIPv6 related bootstrapping AVPs: 253 Command-Name Abbrev. Code Reference Application 255 Diameter-EAP-Request DER 268 RFC 4072 EAP 256 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 258 AA-Request AAR 265 RFC 4005 NASREQ 259 AA-Answer AAA 265 RFC 4005 NASREQ 261 Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 263 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 264 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 265 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 266 (ACR), and Accounting-Answer (ACA) commands are used together with 267 the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules 268 in the Diameter NASREQ [4], EAP [5] and RFC 3588 [3] applications. 269 The accounting commands use the Application Identifier value of 3 270 (Diameter Base Accounting); the others use 0 (Diameter Common 271 Messages). 273 All request messages SHOULD contain the User-Name AVP containing the 274 identity of the MN in NAI format. It is out of scope how the NAS 275 finds out the MN identity However, for example, the NAS could use the 276 MN identity provided by the network access authentication mechanism. 278 4.3. Diameter-EAP-Request (DER) 280 The Diameter-EAP-Request (DER) message [5], indicated by the Command- 281 Code field set to 268 and the 'R' bit set in the Command Flags field, 282 is sent by the NAS to the Diameter server to initiate a network 283 access authentication and authorization procedure. The DER message 284 format is the same as defined in [5]. The message MAY include 285 optional MIPv6 bootstrapping AVPs: 287 ::= < Diameter Header: 268, REQ, PXY > 288 < Session-Id > 289 { Auth-Application-Id } 290 { Origin-Host } 291 { Origin-Realm } 292 { Destination-Realm } 293 { Auth-Request-Type } 295 * [ MIP6-Agent-Info ] 296 [ MIP6-Feature-Vector ] 298 [ User-Name ] 299 [ Destination-Host ] 300 ... 301 * [ AVP ] 303 4.4. Diameter-EAP-Answer (DEA) 305 The Diameter-EAP-Answer (DEA) message defined in [5], indicated by 306 the Command-Code field set to 268 and 'R' bit cleared in the Command 307 Flags field, is sent in response to the Diameter-EAP-Request message 308 (DER). If the network access authentication procedure was successful 309 then the response MAY include any set of bootstrapping AVPs. 311 The DEA message format is the same as defined in [5] with an addition 312 of optional MIPv6 bootstrapping AVPs: 314 ::= < Diameter Header: 268, PXY > 315 < Session-Id > 316 { Auth-Application-Id } 317 { Auth-Request-Type } 318 { Result-Code } 319 { Origin-Host } 320 { Origin-Realm } 322 * [ MIP6-Agent-Info ] 323 [ MIP6-Feature-Vector ] 325 [ User-Name ] 326 ... 327 * [ AVP ] 329 4.5. AA-Request (AAR) 331 The AA-Request (AAR) message [4], indicated by the Command-Code field 332 set to 265 and 'R' bit set in the Command Flags field, is sent by the 333 NAS to the Diameter server to initiate a network access 334 authentication and authorization procedure. The AAR message format 335 is the same as defined in [4]. The message MAY include optional 336 MIPv6 bootstrapping AVPs: 338 ::= < Diameter Header: 265, REQ, PXY > 339 < Session-Id > 340 { Auth-Application-Id } 341 { Origin-Host } 342 { Origin-Realm } 343 { Destination-Realm } 344 { Auth-Request-Type } 346 * [ MIP6-Agent-Info ] 347 [ MIP6-Feature-Vector ] 349 [ User-Name ] 350 [ Destination-Host ] 351 ... 352 * [ AVP ] 354 4.6. AA-Answer (AAA) 356 The AA-Answer (AAA) message, indicated by the Command-Code field set 357 to 265 and 'R' bit cleared in the Command Flags field is sent in 358 response to the AA-Request (AAR) message for confirmation of the 359 result of MIPv6 HA bootstrapping. If the network access 360 authentication procedure was successful then the response MAY include 361 any set of bootstrapping AVPs. 363 The AAA message format is the same as defined in [4] with an addition 364 of optional MIPv6 bootstrapping AVPs: 366 ::= < Diameter Header: 265, PXY > 367 < Session-Id > 368 { Auth-Application-Id } 369 { Auth-Request-Type } 370 { Result-Code } 371 { Origin-Host } 372 { Origin-Realm } 374 * [ MIP6-Agent-Info ] 375 [ MIP6-Feature-Vector ] 377 [ User-Name ] 378 ... 379 * [ AVP ] 381 4.7. Attribute Value Pair Definitions 383 4.7.1. MIP6-Agent-Info 385 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 386 contains necessary information to assign a HA to the MN. When the 387 MIP6-Agent-Info AVP is present in a message, it MUST contain either 388 the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or 389 both AVPs. The grouped AVP has the following grammar: 391 ::= < AVP Header: TBD > 392 [ MIP-Home-Agent-Address ] 393 [ MIP-Home-Agent-Host ] 394 * [ AVP ] 396 4.7.2. MIP-Home-Agent-Address AVP 398 The MIP-Home-Agent-Address AVP (AVP Code 334 [6]) is of type Address 399 and contains the HA address. The Diameter server MAY decide to 400 assign a HA to the MN that is in close proximity to the point of 401 attachment (e.g., determined by the NAS-Identifier AVP). There may 402 be other reasons for dynamically assigning HAs to the MN, for example 403 to share the traffic load. 405 This AVP MAY also be attached by the NAS or by the intermediate local 406 Diameter proxy when sent to the Diameter server in a request message 407 as a hint of a locally assigned HA. 409 4.7.3. MIP-Home-Agent-Host AVP 411 The MIP-Home-Agent-Host AVP (AVP Code 348 [6]) is of type Grouped and 412 contains the identity of the assigned HA. Both the Destination-Realm 413 and the Destination-Host AVP of the HA are included in the grouped 414 AVP. The usage of this AVP is equivalent to the MIP-Home-Agent- 415 Address AVP but offers an additional level of indirection via the DNS 416 infrastructure. 418 This AVP MAY also be attached by the NAS or by the intermediate local 419 Diameter proxy when sent to the Diameter server in a request message 420 as a hint of a locally assigned HA. 422 4.7.4. MIP6-Feature-Vector AVP 424 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 425 contains a 64 bits flags field of supported capabilities of the NAS/ 426 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 427 MUST be supported, although that does not provide much guidance about 428 specific needs of bootstrapping. 430 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 431 to the Diameter server. For example, the NAS may indicate that a 432 local home agent can be provided. Similarly, the Diameter server MAY 433 include this AVP to inform the NAS/ASP about which of the NAS/ASP 434 indicated capabilities are supported or authorized by the ASA/MSA(/ 435 MSP). 437 The following capabilities are defined in this document: 439 MOBILITY_CAPABILITY (0x0000000000000000) 441 The MIP6-Feature-Vector AVP MAY contain value 0 (zero) with the 442 semantics that Mobile IPv6 bootstrapping is generally supported. 443 This value represents the default when the MIP6-Feature-Vector AVP 444 is included in a message. 446 MIP6_INTEGRATED (0x0000000000000001) 448 The entity that sets the flag has an impact on the semantic. When 449 this flag is set by the NAS then it means that the Mobile IPv6 450 integrated scenario bootstrapping functionality is supported by 451 the NAS. When this flag is set by the Diameter server then the 452 Mobile IPv6 integrated scenario bootstrapping is supported by the 453 Diameter server. 455 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 457 The entity that sets the flag has an impact on the semantic. When 458 this flag is set by the NAS then a local home agent can be 459 assigned to the MN. When this flag is set by the Diameter server 460 then the assignment of location HAs is authorized by the Diameter 461 server. 463 5. Examples 465 5.1. Home Agent Assignment by the NAS 467 In this scenario we consider the case where the NAS wishes to 468 allocate a local HA to the MN. The NAS will also inform the Diameter 469 server about the HA address it has assigned to the visiting MN (e.g., 470 2001:db8:1:c020::1). The Diameter-EAP-Request message therefore has 471 the MIP6-Feature-Vector with the LOCAL_HOME_AGENT_ASSIGNMENT and the 472 MIP6_INTEGRATED set. The MIP6-Agent-Info AVP contains the MIP-Home- 473 Agent-Address AVP with the address of the proposed HA. 475 Diameter 476 NAS Server 477 | | 478 | Diameter-EAP-Request | 479 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 480 | | MIP6_INTEGRATED) | 481 | MIP6-Agent-Info{ | 482 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 483 | } | 484 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 485 | EAP-Payload(EAP Start) | 486 |---------------------------------------------------------------->| 487 | | 488 | | 489 : ...more EAP Request/Response pairs... : 490 | | 491 | | 492 | Diameter-EAP-Answer | 493 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 494 | | MIP6_INTEGRATED) | 495 | Result-Code=DIAMETER_SUCCESS | 496 | EAP-Payload(EAP Success) | 497 | EAP-Master-Session-Key | 498 | (authorization AVPs) | 499 | ... | 500 |<----------------------------------------------------------------| 501 | | 503 Figure 3: Home Agent Assignment by NAS 505 Depending on the Diameter server configuration and user's 506 subscription profile, the Diameter server either accepts or rejects 507 the proposal of locally HA allocated by the NAS will be used. In our 508 example, the Diameter server accepts the proposal and the the MIP6- 509 Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together 510 with the MIP6_INTEGRATED flag) is set and returned to the NAS. 512 5.2. Home Agent Assignment by the Diameter Server 514 In this scenario we consider the case where the NAS supports the 515 Diameter MIPv6 integrated scenario as defined in this document but 516 does not offer local home agent assignment. Hence, the MIP6-Feature- 517 Vector AVP only has the MIP6_INTEGRATED flag set. The Diameter 518 server allocates a home agent to the mobile node and conveys the 519 address in the MIP-Home-Agent-Address AVP that is encapsulated in the 520 MIP6-Agent-Info AVP. Additionally, the MIP6-Feature-Vector AVP has 521 the MIP6_INTEGRATED flag set. 523 Diameter 524 NAS Server 525 | | 526 | Diameter-EAP-Request | 527 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 528 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 529 | EAP-Payload(EAP Start) | 530 |---------------------------------------------------------------->| 531 | | 532 | | 533 : ...more EAP Request/Response pairs... : 534 | | 535 | | 536 | Diameter-EAP-Answer | 537 | MIP6-Agent-Info{ | 538 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64) | 539 | } | 540 | MIP6-Feature-Vector=(MIP6_INTEGRATED) | 541 | Result-Code=DIAMETER_SUCCESS | 542 | EAP-Payload(EAP Success) | 543 | EAP-Master-Session-Key | 544 | (authorization AVPs) | 545 | ... | 546 |<----------------------------------------------------------------| 547 | | 549 Figure 4: Home Agent Assignment by Diameter Server 551 5.3. Home Agent Assignment by NAS or Diameter Server 553 This section shows a message flows for the MIPv6 integrated scenario 554 bootstrapping where the NAS informs the Diameter server that it is 555 able to locally assign a HA to the MN. The Diameter server is also 556 able to provide a HA to the MN but also authorizes the assignment of 557 local HA. The Diameter server then replies to the NAS with HA 558 related bootstrapping information. 560 Whether the NAS/ASP then offers a locally assigned HA or the Diameter 561 server assigned HA to the MN is, in this example, based on the local 562 ASP policy. 564 Diameter 565 NAS Server 566 | | 567 | Diameter-EAP-Request | 568 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 569 | | MIP6_INTEGRATED) | 570 | MIP6-Agent-Info{ | 571 | MIP-Home-Agent-Address(2001:db8:1:c020::1)} | 572 | } | 573 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 574 | EAP-Payload(EAP Start) | 575 |---------------------------------------------------------------->| 576 | | 577 | | 578 : ...more EAP Request/Response pairs... : 579 | | 580 | | 581 | Diameter-EAP-Answer | 582 | MIP6-Agent-Info{ | 583 | MIP-Home-Agent-Address(2001:db8:6000:302::1/64)} | 584 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 585 | | MIP6_INTEGRATED) | 586 | Result-Code=DIAMETER_SUCCESS | 587 | EAP-Payload(EAP Success) | 588 | EAP-Master-Session-Key | 589 | (authorization AVPs) | 590 | ... | 591 |<----------------------------------------------------------------| 592 | | 594 Figure 5: Home Agent Assignment by NAS or Diameter Server 596 If the Diameter server does not accept locally assigned HA, the 597 Diameter returns the MIP6-Feature-Vector AVP with 598 LOCAL_HOME_AGENT_ASSIGNMENT bit unset and HA address it plans to 599 allocate for the MN. 601 6. AVP Occurrence Tables 603 6.1. AAR, AAA, DER and DEA Commands AVP Table 605 The following table lists the additional MIPv6 bootstrapping NAS to 606 HAAA interface AVPs that may optionally be present in the AAR and AAA 607 Commands [4] or in the DER and DEA Commands [5]. 609 +-----------------------+ 610 | Command-Code | 611 |-----+-----+-----+-----+ 612 Attribute Name | AAR | AAA | DER | DEA | 613 -------------------------------|-----+-----|-----+-----+ 614 MIP6-Agent-Info | 0+ | 0+ | 0+ | 0+ | 615 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 616 +-----+-----+-----+-----+ 618 Figure 6: AAR, AAA, DER and DEA Commands AVP Table 620 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs 622 This section defines AVPs that are specific to Diameter MIPv6 623 bootstrapping NAS to HAAA interface and MAY be included in the 624 Diameter EAP [5] and the NASREQ [4] application messages. The 625 Diameter AVP rules are defined in the Diameter Base [3], Section 4. 626 These AVP rules are observed in AVPs defined in this section. 628 The following table describes the Diameter AVPs, their AVP Code 629 values, types, possible flag values, and whether the AVP MAY be 630 encrypted. The Diameter base [3] specifies the AVP Flag rules for 631 AVPs in Section 4.5. 633 +---------------------+ 634 | AVP Flag rules | 635 +----+-----+----+-----+----+ 636 AVP Section | | |SHLD|MUST | | 637 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 638 ------------------------------------------+----+-----+----+-----+----+ 639 MIP6-Agent-Info TBD 4.7.1 Grouped | | M,P | | V | Y | 640 MIP-Home-Agent- | | | | | | 641 Address 334 4.7.2 Address | | M,P | | V | Y | 642 MIP-Home-Agent- | | | | | | 643 Host 348 4.7.3 Grouped | | M,P | | V | Y | 644 MIP6-Feature- | | | | | | 645 Vector TBD 4.7.4 Unsigned64 | | M,P | | V | Y | 646 ------------------------------------------+----+-----+----+-----+----+ 648 Figure 7: AVP Flag Rules Table 650 8. IANA Considerations 651 8.1. Registration of new AVPs 653 This specification defines the following new AVPs: 655 MIP6-Agent-Info is set to TBD 656 MIP6-Feature-Vector is set to TBD 658 8.2. New Registry: Mobility Capability 660 IANA is requested to create a new registry for the Mobility 661 Capability as described in Section 4.7.4. 663 Token | Value | Description 664 ----------------------------------+----------------------+------------ 665 MOBILITTY_CAPABILITY | 0x0000000000000000 | [RFC TBD] 666 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 667 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 668 Available for Assignment via IANA | 2^x | 670 Allocation rule: Only numeric values that are 2^x (power of two) are 671 allowed based on the allocation policy described below. 673 Following the policies outlined in [1] new values with a description 674 of their semantic for usage with the MIP6-Feature-Vector AVP together 675 with a Token will be assigned after Expert Review initiated by the 676 O&M Area Directors in consultation with the DIME working group chairs 677 or the working group chairs of a designated successor working group. 678 Updates can be provided based on expert approval only. A designated 679 expert will be appointed by the O&M Area Directors. No mechanism to 680 mark entries as "deprecated" is envisioned. Based on expert approval 681 it is possible to delete entries from the registry. 683 9. Security Considerations 685 The security considerations for the Diameter interaction required to 686 accomplish the integrated scenario are described in [11]. 687 Additionally, the security considerations of the Diameter base 688 protocol [3], Diameter NASREQ application [4] / Diameter EAP [5] 689 application (with respect to network access authentication and the 690 transport of keying material) are applicable to this document. This 691 document does not introduce new security vulnerabilities. 693 10. Acknowledgements 695 This document is heavily based on the ongoing work for RADIUS MIPv6 696 interaction. Hence, credits go to respective authors for their work 697 with draft-ietf-mip6-radius. Furthermore, the author would like to 698 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 699 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 700 in context of MIPv6 Diameter interworking. Their work influenced 701 this document. Jouni Korhonen would like to thank Academy of Finland 702 and TEKES MERCoNe Project for providing funding to work on this 703 document. Julien Bournelle would like to thank GET/INT since he 704 began to work on this document while he was in their employ. Authors 705 would also like to acknowledge Raymond Hsu for his valuable feedback 706 on local HA assignment and Wolfgang Fritsche for his thorough review. 708 11. References 710 11.1. Normative References 712 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 713 IPv6", RFC 3775, June 2004. 715 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 716 Levels", BCP 14, RFC 2119, March 1997. 718 [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 719 "Diameter Base Protocol", RFC 3588, September 2003. 721 [4] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 722 Network Access Server Application", RFC 4005, August 2005. 724 [5] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 725 Authentication Protocol (EAP) Application", RFC 4072, 726 August 2005. 728 [6] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 729 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 730 August 2005. 732 11.2. Informative References 734 [7] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 735 Bootstrapping in Split Scenario", RFC 5026, October 2007. 737 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 738 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 740 [9] Giaretta, G., "AAA Goals for Mobile IPv6", 741 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 742 September 2006. 744 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 745 RFC 3753, June 2004. 747 [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 748 Integrated Scenario", 749 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 750 progress), July 2007. 752 Authors' Addresses 754 Jouni Korhonen (editor) 755 TeliaSonera 756 Teollisuuskatu 13 757 Sonera FIN-00051 758 Finland 760 Email: jouni.korhonen@teliasonera.com 762 Julien Bournelle 763 France Telecom R&D 764 38-4O rue du general Leclerc 765 Issy-Les-Moulineaux 92794 766 France 768 Email: julien.bournelle@orange-ftgroup.com 770 Hannes Tschofenig 771 Nokia Siemens Networks 772 Otto-Hahn-Ring 6 773 Munich, Bavaria 81739 774 Germany 776 Email: Hannes.Tschofenig@nsn.com 777 URI: http://www.tschofenig.com 779 Charles E. Perkins 780 Nokia Siemens Networks 781 313 Fairchild Drive 782 Mountain View CA 94043 783 US 785 Phone: +1 650 625-2986 786 Email: charliep@nsn.com 787 Kuntal Chowdhury 788 Starent Networks 789 30 International Place 790 Tewksbury MA 01876 791 US 793 Phone: +1 214 550 1416 794 Email: kchowdhury@starentnetworks.com 796 Full Copyright Statement 798 Copyright (C) The IETF Trust (2007). 800 This document is subject to the rights, licenses and restrictions 801 contained in BCP 78, and except as set forth therein, the authors 802 retain all their rights. 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 807 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 808 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 809 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Intellectual Property 814 The IETF takes no position regarding the validity or scope of any 815 Intellectual Property Rights or other rights that might be claimed to 816 pertain to the implementation or use of the technology described in 817 this document or the extent to which any license under such rights 818 might or might not be available; nor does it represent that it has 819 made any independent effort to identify any such rights. Information 820 on the procedures with respect to rights in RFC documents can be 821 found in BCP 78 and BCP 79. 823 Copies of IPR disclosures made to the IETF Secretariat and any 824 assurances of licenses to be made available, or the result of an 825 attempt made to obtain a general license or permission for the use of 826 such proprietary rights by implementers or users of this 827 specification can be obtained from the IETF on-line IPR repository at 828 http://www.ietf.org/ipr. 830 The IETF invites any interested party to bring to its attention any 831 copyrights, patents or patent applications, or other proprietary 832 rights that may cover technology that may be required to implement 833 this standard. Please address the information to the IETF at 834 ietf-ipr@ietf.org. 836 Acknowledgment 838 Funding for the RFC Editor function is provided by the IETF 839 Administrative Support Activity (IASA).