idnits 2.17.1 draft-ietf-dime-mip6-integrated-05.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 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 852. 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 (July 9, 2007) is 6136 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 684 ** 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 (-07) exists of draft-ietf-mip6-bootstrapping-split-05 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-04 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 France Telecom R&D 6 Expires: January 10, 2008 H. Tschofenig 7 C. Perkins 8 Nokia Siemens Networks 9 K. Chowdhury 10 Starent Networks 11 July 9, 2007 13 Diameter Mobile IPv6: Support for Network Access Server to Diameter 14 Server Interaction 15 draft-ietf-dime-mip6-integrated-05.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 January 10, 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. Example Message Flows . . . . . . . . . . . . . . . . . . . . 11 78 5.1. EAP-based Authentication . . . . . . . . . . . . . . . . . 11 79 5.2. Integrated Scenario and HA Allocation in MSP . . . . . . . 12 80 5.3. Integrated Scenario and HA Allocation in ASP . . . . . . . 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 . . . . . . . . . . . . . . . . . 15 86 8.2. New Registry: Mobility Capability . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 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 set of information may be statically provisioned 109 in the MN. However, static provisioning of this information becomes 110 an administrative burden for an operator. Moreover, static 111 provisioning does not address load balancing, failover, opportunistic 112 home link assignment and assignment of local home agents in close 113 proximity to the MN. Also the ability to react on sudden 114 environmental or topological changes is minimal. Static provisioning 115 may not be desirable, in light of the mentioned 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 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 MIPv6 231 bootstrapping method. 233 4. Commands, AVPs and Advertising Application Support 235 This section describes command codes, defines AVPs and advertised 236 application identifiers for the Diameter MIPv6 bootstrapping in the 237 NAS to HAAA interface. 239 4.1. Advertising Application Support 241 Diameter nodes conforming to this specification MUST include the 242 value of 1 (NASREQ application) or 5 (EAP application) in the Auth- 243 Application-Id and the Acct-Application-Id AVP of the Capabilities- 244 Exchange-Request / Capabilities-Exchange-Answer commands [3]. 246 4.2. Command Codes 248 This document re-uses the Diameter NASREQ application [4] and the EAP 249 application commands [5]. The following commands are used to carry 250 MIPv6 related bootstrapping AVPs: 252 Command-Name Abbrev. Code Reference Application 254 Diameter-EAP-Request DER 268 RFC 4072 EAP 255 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 257 AA-Request AAR 265 RFC 4005 NASREQ 258 AA-Answer AAA 265 RFC 4005 NASREQ 260 Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 262 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 263 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 264 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 265 (ACR), and Accounting-Answer (ACA) commands are used together with 266 the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules 267 in the Diameter NASREQ [4], EAP [5] and RFC 3588 [3] applications. 268 The accounting commands use the Application Identifier value of 3 269 (Diameter Base Accounting); the others use 0 (Diameter Common 270 Messages). 272 All request messages SHOULD contain User-Name AVP containing the 273 identity of the MN in NAI format. It is out of scope how the NAS 274 finds out the MN identity However, for example, the NAS could use the 275 MN identity provided by the network access authentication mechanism. 277 4.3. Diameter-EAP-Request (DER) 279 The Diameter-EAP-Request (DER) message [5], indicated by the Command- 280 Code field set to 268 and the 'R' bit set in the Command Flags field, 281 is sent by the NAS to the Diameter server to initiate a network 282 access authentication and authorization procedure. The DER message 283 format is the same as defined in [5]. The message MAY include 284 optional MIPv6 bootstrapping AVPs: 286 ::= < Diameter Header: 268, REQ, PXY > 287 < Session-Id > 288 { Auth-Application-Id } 289 { Origin-Host } 290 { Origin-Realm } 291 { Destination-Realm } 292 { Auth-Request-Type } 294 * [ MIP6-Agent-Info ] 295 [ MIP6-Feature-Vector ] 297 [ User-Name ] 298 [ Destination-Host ] 299 ... 300 * [ AVP ] 302 4.4. Diameter-EAP-Answer (DEA) 304 The Diameter-EAP-Answer (DEA) message defined in [5], indicated by 305 the Command-Code field set to 268 and 'R' bit cleared in the Command 306 Flags field, is sent in response to the Diameter-EAP-Request message 307 (DER). If the network access authentication procedure was successful 308 then the response MAY include any set of bootstrapping AVPs. 310 The DEA message format is the same as defined in [5] with an addition 311 of optional MIPv6 bootstrapping AVPs: 313 ::= < Diameter Header: 268, PXY > 314 < Session-Id > 315 { Auth-Application-Id } 316 { Auth-Request-Type } 317 { Result-Code } 318 { Origin-Host } 319 { Origin-Realm } 321 * [ MIP6-Agent-Info ] 322 [ MIP6-Feature-Vector ] 324 [ User-Name ] 325 ... 326 * [ AVP ] 328 4.5. AA-Request (AAR) 330 The AA-Request (AAR) message [4], indicated by the Command-Code field 331 set to 265 and 'R' bit set in the Command Flags field, is sent by the 332 NAS to the Diameter server to initiate a network access 333 authentication and authorization procedure. The AAR message format 334 is the same as defined in [4]. The message MAY include optional 335 MIPv6 bootstrapping AVPs: 337 ::= < Diameter Header: 265, REQ, PXY > 338 < Session-Id > 339 { Auth-Application-Id } 340 { Origin-Host } 341 { Origin-Realm } 342 { Destination-Realm } 343 { Auth-Request-Type } 345 * [ MIP6-Agent-Info ] 346 [ MIP6-Feature-Vector ] 348 [ User-Name ] 349 [ Destination-Host ] 350 ... 351 * [ AVP ] 353 4.6. AA-Answer (AAA) 355 The AA-Answer (AAA) message, indicated by the Command-Code field set 356 to 265 and 'R' bit cleared in the Command Flags field is sent in 357 response to the AA-Request (AAR) message for confirmation of the 358 result of MIPv6 HA bootstrapping. If the network access 359 authentication procedure was successful then the response MAY include 360 any set of bootstrapping AVPs. 362 The AAA message format is the same as defined in [4] with an addition 363 of optional MIPv6 bootstrapping AVPs: 365 ::= < Diameter Header: 265, PXY > 366 < Session-Id > 367 { Auth-Application-Id } 368 { Auth-Request-Type } 369 { Result-Code } 370 { Origin-Host } 371 { Origin-Realm } 373 * [ MIP6-Agent-Info ] 374 [ MIP6-Feature-Vector ] 376 [ User-Name ] 377 ... 378 * [ AVP ] 380 4.7. Attribute Value Pair Definitions 382 4.7.1. MIP6-Agent-Info 384 The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and 385 contains necessary information to assign a HA to the MN. When the 386 MIP6-Agent-Info AVP is present in a message, it MUST contain either a 387 MIP-Home-Agent-Address AVP or a MIP-Home-Agent-Host AVP, but not 388 both. The grouped AVP has the following grammar: 390 ::= < AVP Header: TBD > 391 [ MIP-Home-Agent-Address ] 392 [ MIP-Home-Agent-Host ] 393 * [ AVP ] 395 4.7.2. MIP-Home-Agent-Address AVP 397 The MIP-Home-Agent-Address AVP (AVP Code 334 [6]) is of type Address 398 and contains the HA address. The Diameter server MAY decide to 399 assign a HA to the MN that is in close proximity to the point of 400 attachment (e.g., determined by the NAS-Identifier AVP). There may 401 be other reasons for dynamically assigning HAs to the MN, for example 402 to share the traffic load. 404 This AVP MAY also be attached by the NAS when sent to the Diameter 405 server in a request message as a hint of a locally assigned HA 406 address. 408 4.7.3. MIP-Home-Agent-Host AVP 410 The MIP-Home-Agent-Host AVP (AVP Code 348 [6]) is of type Grouped and 411 contains the identity of the assigned HA. Both the FQDN and the 412 Realm of the HA are included in the grouped AVP. The usage of this 413 AVP is equivalent to the MIP-Home-Agent-Address AVP but offers an 414 additional level of indirection via the DNS infrastructure. 416 4.7.4. MIP6-Feature-Vector AVP 418 The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and 419 contains a 64 bits flags field of supported capabilities of the NAS/ 420 ASP. Sending and receiving the MIP6-Feature-Vector AVP with value 0 421 MUST be supported, although that does not provide much guidance about 422 specific needs of bootstrapping. 424 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 425 to the Diameter server. For example, the NAS may indicate that a 426 local home agent can be provided. Similarly, the Diameter server MAY 427 include this AVP to inform the NAS/ASP about which of the NAS/ASP 428 indicated capabilities are supported or authorized by the ASA/MSA(/ 429 MSP). 431 The following capabilities are defined in this document: 433 MOBILITY_CAPABILITY (0x0000000000000000) 435 The MIP6-Feature-Vector AVP MAY contain value 0 (zero) with the 436 semantics that Mobile IPv6 bootstrapping is generally supported. 437 This 'zero' flag is always implicitly set when the MIP6-Feature- 438 Vector AVP is used. 440 MIP6_INTEGRATED (0x0000000000000001) 442 This flag is set by the NAS/ASP when Mobile IPv6 integrated 443 scenario bootstrapping functionality is supported. This flag is 444 set by the ASA/MSA(/MSP) when Mobile IPv6 integrated scenario 445 bootstrapping is supported and authorized to be used. 447 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 449 This flag is set by the NAS/ASP when a local home agent can be 450 assigned to the MN. This flag is set by the ASA/MSA(/MSP) when 451 the use of a local HA is authorized. 453 5. Example Message Flows 455 5.1. EAP-based Authentication 457 This section shows basic message flows of MIPv6 integrated scenario 458 bootstrapping and dynamic HA assignment. In Figure 3 network access 459 authentication is based on EAP (e.g., 802.11i/802.1X). The NAS 460 informs the home Diameter server that it wishes to provide a locally 461 assigned HA to the visiting MN. The Diameter server assigns the MN a 462 HA in the home MSP but also authorizes the assignment of local HA for 463 the ASP. The Diameter server then replies to the NAS with HA related 464 bootstrapping information. Whether the NAS/ASP then offers a locally 465 assigned HA or the MSP assigned HA to the MN is based on the local 466 ASP policy. 468 NAS Home server 469 | | 470 | Diameter-EAP-Request | 471 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 472 | | MIP6_INTEGRATED) | 473 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 474 | EAP-Payload(EAP Start) | 475 |---------------------------------------------------------------->| 476 | | 477 | | 478 : ...more EAP Request/Response pairs... : 479 | | 480 | | 481 | Diameter-EAP-Answer | 482 | MIP6-Agent-Info{ | 483 | MIP-Home-Agent-Address(IPv6 address)} | 484 | MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | 485 | | MIP6_INTEGRATED) | 486 | Result-Code=DIAMETER_SUCCESS | 487 | EAP-Payload(EAP Success) | 488 | EAP-Master-Session-Key | 489 | (authorization AVPs) | 490 | ... | 491 |<----------------------------------------------------------------| 492 | | 494 Figure 3: Diameter EAP Application with MIPv6 bootstrapping 496 5.2. Integrated Scenario and HA Allocation in MSP 498 Diameter is used to authenticate and authorize the MN for the 499 mobility service, and to send information about the allocated HA to 500 the NAS. In this example scenario the MN uses DHCP for its IP 501 address configuration. 503 | 504 --------------ASP------>|<--ASA/MSA/(MSP)-- 505 | 506 +----+ +--------+ +-------+ +--------+ 507 | | |Diameter| | | | | 508 | | | Client | | | | | 509 | MN | | NAS/ | | DHCP | | Home | 510 | | | DHCP | | Server| |Diameter| 511 | | | Relay | | | | Server | 512 +-+--+ +----+---+ +---+---+ +--------+ 513 | | | | 514 | 1 | 2 | | 515 |<------------->|<----------------------->| 516 | | | | 517 | | | | 518 | 3 | | | 519 |-------------->| | | 520 | | | | 521 | | 4 | | 522 | |------------>| | 523 | | | | 524 | | 5 | | 525 | |<------------| | 526 | | | | 527 | 6 | | | 528 |<--------------| | | 529 | | | | 531 Figure 4: Mobile IPv6 Integrated Scenario Bootstrapping and the 532 allocation of HAs either in the ASP or in the MSP 534 1) The MN executes the normal network access authentication procedure 535 (IEEE 802.11i/802.1X, PANA, ...) with the NAS. The NAS acts as an 536 authenticator in "pass-through" mode. The other endpoint of the 537 authentication dialogue is the MN's home Diameter server. This is 538 a typical scenario for network access authentication using EAP 539 methods. The NAS includes at least one of the NAS to HAAA 540 interface AVPs in the DER or in the AAR messages to indicate MIPv6 541 bootstrapping capability. For example, the NAS should include the 542 MIP6-Feature-Vector AVP with a value 0x0000000000000001. 544 2) Depending on the Diameter server configuration and the user's 545 subscription profile, the MIP6-Agent-Info AVP and/or the MIP6- 546 Feature-Vector AVP may be carried in the DEA, assuming the home 547 Diameter server has allocated a HA to the MN. In case the MIP- 548 Home-Agent-Host AVP was returned within the MIP6-Agent-Info 549 grouped AVP the MN ultimately needs to perform a DNS query in 550 order to discover the HA's IP address. For example, the home 551 Diameter server could return the following AVPs: 553 o MIP6-Feature-Vector = 0x0000000000000001 554 o MIP6-Agent-Info grouped AVP containing: 555 * MIP-Home-Agent-Address = 2001:db8:6000:302::1/64 557 3) the MN sends a DHCPv6 Information Request message to 558 all_DHCP_Relay_Agents_and_Servers address. In the OPTION_ORO, 559 Option Code for the Home Network Identifier Option shall be 560 included in that message [11]. The Home Network Identifier Option 561 should have id-type of 1, the message is a request to discover 562 home network information that pertains to the given realm, i.e., 563 the user's home domain (identified by the NAI of the MN). The 564 OPTION_CLIENTID is set by the MN to identify itself to the DHCP 565 server. 567 Steps 4 to 6 are not relevant from the NAS to HAAA Diameter interface 568 point of view and are not described in this document. The reader 569 should consult [11] for a detailed description about the rest of the 570 integrated scenario bootstrapping procedure. 572 5.3. Integrated Scenario and HA Allocation in ASP 574 This scenario is similar to the one described in Section 5.2 and 575 illustrated in Figure 4. There are slight differences in steps 2) 576 and 3). 578 2) The NAS/ASP wishes to allocate a local HA to the visiting MN. The 579 NAS/ASP will also inform the Diameter server about the HA address 580 it has assigned to the visiting MN (e.g., 2001:db8:1:c020::1). In 581 this case the NAS includes the following AVPs in the DER or in the 582 AAR messages: 584 o MIP6-Feature-Vector = 0x0000000000000003 585 o MIP6-Agent-Info grouped AVP containing: 586 * MIP-Home-Agent-Address = 2001:db8:1:c020::1 588 Depending on the Diameter server configuration and user's 589 subscription profile, the Diameter server either accepts or 590 rejects the proposal of locally allocated HA in the NAS/ASP. If 591 the Diameter server accepts the proposal then the MIP6-Feature- 592 Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit set is returned 593 back to the NAS. On the other hand if the Diameter server does 594 not accept locally assigned HA, the Diameter returns the MIP6- 595 Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit unset. 596 The Diameter server assigns a HA to the MN (e.g., 597 2001:db8:6000::1) in the ASA/MSA/(MSP) and returns the IP address 598 back to the NAS/ASP. In a case the home Diameter server accepted 599 the NAS/ASP proposal of local HA the home Diameter server would 600 return, for example, the following AVPs: 602 o MIP6-Feature-Vector = 0x0000000000000003 603 o MIP6-Agent-Info grouped AVP containing: 604 * MIP-Home-Agent-Address = 2001:db8:6000::1 606 3) The type-id field in the Home Network Identifier Option is set to 607 zero, indicating that a HA is requested in the ASP instead of in 608 the MSP. Depending on the result of the phase 2) the DHCP relay 609 agent places in the OPTION_MIP6-RELAY-Option either the locally 610 allocated HA information or the HA information that was returned 611 (proposed) by home Diameter server. The selection of local or 612 home allocated HAs in based on the local policy in the ASP. It is 613 also possible that both local and home allocated HAs are available 614 for the MN. The policy and heuristics when to select the local HA 615 and when the home HA are outside of this specification. 617 6. AVP Occurrence Tables 619 6.1. AAR, AAA, DER and DEA Commands AVP Table 621 The following table lists the additional MIPv6 bootstrapping NAS to 622 HAAA interface AVPs that may optionally be present in the AAR and AAA 623 Commands [4] or in the DER and DEA Commands [5]. 625 +-----------------------+ 626 | Command-Code | 627 |-----+-----+-----+-----+ 628 Attribute Name | AAR | AAA | DER | DEA | 629 -------------------------------|-----+-----|-----+-----+ 630 MIP6-Agent-Info | 0+ | 0+ | 0+ | 0+ | 631 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 632 +-----+-----+-----+-----+ 634 Figure 5: AAR, AAA, DER and DEA Commands AVP Table 636 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs 638 This section defines AVPs that are specific to Diameter MIPv6 639 bootstrapping NAS to HAAA interface and MAY be included in the 640 Diameter EAP [5] and the NASREQ [4] application messages. The 641 Diameter AVP rules are defined in the Diameter Base [3], Section 4. 642 These AVP rules are observed in AVPs defined in this section. 644 The following table describes the Diameter AVPs, their AVP Code 645 values, types, possible flag values, and whether the AVP MAY be 646 encrypted. The Diameter base [3] specifies the AVP Flag rules for 647 AVPs in Section 4.5. 649 +---------------------+ 650 | AVP Flag rules | 651 +----+-----+----+-----+----+ 652 AVP Section | | |SHLD|MUST | | 653 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 654 ------------------------------------------+----+-----+----+-----+----+ 655 MIP6-Agent-Info TBD 4.7.1 Grouped | | P | | M,V | Y | 656 MIP-Home-Agent- | | | | | | 657 Address 334 4.7.2 Address | | P | | M,V | Y | 658 MIP-Home-Agent- | | | | | | 659 Host 348 4.7.3 Grouped | | P | | M,V | Y | 660 MIP6-Feature- | | | | | | 661 Vector TBD 4.7.4 Unsigned64 | | P | | M,V | Y | 662 ------------------------------------------+----+-----+----+-----+----+ 664 Figure 6: AVP Flag Rules Table 666 8. IANA Considerations 668 8.1. Registration of new AVPs 670 This specification defines the following new AVPs: 672 MIP6-Agent-Info is set to TBD 673 MIP6-Feature-Vector is set to TBD 675 8.2. New Registry: Mobility Capability 677 IANA is requested to create a new registry for the Mobility 678 Capability as described in Section 4.7.4. 680 Token | Value | Description 681 ----------------------------------+----------------------+------------ 682 MOBILITTY_CAPABILITY | 0x0000000000000000 | [RFC TBD] 683 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 684 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 685 Available for Assignment via IANA | 2^x | 687 Allocation rule: Only numeric values that are 2^x (power of two) are 688 allowed based on the allocation policy described below. 690 Following the policies outlined in [1] new values with a description 691 of their semantic for usage with the MIP6-Feature-Vector AVP together 692 with a Token will be assigned after Expert Review initiated by the 693 O&M Area Directors in consultation with the DIME working group chairs 694 or the working group chairs of a designated successor working group. 695 Updates can be provided based on expert approval only. A designated 696 expert will be appointed by the O&M Area Directors. No mechanism to 697 mark entries as "deprecated" is envisioned. Based on expert approval 698 it is possible to delete entries from the registry. 700 9. Security Considerations 702 The security considerations for the Diameter interaction required to 703 accomplish the integrated scenario are described in [11]. 704 Additionally, the security considerations of the Diameter base 705 protocol [3], Diameter NASREQ application [4] / Diameter EAP [5] 706 application (with respect to network access authentication and the 707 transport of keying material) are applicable to this document. This 708 document does not introduce new security vulnerabilities. 710 10. Acknowledgements 712 This document is heavily based on the ongoing work for RADIUS MIPv6 713 interaction. Hence, credits go to respective authors for their work 714 with draft-ietf-mip6-radius. Furthermore, the author would like to 715 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 716 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 717 in context of MIPv6 Diameter interworking. Their work influenced 718 this document. Jouni Korhonen would like to thank Academy of Finland 719 and TEKES MERCoNe Project for providing funding to work on this 720 document. Julien Bournelle would like to thank GET/INT since he 721 began to work on this document while he was in their employ. Authors 722 would also like to acknowledge Raymond Hsu for his valuable feedback 723 on local HA assignment and Wolfgang Fritsche for his thorough review. 725 11. References 727 11.1. Normative References 729 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 730 IPv6", RFC 3775, June 2004. 732 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 733 Levels", BCP 14, RFC 2119, March 1997. 735 [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 736 "Diameter Base Protocol", RFC 3588, September 2003. 738 [4] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 739 Network Access Server Application", RFC 4005, August 2005. 741 [5] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 742 Authentication Protocol (EAP) Application", RFC 4072, 743 August 2005. 745 [6] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 746 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 747 August 2005. 749 11.2. Informative References 751 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 752 draft-ietf-mip6-bootstrapping-split-05 (work in progress), 753 May 2007. 755 [8] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 756 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 758 [9] Giaretta, G., "AAA Goals for Mobile IPv6", 759 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 760 September 2006. 762 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 763 RFC 3753, June 2004. 765 [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 766 Integrated Scenario", 767 draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in 768 progress), June 2007. 770 Authors' Addresses 772 Jouni Korhonen 773 TeliaSonera 774 Teollisuuskatu 13 775 Sonera FIN-00051 776 Finland 778 Email: jouni.korhonen@teliasonera.com 780 Julien Bournelle 781 France Telecom R&D 782 38-4O rue du general Leclerc 783 Issy-Les-Moulineaux 92794 784 France 786 Email: julien.bournelle@orange-ftgroup.com 788 Hannes Tschofenig 789 Nokia Siemens Networks 790 Otto-Hahn-Ring 6 791 Munich, Bavaria 81739 792 Germany 794 Email: Hannes.Tschofenig@nsn.com 795 URI: http://www.tschofenig.com 797 Charles E. Perkins 798 Nokia Siemens Networks 799 313 Fairchild Drive 800 Mountain View CA 94043 801 US 803 Phone: +1 650 625-2986 804 Email: charliep@nsn.com 805 Kuntal Chowdhury 806 Starent Networks 807 30 International Place 808 Tewksbury MA 01876 809 US 811 Phone: +1 214 550 1416 812 Email: kchowdhury@starentnetworks.com 814 Full Copyright Statement 816 Copyright (C) The IETF Trust (2007). 818 This document is subject to the rights, licenses and restrictions 819 contained in BCP 78, and except as set forth therein, the authors 820 retain all their rights. 822 This document and the information contained herein are provided on an 823 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 824 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 825 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 826 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 827 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 828 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 830 Intellectual Property 832 The IETF takes no position regarding the validity or scope of any 833 Intellectual Property Rights or other rights that might be claimed to 834 pertain to the implementation or use of the technology described in 835 this document or the extent to which any license under such rights 836 might or might not be available; nor does it represent that it has 837 made any independent effort to identify any such rights. Information 838 on the procedures with respect to rights in RFC documents can be 839 found in BCP 78 and BCP 79. 841 Copies of IPR disclosures made to the IETF Secretariat and any 842 assurances of licenses to be made available, or the result of an 843 attempt made to obtain a general license or permission for the use of 844 such proprietary rights by implementers or users of this 845 specification can be obtained from the IETF on-line IPR repository at 846 http://www.ietf.org/ipr. 848 The IETF invites any interested party to bring to its attention any 849 copyrights, patents or patent applications, or other proprietary 850 rights that may cover technology that may be required to implement 851 this standard. Please address the information to the IETF at 852 ietf-ipr@ietf.org. 854 Acknowledgment 856 Funding for the RFC Editor function is provided by the IETF 857 Administrative Support Activity (IASA).