idnits 2.17.1 draft-ietf-dime-mip6-integrated-04.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 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 831. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (May 31, 2007) is 6174 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 669 ** 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. '5') (Obsoleted by RFC 7155) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 Summary: 4 errors (**), 0 flaws (~~), 4 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: December 2, 2007 H. Tschofenig 7 C. Perkins 8 Nokia Siemens Networks 9 K. Chowdhury 10 Starent Networks 11 May 31, 2007 13 Diameter Mobile IPv6: Support for Network Access Server to Diameter 14 Server Interaction 15 draft-ietf-dime-mip6-integrated-04.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 December 2, 2007. 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) . . . . . . . . . . . . . . . . 6 69 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 7 70 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 7 71 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 72 4.7. Attribute Value Pair Definitions . . . . . . . . . . . . . 9 73 4.7.1. Mobility-Agent-Info . . . . . . . . . . . . . . . . . 9 74 4.7.2. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 9 75 4.7.3. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 9 76 4.7.4. Mobility-Capability AVP . . . . . . . . . . . . . . . 9 77 5. Example Message Flows . . . . . . . . . . . . . . . . . . . . 10 78 5.1. EAP-based Authentication . . . . . . . . . . . . . . . . . 10 79 5.2. Integrated Scenario and HA Allocation in MSP . . . . . . . 11 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 . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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 [6]. The terms integrated and split are described in the 127 terminology section and were introduced in [7] and [8]. 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 [9]. The following 136 additional terms, as defined in [7], 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 [7]. 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 [10]. 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 [5], EAP [4] 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 4.3. Diameter-EAP-Request (DER) 274 The Diameter-EAP-Request (DER) message [4], indicated by the Command- 275 Code field set to 268 and the 'R' bit set in the Command Flags field, 276 is sent by the NAS to the Diameter server to initiate a network 277 access authentication and authorization procedure. The DER message 278 format is the same as defined in [4]. The message MAY include 279 optional MIPv6 bootstrapping AVPs: 281 ::= < Diameter Header: 268, REQ, PXY > 282 < Session-Id > 283 { Auth-Application-Id } 284 { Origin-Host } 285 { Origin-Realm } 286 { Destination-Realm } 287 { Auth-Request-Type } 289 * [ Mobility-Agent-Info ] 290 [ Mobility-Capability ] 292 [ Destination-Host ] 293 ... 294 * [ AVP ] 296 4.4. Diameter-EAP-Answer (DEA) 298 The Diameter-EAP-Answer (DEA) message defined in [4], indicated by 299 the Command-Code field set to 268 and 'R' bit cleared in the Command 300 Flags field, is sent in response to the Diameter-EAP-Request message 301 (DER). If the network access authentication procedure was successful 302 then the response MAY include any set of bootstrapping AVPs. 304 The DEA message format is the same as defined in [4] with an addition 305 of optional MIPv6 bootstrapping AVPs: 307 ::= < Diameter Header: 268, PXY > 308 < Session-Id > 309 { Auth-Application-Id } 310 { Auth-Request-Type } 311 { Result-Code } 312 { Origin-Host } 313 { Origin-Realm } 315 * [ Mobility-Agent-Info ] 316 [ Mobility-Capability ] 318 [ User-Name ] 319 ... 320 * [ AVP ] 322 4.5. AA-Request (AAR) 324 The AA-Request (AAR) message [5], indicated by the Command-Code field 325 set to 265 and 'R' bit set in the Command Flags field, is sent by the 326 NAS to the Diameter server to initiate a network access 327 authentication and authorization procedure. The AAR message format 328 is the same as defined in [5]. The message MAY include optional 329 MIPv6 bootstrapping AVPs: 331 ::= < Diameter Header: 265, REQ, PXY > 332 < Session-Id > 333 { Auth-Application-Id } 334 { Origin-Host } 335 { Origin-Realm } 336 { Destination-Realm } 337 { Auth-Request-Type } 339 * [ Mobility-Agent-Info ] 340 [ Mobility-Capability ] 342 [ Destination-Host ] 343 ... 344 * [ AVP ] 346 4.6. AA-Answer (AAA) 348 The AA-Answer (AAA) message, indicated by the Command-Code field set 349 to 265 and 'R' bit cleared in the Command Flags field is sent in 350 response to the AA-Request (AAR) message for confirmation of the 351 result of MIPv6 HA bootstrapping. If the network access 352 authentication procedure was successful then the response MAY include 353 any set of bootstrapping AVPs. 355 The AAA message format is the same as defined in [5] with an addition 356 of optional MIPv6 bootstrapping AVPs: 358 ::= < Diameter Header: 265, PXY > 359 < Session-Id > 360 { Auth-Application-Id } 361 { Auth-Request-Type } 362 { Result-Code } 363 { Origin-Host } 364 { Origin-Realm } 366 * [ Mobility-Agent-Info ] 367 [ Mobility-Capability ] 369 [ User-Name ] 370 ... 371 * [ AVP ] 373 4.7. Attribute Value Pair Definitions 375 4.7.1. Mobility-Agent-Info 377 The Mobility-Agent-Info AVP (AVP code TBD) is type of Grouped and 378 contains necessary information to assign a HA to the MN. When the 379 Mobility-Agent-Info AVP is present in a message, it MUST contain 380 either a MIP6-Home-Agent-Address AVP or a MIP6-Home-Agent-FQDN AVP, 381 but not both. The grouped AVP has the following grammar: 383 ::= < AVP Header: TBD > 384 [ MIP6-Home-Agent-Address ] 385 [ MIP6-Home-Agent-FQDN ] 386 * [ AVP ] 388 4.7.2. MIP6-Home-Agent-Address AVP 390 The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type Address 391 (see Section 4.3 in [3]) and contains the HA address. The Diameter 392 server MAY decide to assign a HA to the MN that is in close proximity 393 to the point of attachment (e.g., determined by the NAS-Identifier 394 AVP). There may be other reasons for dynamically assigning HAs to 395 the MN, for example to share the traffic load. 397 This AVP MAY also be attached by the NAS when sent to the Diameter 398 server in a request message as a hint of a locally assigned HA 399 address. 401 4.7.3. MIP6-Home-Agent-FQDN AVP 403 The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and 404 contains the FQDN of a HA. The usage of this AVP is equivalent to 405 the MIP6-Home-Agent-Address AVP but offers an additional level of 406 indirection via the DNS infrastructure. 408 4.7.4. Mobility-Capability AVP 410 The Mobility-Capability AVP (AVP Code TBD) is of type Unsigned64 and 411 contains a 64 bits flags field of supported capabilities of the NAS/ 412 ASP. Sending and receiving the Mobility-Capability AVP with value 0 413 MUST be supported. 415 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 416 to the Diameter server. For example, the NAS may indicate that a 417 local home agent can be provided. Similarly, the Diameter server MAY 418 include this AVP to inform the NAS/ASP about which of the NAS/ASP 419 indicated capabilities are supported or authorized by the ASA/MSA(/ 420 MSP). 422 The following capabilities are defined in this document: 424 MOBILITY_CAPABILITY (0x0000000000000000) 426 The Mobility-Capability AVP MAY contain value 0 (zero) with the 427 semantics that are defined in this document for the Mobile IPv6 428 bootstrapping functionality. This 'zero' flag is always 429 implicitly set when the Mobility-Capability AVP is used. 431 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000001) 433 This flag is set by the NAS/ASP when a local home agent can be 434 assigned to the MN. This flag is set by the ASA/MSA(/MSP) when 435 the use of a local HA is authorized. 437 5. Example Message Flows 439 5.1. EAP-based Authentication 441 This section shows basic message flows of MIPv6 integrated scenario 442 bootstrapping and dynamic HA assignment. In Figure 3 network access 443 authentication is based on EAP (e.g., 802.11i/802.1X). The NAS 444 informs the home Diameter server that it wishes to provide a locally 445 assigned HA to the visiting MN. The Diameter server assigns the MN a 446 HA in the home MSP but also authorizes the assignment of local HA for 447 the ASP. The Diameter server then replies to the NAS with HA related 448 bootstrapping information. Whether the NAS/ASP then offers a locally 449 assigned HA or the MSP assigned HA to the MN is based on the local 450 ASP policy. 452 NAS Home server 453 | | 454 | Diameter-EAP-Request | 455 | Mobility-Capability=LOCAL_HOME_AGENT_ASSIGNMENT | 456 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 457 | EAP-Payload(EAP Start) | 458 |---------------------------------------------------------------->| 459 | | 460 | | 461 : ...more EAP Request/Response pairs... : 462 | | 463 | | 464 | Diameter-EAP-Answer | 465 | Mobility-Agent-Info{ | 466 | MIP6-Home-Agent-Address(IPv6 address) | 467 | MIP6-Home-Agent-FQDN=ha.example.com } | 468 | Mobility-Capability=LOCAL_HOME_AGENT_ASSIGNMENT | 469 | Result-Code=DIAMETER_SUCCESS | 470 | EAP-Payload(EAP Success) | 471 | EAP-Master-Session-Key | 472 | (authorization AVPs) | 473 | ... | 474 |<----------------------------------------------------------------| 475 | | 477 Figure 3: Diameter EAP Application with MIPv6 bootstrapping 479 5.2. Integrated Scenario and HA Allocation in MSP 481 Diameter is used to authenticate and authorize the MN for the 482 mobility service, and to send information about the allocated HA to 483 the NAS. In this example scenario the MN uses DHCP for its IP 484 address configuration. 486 | 487 --------------ASP------>|<--ASA/MSA/(MSP)-- 488 | 489 +----+ +--------+ +-------+ +--------+ 490 | | |Diameter| | | | | 491 | | | Client | | | | | 492 | MN | | NAS/ | | DHCP | | Home | 493 | | | DHCP | | Server| |Diameter| 494 | | | Relay | | | | Server | 495 +-+--+ +----+---+ +---+---+ +--------+ 496 | | | | 497 | 1 | 2 | | 498 |<------------->|<----------------------->| 499 | | | | 500 | | | | 501 | 3 | | | 502 |-------------->| | | 503 | | | | 504 | | 4 | | 505 | |------------>| | 506 | | | | 507 | | 5 | | 508 | |<------------| | 509 | | | | 510 | 6 | | | 511 |<--------------| | | 512 | | | | 514 Figure 4: Mobile IPv6 Integrated Scenario Bootstrapping and the 515 allocation of HAs either in the ASP or in the MSP 517 1) The MN executes the normal network access authentication procedure 518 (IEEE 802.11i/802.1X, PANA, ...) with the NAS. The NAS acts as an 519 authenticator in "pass-through" mode. The other endpoint of the 520 authentication dialogue is the MN's home Diameter server. This is 521 a typical scenario for network access authentication using EAP 522 methods. The NAS includes at least one of the NAS to HAAA 523 interface AVPs in the DER or in the AAR messages to indicate MIPv6 524 bootstrapping capability. For example, the NAS could include the 525 Mobility-Capability AVP with a value 0. 527 2) Depending on the Diameter server configuration and the user's 528 subscription profile, the Mobility-Agent-Info AVP and/or the 529 Mobility-Capability AVP may be carried in the DEA, assuming the 530 home Diameter server has allocated a HA to the MN. In case the 531 MIP6-Home-Agent-FQDN AVP was returned within the Mobility-Agent- 532 Info grouped AVP the MN ultimately needs to perform a DNS query in 533 order to discover the HA's IP address. For example, the home 534 Diameter server could return the following AVPs: 536 o Mobility-Agent-Info grouped AVP containing: 537 * MIP6-Home-Agent-Address = 2001:db8:6000:302::1/64 538 * MIP6-Home-Agent-FQDN = ha.example.com 540 3) the MN sends a DHCPv6 Information Request message to 541 all_DHCP_Relay_Agents_and_Servers address. In the OPTION_ORO, 542 Option Code for the Home Network Identifier Option shall be 543 included in that message [10]. The Home Network Identifier Option 544 should have id-type of 1, the message is a request to discover 545 home network information that pertains to the given realm, i.e., 546 the user's home domain (identified by the NAI of the MN). The 547 OPTION_CLIENTID is set by the MN to identify itself to the DHCP 548 server. 550 Steps 4 to 6 are not relevant from the NAS to HAAA Diameter interface 551 point of view and are not described in this document. The reader 552 should consult [10] for a detailed description about the rest of the 553 integrated scenario bootstrapping procedure. 555 5.3. Integrated Scenario and HA Allocation in ASP 557 This scenario is similar to the one described in Section 5.2 and 558 illustrated in Figure 4. There are slight differences in steps 2) 559 and 3). 561 2) The NAS/ASP wishes to allocate a local HA to the visiting MN. The 562 NAS/ASP will also inform the Diameter server about the HA address 563 it has assigned to the visiting MN (e.g., 2001:db8:1:c020::1). In 564 this case the NAS includes the following AVPs in the DER or in the 565 AAR messages: 567 o Mobility-Capability = LOCAL_HOME_AGENT_ASSIGNMENT 568 o Mobility-Agent-Info grouped AVP containing: 569 * MIP6-Home-Agent-Address = 2001:db8:1:c020::1 571 Depending on the Diameter server configuration and user's 572 subscription profile, the Diameter server either accepts or 573 rejects the proposal of locally allocated HA in the NAS/ASP. If 574 the Diameter server accepts the proposal then the Mobility- 575 Capability AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit set is 576 returned back to the NAS. On the other hand if the Diameter 577 server does not accept locally assigned HA, the Diameter returns 578 the Mobility-Capability AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit 579 unset. The Diameter server assigns a HA to the MN (e.g., 2001: 580 db8:6000::1) in the ASA/MSA/(MSP) and returns the IP address back 581 to the NAS/ASP. In a case the home Diameter server accepted the 582 NAS/ASP proposal of local HA the home Diameter server would 583 return, for example, the following AVPs: 585 o Mobility-Capability = LOCAL_HOME_AGENT_ASSIGNMENT 586 o Mobility-Agent-Info grouped AVP containing: 587 * MIP6-Home-Agent-Address = 2001:db8:6000::1 589 3) The type-id field in the Home Network Identifier Option is set to 590 zero, indicating that a HA is requested in the ASP instead of in 591 the MSP. Depending on the result of the phase 2) the DHCP relay 592 agent places in the OPTION_MIP6-RELAY-Option either the locally 593 allocated HA information or the HA information that was returned 594 (proposed) by home Diameter server. The selection of local or 595 home allocated HAs in based on the local policy in the ASP. It is 596 also possible that both local and home allocated HAs are available 597 for the MN. The policy and heuristics when to select the local HA 598 and when the home HA are outside of this specification. 600 6. AVP Occurrence Tables 602 6.1. AAR, AAA, DER and DEA Commands AVP Table 604 The following table lists the additional MIPv6 bootstrapping NAS to 605 HAAA interface AVPs that may optionally be present in the AAR and AAA 606 Commands [5] or in the DER and DEA Commands [4]. 608 +-----------------------+ 609 | Command-Code | 610 |-----+-----+-----+-----+ 611 Attribute Name | AAR | AAA | DER | DEA | 612 -------------------------------|-----+-----|-----+-----+ 613 Mobility-Agent-Info | 0+ | 0+ | 0+ | 0+ | 614 Mobility-Capability | 0-1 | 0-1 | 0-1 | 0-1 | 615 +-----+-----+-----+-----+ 617 Figure 5: AAR, AAA, DER and DEA Commands AVP Table 619 7. MIPv6 Bootstrapping NAS to HAAA Interface AVPs 621 This section defines AVPs that are specific to Diameter MIPv6 622 bootstrapping NAS to HAAA interface and MAY be included in the 623 Diameter EAP [4] and the NASREQ [5] application messages. The 624 Diameter AVP rules are defined in the Diameter Base [3], Section 4. 625 These AVP rules are observed in AVPs defined in this section. 627 The following table describes the Diameter AVPs, their AVP Code 628 values, types, possible flag values, and whether the AVP MAY be 629 encrypted. The Diameter base [3] specifies the AVP Flag rules for 630 AVPs in Section 4.5. 632 +---------------------+ 633 | AVP Flag rules | 634 +----+-----+----+-----+----+ 635 AVP Section | | |SHLD|MUST | | 636 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 637 ------------------------------------------+----+-----+----+-----+----+ 638 Mobility- | | | | | | 639 Agent-Info TBD 4.7.1 Grouped | | P | | M,V | Y | 640 MIP6-Home-Agent- | | | | | | 641 Address TBD 4.7.2 Address | | P | | M,V | Y | 642 MIP6-Home-Agent- | | | | | | 643 FQDN TBD 4.7.3 UTF8String | | P | | M,V | Y | 644 Mobility- | | | | | | 645 Capability TBD 4.7.4 Unsigned64 | | P | | M,V | Y | 646 ------------------------------------------+----+-----+----+-----+----+ 648 Figure 6: AVP Flag Rules Table 650 8. IANA Considerations 652 8.1. Registration of new AVPs 654 This specification defines the following new AVPs: 656 Mobility-Agent-Info is set to TBD 657 MIP6-Home-Agent-Address is set to TBD 658 MIP6-Home-Agent-FQDN is set to TBD 659 Mobility-Capability is set to TBD 661 8.2. New Registry: Mobility Capability 663 IANA is requested to create a new registry for the Mobility 664 Capability as described in Section 4.7.4. 666 Token | Value | Description 667 ----------------------------------+----------------------+------------ 668 MOBILITTY_CAPABILITY | 0x0000000000000000 | [RFC TBD] 669 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000001 | [RFC TBD] 670 Available for Assignment via IANA | 2^x | 672 Allocation rule: Only numeric values that are 2^x (power of two) are 673 allowed based on the allocation policy described below. 675 Following the policies outlined in [1] new values with a description 676 of their semantic for usage with the Mobility-Capability AVP together 677 with a Token will be assigned after Expert Review initiated by the 678 O&M Area Directors in consultation with the DIME working group chairs 679 or the working group chairs of a designated successor working group. 680 Updates can be provided based on expert approval only. A designated 681 expert will be appointed by the O&M Area Directors. No mechanism to 682 mark entries as "deprecated" is envisioned. Based on expert approval 683 it is possible to delete entries from the registry. 685 9. Security Considerations 687 The security considerations for the Diameter interaction required to 688 accomplish the integrated scenario are described in [10]. 689 Additionally, the security considerations of the Diameter base 690 protocol [3], Diameter NASREQ application [5] / Diameter EAP [4] 691 application (with respect to network access authentication and the 692 transport of keying material) are applicable to this document. This 693 document does not introduce new security vulnerabilities. 695 10. Acknowledgements 697 This document is heavily based on the ongoing work for RADIUS MIPv6 698 interaction. Hence, credits go to respective authors for their work 699 with draft-ietf-mip6-radius. Furthermore, the author would like to 700 thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le, 701 Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work 702 in context of MIPv6 Diameter interworking. Their work influenced 703 this 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] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 722 Authentication Protocol (EAP) Application", RFC 4072, 723 August 2005. 725 [5] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 726 Network Access Server Application", RFC 4005, August 2005. 728 11.2. Informative References 730 [6] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 731 draft-ietf-mip6-bootstrapping-split-04 (work in progress), 732 December 2006. 734 [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 735 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 737 [8] Giaretta, G., "AAA Goals for Mobile IPv6", 738 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 739 September 2006. 741 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 742 RFC 3753, June 2004. 744 [10] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 745 Integrated Scenario", 746 draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in 747 progress), February 2007. 749 Authors' Addresses 751 Jouni Korhonen 752 TeliaSonera 753 Teollisuuskatu 13 754 Sonera FIN-00051 755 Finland 757 Email: jouni.korhonen@teliasonera.com 759 Julien Bournelle 760 France Telecom R&D 761 38-4O rue du general Leclerc 762 Issy-Les-Moulineaux 92794 763 France 765 Email: julien.bournelle@orange-ftgroup.com 766 Hannes Tschofenig 767 Nokia Siemens Networks 768 Otto-Hahn-Ring 6 769 Munich, Bavaria 81739 770 Germany 772 Email: Hannes.Tschofenig@nsn.com 773 URI: http://www.tschofenig.com 775 Charles E. Perkins 776 Nokia Siemens Networks 777 313 Fairchild Drive 778 Mountain View CA 94043 779 US 781 Phone: +1 650 625-2986 782 Email: charliep@nsn.com 784 Kuntal Chowdhury 785 Starent Networks 786 30 International Place 787 Tewksbury MA 01876 788 US 790 Phone: +1 214 550 1416 791 Email: kchowdhury@starentnetworks.com 793 Full Copyright Statement 795 Copyright (C) The IETF Trust (2007). 797 This document is subject to the rights, licenses and restrictions 798 contained in BCP 78, and except as set forth therein, the authors 799 retain all their rights. 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 804 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 805 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 806 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Intellectual Property 811 The IETF takes no position regarding the validity or scope of any 812 Intellectual Property Rights or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; nor does it represent that it has 816 made any independent effort to identify any such rights. Information 817 on the procedures with respect to rights in RFC documents can be 818 found in BCP 78 and BCP 79. 820 Copies of IPR disclosures made to the IETF Secretariat and any 821 assurances of licenses to be made available, or the result of an 822 attempt made to obtain a general license or permission for the use of 823 such proprietary rights by implementers or users of this 824 specification can be obtained from the IETF on-line IPR repository at 825 http://www.ietf.org/ipr. 827 The IETF invites any interested party to bring to its attention any 828 copyrights, patents or patent applications, or other proprietary 829 rights that may cover technology that may be required to implement 830 this standard. Please address the information to the IETF at 831 ietf-ipr@ietf.org. 833 Acknowledgment 835 Funding for the RFC Editor function is provided by the IETF 836 Administrative Support Activity (IASA).