idnits 2.17.1 draft-ietf-dime-mip6-integrated-01.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 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 898. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (June 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-01 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-03 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-02 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 5 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: Informational GET/INT 6 Expires: December 3, 2006 H. Tschofenig 7 Siemens 8 C. Perkins 9 Nokia 10 K. Chowdhury 11 Starent Networks 12 June 2006 14 The NAS - HAAA Interface for MIPv6 Bootstrapping 15 draft-ietf-dime-mip6-integrated-01.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 3, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 A Mobile IPv6 node requires a home agent address, a home address, and 49 IPsec security association with its home agent before it can start 50 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 51 these parameters are statically configured. Ongoing Mobile IPv6 52 bootstrapping work aims to make this information dynamically 53 available to the mobile node. An important aspect of the Mobile IPv6 54 bootstrapping solution is to support interworking with existing 55 authentication, authorization and accounting infrastructure. This 56 document describes the usage of Diameter to facilitate Mobile IPv6 57 bootstrapping for the NAS - HAAA interface. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Commands, AVPs and Advertising Application Support . . . . . . 6 65 4.1. Advertising Application Support . . . . . . . . . . . . . 6 66 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 7 68 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 7 69 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 8 70 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 9 71 4.7. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.7.1. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 10 73 4.7.2. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 10 74 4.7.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 10 75 4.7.4. MIP4-Home-Agent-Address AVP . . . . . . . . . . . . . 11 76 4.8. Capability Advertisement . . . . . . . . . . . . . . . . . 11 77 5. Diameter Client and Server Behavior During MIPv6 78 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Client (NAS) Behavior . . . . . . . . . . . . . . . . . . 12 80 5.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 13 81 5.3. Example Message Flows . . . . . . . . . . . . . . . . . . 14 82 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 15 83 6.1. DER and DEA Commands AVP Table . . . . . . . . . . . . . . 15 84 6.2. AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 16 85 7. MIPv6 Bootstrapping NAS - HAAA Interface AVPs . . . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 89 11. Revision history . . . . . . . . . . . . . . . . . . . . . . . 18 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 Intellectual Property and Copyright Statements . . . . . . . . . . 21 96 1. Introduction 98 Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to 99 perform registration with a home agent with information about its 100 current point of attachment (Care-of Address). The home agent 101 creates and maintains binding between the MN's Home Address and the 102 MN's Care-of Address. 104 In order to register with a home agent, the MN needs to know some 105 information such as, the Home Link prefix, the home agent Address, 106 the Home Address(es), the Home Link prefix Length and security 107 related information in order to later secure the Binding Update. 109 The aforementioned set of information may be statically provisioned 110 in the MN. However, static provisioning of this information has its 111 drawbacks. It increases provisioning and network maintenance becomes 112 easily burden for an operator. Moreover, static provisioning does 113 not allow load balancing, failover, opportunistic home link 114 assignment etc. For example, the user may be accessing the network 115 from a location that may be geographically far away from the 116 preconfigured home link; the administrative burden to configure the 117 MNs with the respective addresses is large and the ability to react 118 on environmental changes is minimal. In these situations static 119 provisioning may not be desirable. 121 Dynamic assignment of Mobile IPv6 home registration information is a 122 desirable feature for ease of deployment and network maintenance. 123 For this purpose, the Diameter infrastructure, which is used for 124 access authentication, can be leveraged to assign some or all of the 125 necessary parameters. The Diameter server in Access Service 126 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 127 return these parameters to the AAA client. Regarding the 128 bootstrapping procedures, the AAA client might either be the NAS, in 129 case of the integrated scenario, or the home agent, in case of the 130 split scenario [I-D.ietf-mip6-bootstrapping-split]. The terms 131 integrated and split are described in the terminology section and 132 were introduced in [RFC4640] and [I-D.ietf-mip6-aaa-ha-goals]. 134 2. Terminology and Abbreviations 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC2119 [RFC2119]. 140 General mobility terminology can be found in [RFC3753]. The 141 following additional terms, as defined in [RFC4640], are used in this 142 document: 144 Access Service Authorizer (ASA): 146 A network operator that authenticates a mobile node and 147 establishes the mobile node's authorization to receive Internet 148 service. 150 Access Service Provider (ASP): 152 A network operator that provides direct IP packet forwarding to 153 and from the mobile node. 155 Mobility Service Authorizer (MSA): 157 A service provider that authorizes Mobile IPv6 service. 159 Mobility Service Provider (MSP): 161 A service provider that provides Mobile IPv6 service. In order to 162 obtain such service, the mobile node must be authenticated and 163 authorized to obtain the Mobile IPv6 service. 165 Split scenario: 167 A scenario where the mobility service and the network access 168 service are authorized by different entities. 170 Integrated Scenario: 172 A scenario where the mobility service and the network access 173 service are authorized by the same entity. 175 Network Access Server (NAS): 177 A device that provides an access service for a user to a network. 179 Home AAA (HAAA): 181 An authentication, authorization and accounting server located in 182 user's home network. 184 3. Overview 186 This document addresses the authentication, authorization and 187 accounting functionality required by for the MIPv6 bootstrapping as 188 outlined in the MIPv6 bootstrapping problem statement document (see 189 [RFC4640]). This document focuses on the AAA functionality for the 190 NAS - HAAA interface. 192 The subsequent text outlines the AAA interaction between the 193 participating entities in the integrated scenario. In the integrated 194 scenario MIPv6 bootstrapping is provided as part of the network 195 access authentication procedure. Figure 1 shows the participating 196 entities. This document, however, only concentrates on the NAS, 197 possible local Diameter proxies and the home Diameter server. 199 +---------------------------+ +-----------------+ 200 |Access Service Provider | |ASA/MSA/(MSP) | 201 |(Mobility Service Provider)| | | 202 | | | | 203 | +--------+ | | +--------+ | 204 | |Local | Diameter | | |Home | | 205 | |Diameter|<---------------------->|Diameter| | 206 | |Proxy | | | |Server | | 207 | +--------+ | | +--------+ | 208 | ^ | | ^ | 209 | | | | | | 210 | | | | | | 211 | |Diameter | | v | 212 | | +-------+ | | +-------+ | 213 | | |Home | | | |Home | | 214 | | +---->|Agent | | | |Agent | | 215 | | | |in ASP | | | |in MSP | | 216 | v v +-------+ | | +-------+ | 217 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 218 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 219 |Node |----------+-|Diameter |---|Server | | 220 | | PANA,... | |Client | | | | 221 +-------+ DHCP | +-----------+ +-------+ | 222 +---------------------------+ 224 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 226 In a typical Mobile IPv6 access scenario, as shown above, the MN is 227 attached to an ASP's network. During the network attachment 228 procedure, the NAS/Diameter client interacts with the mobile node. 229 As shown in Figure 1, the authentication and authorization happens 230 via the Diameter infrastructure. 232 At the time of authentication the user for the network access, the 233 Diameter server in the MSA detects that the user is also authorized 234 for Mobile IPv6 access. Based on the MSA's policy, the Diameter 235 server may allocate several parameters to the MN for use during the 236 subsequent Mobile IPv6 protocol interaction with the home agent. 238 Depending on the details of the solution interaction with the DHCPv6 239 server may be required, as described in 240 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. However, the solution 241 described in this document is not dependant on the DHCPv6 as the only 242 possible MIPv6 bootstrapping method. 244 4. Commands, AVPs and Advertising Application Support 246 This section describes command codes, defines AVPs and advertised 247 application identifiers for the Diameter MIPv6 bootstrapping in the 248 NAS - HAAA interface. 250 4.1. Advertising Application Support 252 Diameter nodes conforming to this specification SHOULD include the 253 value of 1 (NASREQ application) or 5 (EAP application) in the Auth- 254 Application-Id or the Acct-Application-Id AVP of the Capabilities- 255 Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588]. 257 The value of zero (0) SHOULD be used as the Application-Id in all 258 STR/STA, ACR/ACA, ASR/ASA, and RAR/RAA commands, because these 259 commands are defined in the Diameter base protocol and no additional 260 mandatory AVPs for those commands are defined in this document. 262 4.2. Command Codes 264 This document re-uses the Diameter Base protocol [RFC3588], Diameter 265 NASREQ application [RFC4072] and EAP commands . The following 266 commands are used to carry MIPv6 related bootstrapping AVPs: 268 Command-Name Abbrev. Code Reference Application 270 Diameter-EAP-Request DER 268 RFC 4072 EAP 271 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 273 AA-Request AAR 265 RFC 4005 NASREQ 274 AA-Answer AAA 265 RFC 4005 NASREQ 276 Figure 2: MIPv6 Bootstrapping NAS - HAAA Interface Command Codes 278 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 279 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 280 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 281 (ACR), and Accounting-Answer (ACA) commands are used together with 282 the Diameter MIPv6 bootstrapping NAS - HAAA interface, they follow 283 the rules in the Diameter NASREQ [RFC4005], EAP [RFC4072] and BASE 285 [RFC3588] applications. The accounting commands use Application 286 Identifier value of 3 (Diameter Base Accounting); the others use 0 287 (Diameter Common Messages). 289 4.3. Diameter-EAP-Request (DER) 291 The Diameter-EAP-Request (DER) command [RFC4072], indicated by the 292 Command-Code field set to 268 and the 'R' bit set in the Command 293 Flags field, may be sent by the NAS to the Diameter server providing 294 network access authentication and authorization services. At the 295 same time with the network access authentication and authorization 296 the NAS MAY indicate the access network capability of MIPv6 297 bootstrapping and optionally also the capability of a local home 298 agent assignment. 300 The message format is the same as defined in [RFC4072] with an 301 addition of possible MIPv6 bootstrapping NAS - HAAA interface AVPs to 302 indicate capabilities of the NAS and ASP: 304 ::= < Diameter Header: 268, REQ, PXY > 305 < Session-Id > 306 { Auth-Application-Id } 307 { Origin-Host } 308 { Origin-Realm } 309 { Destination-Realm } 310 { Auth-Request-Type } 312 [ MIP6-Home-Agent-Address ] 313 [ MIP6-Home-Agent-FQDN ] 314 [ MIP6-Home-Link-Prefix ] 315 [ MIP4-Home-Agent-Address ] 317 [ Destination-Host ] 318 ... 319 * [ AVP ] 321 Figure 3: Diameter EAP Request Command 323 4.4. Diameter-EAP-Answer (DEA) 325 The Diameter-EAP-Answer (DEA) message define in [RFC4072], indicated 326 by the Command-Code field set to 268 and 'R' bit cleared in the 327 Command Flags field is sent in response to the Diameter-EAP-Request 328 message (DER). If the network access was successfully authenticated 329 then the response SHOULD include the MIP6-Home-Agent-Address AVP, 330 MIP6-Home-Link-Prefix, MIP6-Home-Agent-FQDN and MIP4-Home-Agent- 331 address AVPs. 333 The message format is the same as defined in [RFC4072] with an 334 addition of MIPv6 bootstrapping NAS - HAAA interface AVPs: 336 ::= < Diameter Header: 268, PXY > 337 < Session-Id > 338 { Auth-Application-Id } 339 { Auth-Request-Type } 340 { Result-Code } 341 { Origin-Host } 342 { Origin-Realm } 344 [ MIP6-Home-Agent-Address ] 345 [ MIP6-Home-Agent-FQDN ] 346 [ MIP6-Home-Link-Prefix ] 347 [ MIP4-Home-Agent-Address ] 349 [ User-Name ] 350 ... 351 * [ AVP ] 353 Figure 4: Diameter EAP Answer Command 355 4.5. AA-Request (AAR) 357 The AA-Request (AAR) message, indicated by the Command-Code field set 358 to 265 and 'R' bit set in the Command Flags field, may be sent by the 359 NAS to the Diameter server providing network access configuration 360 services. At the same time with the network access configuration the 361 NAS MAY request home agent assignment, to authorize for mobility 362 service usage and optionally to indicate the support of possible 363 local home agent assignment. 365 The message format is the same as defined in [RFC4005] with an 366 addition of MIPv6 bootstrapping NAS - HAAA interface AVPs: 368 ::= < Diameter Header: 265, REQ, PXY > 369 < Session-Id > 370 { Auth-Application-Id } 371 { Origin-Host } 372 { Origin-Realm } 373 { Destination-Realm } 374 { Auth-Request-Type } 376 [ MIP6-Home-Agent-Address ] 377 [ MIP6-Home-Agent-FQDN ] 378 [ MIP6-Home-Link-Prefix ] 379 [ MIP4-Home-Agent-Address ] 381 [ Destination-Host ] 382 ... 383 * [ AVP ] 385 Figure 5: AA Request Command 387 4.6. AA-Answer (AAA) 389 The AA-Answer (AAA) message, indicated by the Command-Code field set 390 to 265 and 'R' bit cleared in the Command Flags field is sent in 391 response to the AA-Request (AAR) message for confirmation of the 392 result of MIPv6 HA bootstrapping. If the network access was 393 successfully authenticated then the response SHOULD include the MIP6- 394 Home-Agent-Address AVP, MIP6-Home-Link-Prefix, MIP6-Home-Agent-FQDN 395 and MIP4-Home-Agent-address AVPs. 397 The message format is the same as defined in [RFC4005] with an 398 addition of MIPv6 bootstrapping NAS - HAAA interface AVPs: 400 ::= < Diameter Header: 265, PXY > 401 < Session-Id > 402 { Auth-Application-Id } 403 { Auth-Request-Type } 404 { Result-Code } 405 { Origin-Host } 406 { Origin-Realm } 408 [ MIP6-Home-Agent-Address ] 409 [ MIP6-Home-Agent-FQDN ] 410 [ MIP6-Home-Link-Prefix] 411 [ MIP4-Home-Agent-address ] 413 [ User-Name ] 414 ... 415 * [ AVP ] 417 Figure 6: AA Answer Command 419 4.7. New AVPs 421 4.7.1. MIP6-Home-Agent-Address AVP 423 The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 424 and contains the Mobile IPv6 home agent address and the prefix length 425 of the said address. The AVP is a discriminated union, representing 426 IPv6 address in network byte order. The first two octets of this AVP 427 represents the home link prefix length followed by 16 octets of the 428 IPv6 address. 430 The Diameter server MAY decide to assign a MIPv6 home agent to the MN 431 that is in close proximity to the point of attachment (e.g. 432 determined by the NAS-Identifier). There may be other reasons for 433 dynamically assigning home agents to the MN, for example to share the 434 traffic load. The AVP also contains the prefix length so that the MN 435 can easily infer one of the possible Home Link prefixes from the home 436 agent address. 438 4.7.2. MIP6-Home-Agent-FQDN AVP 440 The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and 441 contains the FQDN of a Mobile IPv6 home agent. 443 4.7.3. MIP6-Home-Link-Prefix AVP 445 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 446 and contains the Mobile IPv6 home link prefix. There may be reasons 447 for the Diameter server to dynamically assigning home link prefix to 448 the MN, for example one that is in close proximity to the point of 449 attachment. 451 4.7.4. MIP4-Home-Agent-Address AVP 453 The MIP4-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 454 and contains the IPv4 home agent address and the prefix length of the 455 said address. The AVP is a discriminated union, representing IPv4 456 address in network byte order. The first two octets of this AVP 457 represents the home link prefix length followed by 4 octets of the 458 IPv4 address. 460 The Diameter server MAY decide to assign a MIPv4 home agent to the MN 461 in a case where dual stack Mobile IP is supported 462 [I-D.ietf-mip6-nemo-v4traversal]. 464 4.8. Capability Advertisement 466 The NAS/ASP may include any MIPv6 bootstrapping AVPs in the Diameter 467 EAP or NASREQ application request messages to advertise its MIPv6 468 bootstrapping capabilities to the Diameter server. The use of 469 capability advertisement is optional. 471 The capability advertisement may also be used as an explicit hint to 472 the Diameter server about locally allocated mobility agents or home 473 links. In this case e.g. the MIP6-Home-Agent-Address AVP would 474 contain the IP address of the locally allocated home agent. If the 475 NAS/ASP does not have any specific home agent to offer during the 476 access authentication time the IP address in the respective 477 bootstrapping AVPs MUST be set to unspecified address (::/128). The 478 MIP6-Home-Agent-FQDN SHOULD NOT be used for the capability 479 advertisement if it does not already name a locally allocated Home 480 Agent. 482 5. Diameter Client and Server Behavior During MIPv6 Bootstrapping 484 This section describes the Diameter server and client behavior in 485 case of the MIPv6 bootstrapping in the integrated scenario. The text 486 does several assumptions for brevity. 488 o The Diameter server is assumed to support at least the Diameter 489 BASE, EAP and NASREQ applications. 490 o The Diameter client (i.e. the NAS) is assumed to support at least 491 the Diameter BASE, EAP and NASREQ applications. 493 o The MN uses such network access authentication method and 494 credentials that are supported by the NAS/ASP and ASA/MSA. 495 o The MN has been provisioned with a Mobile IPv6 service. 496 o The capability exchange has already completed, thus the NAS and 497 the Diameter server share the knowledge of mutually supported 498 applications. Cases where the ASA/MSA do not support MIPv6 499 bootstrapping are not discussed. In these cases the NAS has no 500 other choice than to carry out the network access authentication 501 as defined in the Diameter EAP or NASREQ applications. 503 5.1. Client (NAS) Behavior 505 If the ASP/NAS does not support MIPv6 integrated scenario 506 bootstrapping then the NAS either selects the basic Diameter NASREQ 507 or EAP application depending on which authentication method gets 508 used. Naturally after a successful or a failed authentication the 509 NAS does not have to carry out any MIPv6 bootstrapping related 510 procedures. 512 Next we describe two different scenarios for the network access 513 authentication when the ASP/NAS supports MIPv6 integrated scenario 514 bootstrapping. 516 1) The MN uses some EAP-based method (e.g. 802.11i/802.1X) to 517 authenticate to the network. In this scenario the NAS uses 518 commands originally defined for the EAP application. 519 2) The MN uses some other than EAP-based method to authenticate to 520 the network. In this scenario the NAS uses the Diameter NASREQ 521 application commands. 523 The NAS may include the MIPv6 NAS - HAAA AVPs in the DER or in the 524 AAR messages. This serves two purposes. Firstly the NAS/ASP may 525 advertise its MIPv6 bootstrapping capability to the Diameter server. 526 Secondly the NAS/ASP may suggest locally allocated home agents to the 527 Diameter server. Whether the locally allocated home agents are 528 allowed for the forthcoming MIPv6 session depends on the MN's 529 subscription and the ASA/MSA(/MSP) policies. If the NAS/ASP only 530 wants to advertise its capability for local agent allocation but does 531 not want to provide any specific agent at this point of time (e.g. 532 that is left for later steps during the actual Mobile IP 533 registration) the AVPs MUST contain values described in Section 4.8. 535 If the network access authentication failed the NAS receives 536 appropriate error codes as defined for the Diameter EAP or NASREQ 537 applications. The NAS does not allow the MN to access the network 538 and does not do any MIPv6 bootstrapping related procedures. 540 If the network access authentication completed successfully, the NAS 541 looks for home agent defining AVPs in the reply messages (either DEA 542 or AAA depending on the used authentication method). The NAS 543 associates the received bootstrapping information to the MN that 544 initiated the access authentication and stores the information 545 internally (storing time is determined by the ASP policy). The 546 stored bootstrapping information is then available for the NAS and 547 the DHCP relay for later step during the MN bootstrapping process. 549 The actual bootstrapping from the MN point of view takes place after 550 the network access authentication has completed. The bootstrapping 551 may be realized e.g. using DHCP as defined in 552 [I-D.ietf-mip6-bootstrapping-integrated-dhc] and [RFC2132]. 554 The MN has no consistent way of indicating to the NAS that it 555 supports MIPv6 integrated scenario way of bootstrapping during the 556 network access authentication. Subsequently the NAS has no 557 possibilities to find out whether the terminal attempting to 558 authenticate is actually a MN with MIPv6 bootstrapping functionality 559 prior the network access authentication has completed. Thus it is 560 possible that the NAS initiates MIPv6 integrated scenario 561 bootstrapping configuration even if the MN is not able to make any 562 use of it later. The Diameter server in the ASA/MSA might be able to 563 detect this situation during the authentication phase based on MN's 564 identity -- assuming the ASA is able to verify from the MSA(/MSP) 565 whether the MN has been provisioned with a MIPv6 service. 567 5.2. Server Behavior 569 If the NAS/ASP does not support MIPv6 integrated scenario 570 bootstrapping then the NAS either selects the Diameter NASREQ or EAP 571 application depending on which access authentication method the MN 572 has to use to authenticate. In this case the NAS does not either 573 include any MIPv6 NAS - HAAA interface AVPs as a hint of the 574 bootstrapping capability in the NAS/ASP. The Diameter server in the 575 ASA/MSA(/MSP) detects this case (based on AVPs that serve as a 576 capability hint) and does not have to carry out any MIPv6 577 bootstrapping related procedures. However, as the capability 578 advertisement mechanism described in this document serves only as an 579 optional hint, the Diameter server should not entirely rely on the 580 received capability hints but also base its working logic on 581 subscription information and general MSA(/MSP) policies. 583 Next we describe two different scenarios for the network access 584 authentication when the NAS/ASP supports MIPv6 integrated scenario 585 bootstrapping. 587 1) The MN uses some EAP-based method to authenticate to the network 588 and the NAS uses Diameter EAP application commands. Depending on 589 the ASA/MSA(/MSP) policy the Diameter server SHOULD assign a 590 Mobile IPv6 home agent to the MN and include corresponding MIP6- 591 Home-Agent-Address, the MIP6-Home-Agent-FQDN AVPs and the MIP6- 592 Home-Link-Prefix in the final DEA message. 593 2) The MN uses some other than EAP-based method to authenticate to 594 the network and the NAS uses Diameter NASREQ application commands. 595 Depending on the ASA/MSA(/MSP) policy the Diameter server SHOULD 596 assign a Mobile IPv6 home agent to the MN and include 597 corresponding MIP6-Home-Agent-Address, the MIP6-Home-Agent-FQDN 598 AVPs and the MIP6-Home-Link-Prefix in the final AAA message. 600 If the Diameter request message contained any MIPv6 NAS -HAAA 601 interface AVPs the Diameter server should regard them as a hint of 602 the MIPv6 bootstrapping capability in the NAS/ASP. Any of these AVPs 603 may contain values as described in Section 4.8 which indicate the 604 NAS/ASP would like to locally allocate a home agent or a home link to 605 the MN. The Diameter server may or may not honor the NAS/ASP hint 606 based on the MN's subscription and ASA/MAS(/MSP) policies. 608 5.3. Example Message Flows 610 This section shows basic message flows of MIPv6 integrated scenario 611 bootstrapping and dynamic home agent assignment. In the Figure 7 612 network access authentication is based on EAP (e.g. 802.11i/802.1X). 613 The NAS informs the home Diameter server that home agent assignment 614 in the foreign network is possible. The Diameter server assigns the 615 MN a home agent either in the home MSP or in the ASP. The assignment 616 procedure is out of scope of this document. The Diameter server then 617 replies to the NAS with home agent related bootstrapping information. 619 NAS Local proxy Home server 620 | | | 621 | Diameter-EAP-Request | | 622 | MIP6-Home-Agent-Address(IPv6 address) | 623 | MIP6-Home-Agent-FQDN=visited_ha6.example.com | 624 | MIP4-Home-Agent-Address(IPv4 address) | 625 | MIP6-Home-Link-Prefix=(IPv6 prefix) | 626 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 627 | EAP-Payload(EAP Start) | | 628 |------------------------------->|------------------------------->| 629 | | | 630 | : | 631 : ...more EAP Request/Response pairs... : 632 | : | 633 | | | 634 | | Diameter-EAP-Answer | 635 | MIP6-Home-Agent-Address(IPv6 address) | 636 | MIP6-Home-Agent-FQDN=ha.example.com | 637 | | Result-Code=DIAMETER_SUCCESS | 638 | | EAP-Payload(EAP Success) | 639 | | EAP-Master-Session-Key | 640 | | (authorization AVPs) | 641 | | ... | 642 |<-------------------------------|<-------------------------------| 643 | | | 645 Figure 7: MIPv6 integrated scenario bootstrapping and NAS - HAAA 646 interface example when EAP is used for access authentication 648 6. AVP Occurrence Tables 650 6.1. DER and DEA Commands AVP Table 652 The following table lists the additional MIPv6 bootstrapping NAS - 653 HAAA interface AVPs that optionally may be present in the DER and DEA 654 Commands, as defined in this document and in [RFC4072]. 656 +---------------+ 657 | Command-Code | 658 |-------+-------+ 659 Attribute Name | DER | DEA | 660 -------------------------------+-------+-------+ 661 MIP6-Home-Agent-Address | 0-1 | 0-1 | 662 MIP6-Home-Agent-FQDN | 0-1 | 0-1 | 663 MIP4-Home-Agent-Address | 0-1 | 0-1 | 664 MIP6-Home-Link-Prefix | 0-1 | 0-1 | 665 +-------+-------+ 667 Figure 8: DER and DEA Commands AVP table 669 6.2. AAR and AAA Commands AVP Table 671 The following table lists the additional MIPv6 bootstrapping NAS - 672 HAAA interface AVPs that may optionally be present in the AAR and AAA 673 Commands, as defined in this document and in [RFC4005]. 675 +---------------+ 676 | Command-Code | 677 |-------+-------+ 678 Attribute Name | AAR | AAA | 679 -------------------------------|-------+-------| 680 MIP6-Home-Agent-Address | 0-1 | 0-1 | 681 MIP6-Home-Agent-FQDN | 0-1 | 0-1 | 682 MIP4-Home-Agent-Address | 0-1 | 0-1 | 683 MIP6-Home-Link-Prefix | 0-1 | 0-1 | 684 +-------+-------+ 686 Figure 9: AAR and AAA Commands AVP table 688 7. MIPv6 Bootstrapping NAS - HAAA Interface AVPs 690 This section defines the AVPs that are specific to Diameter MIPv6 691 bootstrapping NAS - HAAA interface and MAY be included in the 692 Diameter EAP [RFC4072] and the NASREQ [RFC4005] applications messages 693 listed in Section 4 of this document. The Diameter AVP rules are 694 defined in the Diameter Base [RFC3588], Section 4. These AVP rules 695 are observed in AVPs defined in this section. 697 The following table describes the Diameter AVPs, their AVP Code 698 values, types, possible flag values, and whether the AVP MAY be 699 encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules 700 for AVPs in section 4.5. 702 +--------------------+ 703 | AVP Flag rules | 704 +----+-----+----+----+----+ 705 AVP Section | | |SHLD|MUST| | 706 Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| 707 -----------------------------------------+----+-----+----+----+----+ 708 MIP6-Home-Agent- TBD 4.7.1 OctetString| M | P | | V | Y | 709 Address | | | | | | 710 MIP6-Home-Agent- TBD 4.7.2 UTF8String | M | P | | V | Y | 711 FQDN | | | | | | 712 MIP4-Home-Agent- TBD 4.7.4 OctetString| M | P | | V | Y | 713 address | | | | | | 714 MIP6-Home-Link- TBD 4.7.3 Unsigned32 | M | P | | V | Y | 715 Prefix | | | | | | 716 -----------------------------------------+----+-----+----+----+----+ 718 Figure 10: AVP flag rules table 720 8. IANA Considerations 722 This specification defines the following new AVPs: 724 MIP6-Home-Agent-Address is set to TBD 725 MIP6-Home-Agent-FQDN is set to TBD 726 MIP4-Home-Agent-Address is set to TBD 727 MIP6-Home-Link-Prefix is set to TBD 729 9. Security Considerations 731 The security considerations for the Diameter interaction required to 732 accomplish the integrated scenario are described in 733 [I-D.ietf-mip6-bootstrapping-integrated-dhc] . Additionally, the 734 security considerations of the Diameter base protocol [RFC3588], 735 Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] 736 application (with respect to network access authentication and the 737 transport of keying material) are applicable to this document. 739 10. Acknowledgements 741 This document is heavily based on the ongoing work for RADIUS MIPv6 742 interaction. Hence, credits go to respective authors for their work 743 with draft-ietf-mip6-radius-00.txt. Furthermore, the author would 744 like to thank the authors of draft-le-aaa-diameter-mobileipv6-04.txt 745 (Franck Le, Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for 746 their work in context of MIPv6 Diameter interworking. Their work 747 influenced this document. 749 11. Revision history 751 The following changes were made to the -01 version of the draft: 753 o The document title was changed to "The NAS - HAAA Interface for 754 MIPv6 Bootstrapping". 755 o Added HAAA and NAS to terminology section". 756 o Changed NAS application to NASREQ application.". 757 o Changed "Integrated Scenario" to NAS-HAAA interface". 758 o The separate Diameter Application-ID for MIPv6 bootstrapping 759 (MIP6BSTI) got removed and all bootstrapping is based on Diameter 760 EAP application and Diameter NAS application. 761 o MIPv6-Bootstrapping-Feature AVP was removed and General text 762 regarding to the capability advertisement based on optional AVPs 763 was added. 764 o The capability exchange was modified so that the NAS may suggest a 765 specific HA to the AAAH. Original MIPv6-Bootstrapping-Feature AVP 766 was replaces with a possibility to include any bootstrapping AVP 767 to the Diameter AAR or DER messages as a capability and local 768 allocation hint. 770 12. References 772 12.1. Normative References 774 [I-D.ietf-mip6-aaa-ha-goals] 775 Giaretta, G., "AAA Goals for Mobile IPv6", 776 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 777 September 2006. 779 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 780 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 781 for the Integrated Scenario", 782 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 783 progress), June 2006. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", March 1997. 788 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 789 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 791 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 792 in IPv6", RFC 3775, June 2004. 794 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 795 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 796 September 2006. 798 12.2. Informative References 800 [I-D.ietf-mip6-bootstrapping-split] 801 Giaretta, G., "Mobile IPv6 bootstrapping in split 802 scenario", draft-ietf-mip6-bootstrapping-split-03 (work in 803 progress), October 2006. 805 [I-D.ietf-mip6-nemo-v4traversal] 806 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 807 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-02 808 (work in progress), June 2006. 810 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 811 Extensions", RFC 2132, March 1997. 813 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 814 RFC 3753, June 2004. 816 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 817 "Diameter Network Access Server Application", RFC 4005, 818 August 2005. 820 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 821 Authentication Protocol (EAP) Application", RFC 4072, 822 August 2005. 824 Authors' Addresses 826 Jouni Korhonen 827 TeliaSonera 828 Teollisuuskatu 13 829 Sonera FIN-00051 830 Finland 832 Email: jouni.korhonen@teliasonera.com 833 Julien Bournelle 834 GET/INT 835 9 rue Charles Fourier 836 Evry 91011 837 France 839 Email: julien.bournelle@int-evry.fr 841 Hannes Tschofenig 842 Siemens 843 Otto-Hahn-Ring 6 844 Munich, Bavaria 81739 845 Germany 847 Email: Hannes.Tschofenig@siemens.com 848 URI: http://www.tschofenig.com 850 Charles E. Perkins 851 Nokia 853 Email: charliep@iprg.nokia.com 855 Kuntal Chowdhury 856 Starent Networks 858 Email: kchowdhury@starentnetworks.com 860 Full Copyright Statement 862 Copyright (C) The Internet Society (2006). 864 This document is subject to the rights, licenses and restrictions 865 contained in BCP 78, and except as set forth therein, the authors 866 retain all their rights. 868 This document and the information contained herein are provided on an 869 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 870 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 871 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 872 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 873 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 876 Intellectual Property 878 The IETF takes no position regarding the validity or scope of any 879 Intellectual Property Rights or other rights that might be claimed to 880 pertain to the implementation or use of the technology described in 881 this document or the extent to which any license under such rights 882 might or might not be available; nor does it represent that it has 883 made any independent effort to identify any such rights. Information 884 on the procedures with respect to rights in RFC documents can be 885 found in BCP 78 and BCP 79. 887 Copies of IPR disclosures made to the IETF Secretariat and any 888 assurances of licenses to be made available, or the result of an 889 attempt made to obtain a general license or permission for the use of 890 such proprietary rights by implementers or users of this 891 specification can be obtained from the IETF on-line IPR repository at 892 http://www.ietf.org/ipr. 894 The IETF invites any interested party to bring to its attention any 895 copyrights, patents or patent applications, or other proprietary 896 rights that may cover technology that may be required to implement 897 this standard. Please address the information to the IETF at 898 ietf-ipr@ietf.org. 900 Acknowledgment 902 Funding for the RFC Editor function is provided by the IETF 903 Administrative Support Activity (IASA).