idnits 2.17.1 draft-ietf-dime-mip6-integrated-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 919. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 239 has weird spacing: '...ers for the D...' -- 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 19, 2006) is 6511 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) == Unused Reference: 'I-D.ietf-mip6-bootstrapping-integrated-dhc' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip6-bootstrapping-split' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip6-nemo-v4traversal' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'I-D.jang-mip6-hiopt' is defined on line 842, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. 'I-D.ietf-mip6-bootstrap-ps') == 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-02 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-01 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen 3 Extensions (DIME) TeliaSonera 4 Internet-Draft J. Bournelle 5 Expires: December 21, 2006 GET/INT 6 H. Tschofenig 7 Siemens 8 C. Perkins 9 Nokia 10 June 19, 2006 12 Diameter MIPv6 Bootstrapping for the Integrated Scenario 13 draft-ietf-dime-mip6-integrated-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 21, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 A Mobile IPv6 node requires a home agent address, a home address, and 47 IPsec security association with its home agent before it can start 48 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 49 these parameters are statically configured. Ongoing Mobile IPv6 50 bootstrapping work aims to make this information dynamically 51 available to the mobile node. An important aspect of the Mobile IPv6 52 bootstrapping solution is to support interworking with existing 53 authentication, authorization and accounting infrastructure. This 54 document describes the usage of Diameter to facilitate Mobile IPv6 55 bootstrapping for the integrated scenario. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Commands, AVPs and Advertising Application Support . . . . . . 7 63 4.1 Advertising Application Support . . . . . . . . . . . . . 7 64 4.2 Command Codes . . . . . . . . . . . . . . . . . . . . . . 8 65 4.3 Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 8 66 4.4 Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 9 67 4.5 AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 10 68 4.6 AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 11 69 4.7 New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.7.1 MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 12 71 4.7.2 MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 12 72 4.7.3 MIP4-Home-Agent-Address AVP . . . . . . . . . . . . . 12 73 4.7.4 MIPv6-Bootstrapping-Feature AVP . . . . . . . . . . . 13 74 5. Diameter Client and Server Behavior During MIPv6 75 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1 Client (NAS) Behavior . . . . . . . . . . . . . . . . . . 14 77 5.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 15 78 5.3 Example Message Flows . . . . . . . . . . . . . . . . . . 16 79 6. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 18 80 6.1 DER and DEA Commands AVP Table . . . . . . . . . . . . . . 18 81 6.2 AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 18 82 7. MIPv6 Bootstrapping Integrated AVPs . . . . . . . . . . . . . 19 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 8.1 AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.2 Application Identifier . . . . . . . . . . . . . . . . . . 20 86 8.3 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 11.1 Normative References . . . . . . . . . . . . . . . . . . . 23 91 11.2 Informative References . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 93 Intellectual Property and Copyright Statements . . . . . . . . 26 95 1. Introduction 97 Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to 98 perform registration with a home agent with information about its 99 current point of attachment (Care-of Address). The home agent 100 creates and maintains binding between the MN's Home Address and the 101 MN's Care-of Address. 103 In order to register with a home agent, the MN needs to know some 104 information such as, the Home Link prefix, the home agent Address, 105 the Home Address(es), the Home Link prefix Length and security 106 related information in order to later secure the Binding Update. 108 The aforementioned set of information may be statically provisioned 109 in the MN. However, static provisioning of this information has its 110 drawbacks. It increases provisioning and network maintenance becomes 111 easily burden for an operator. Moreover, static provisioning does 112 not allow load balancing, failover, opportunistic home link 113 assignment etc. For example, the user may be accessing the network 114 from a location that may be geographically far away from the 115 preconfigured home link; the administrative burden to configure the 116 MNs with the respective addresses is large and the ability to react 117 on environmental changes is minimal. In these situations static 118 provisioning may not be desirable. 120 Dynamic assignment of Mobile IPv6 home registration information is a 121 desirable feature for ease of deployment and network maintenance. 122 For this purpose, the Diameter infrastructure, which is used for 123 access authentication, can be leveraged to assign some or all of the 124 necessary parameters. The Diameter server in Access Service 125 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 126 return these parameters to the AAA client. The AAA client might 127 either be the NAS, in case of the integrated scenario, or the home 128 agent, in case of the split scenario [I-D.ietf-mip6-bootstrapping- 129 split]. The terms integrated and split are described in the 130 terminology section and were introduced in 131 [I-D.ietf-mip6-bootstrap-ps] and [I-D.ietf-mip6-aaa-ha-goals]. 133 2. Terminology and Abbreviations 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC2119 [RFC2119]. 139 General mobility terminology can be found in [RFC3753]. The 140 following additional terms, as defined in 141 [I-D.ietf-mip6-bootstrap-ps], are used in this document: 143 Access Service Authorizer (ASA): 145 A network operator that authenticates a mobile node and 146 establishes the mobile node's authorization to receive Internet 147 service. 149 Access Service Provider (ASP): 151 A network operator that provides direct IP packet forwarding to 152 and from the mobile node. 154 Mobility Service Authorizer (MSA): 156 A service provider that authorizes Mobile IPv6 service. 158 Mobility Service Provider (MSP): 160 A service provider that provides Mobile IPv6 service. In order to 161 obtain such service, the mobile node must be authenticated and 162 authorized to obtain the Mobile IPv6 service. 164 Split scenario: 166 A scenario where the mobility service and the network access 167 service are authorized by different entities. 169 Integrated Scenario: 171 A scenario where the mobility service and the network access 172 service are authorized by the same entity. 174 3. Overview 176 This document addresses the authentication, authorization and 177 accounting functionality required by for the MIPv6 bootstrapping as 178 outlined in the MIPv6 bootstrapping problem statement document (see 179 [I-D.ietf-mip6-bootstrap-ps]). This document focuses on the AAA 180 functionality for the integrated scenario. The AAA interaction for 181 the split scenario is conceptually simpler and described in 182 [I-D.tschofenig-mip6-aaa-ha-diameter]. 184 The subsequent text outlines the AAA interaction between the 185 participating entities in the integrated scenario. In the integrated 186 scenario MIPv6 bootstrapping is provided as part of the network 187 access authentication procedure. Figure 1 shows the participating 188 entities. This document, however, only concentrates on the NAS, 189 possible local Diameter proxies and the home Diameter 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 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 Mobile IPv6 access scenario, as shown above, the MN is 219 attached to an Access Service Provider's network. During the network 220 attachment procedure, the NAS/Diameter client interacts with the 221 mobile node. As shown in Figure 1, the authentication and 222 authorization happens via the Diameter infrastructure. 224 At the time of authorizing the user for the IPv6 access, the Diameter 225 server in the MSA detects that the user is authorized for Mobile IPv6 226 access. Based on the MSA's policy, the Diameter server may allocate 227 several parameters to the MN for use during the subsequent Mobile 228 IPv6 protocol interaction with the home agent. 230 Depending on the details of the solution interaction with the DHCPv6 231 server may be required, as described in [I-D.ietf-mip6-bootstrapping- 232 integrated-dhc]. However, the solution described in this document is 233 not dependant on the DHCPv6 as the only possible MIPv6 bootstrapping 234 method. 236 4. Commands, AVPs and Advertising Application Support 238 This section describes command codes, defines AVPs and advertised 239 application identifiers for the Diameter MIPv6 bootstrapping in the 240 integrated scenario. 242 4.1 Advertising Application Support 244 Diameter nodes conforming to this specification SHOULD include the 245 value of (TBD) in the Auth-Application-Id or the Acct-Application-Id 246 AVP of the Capabilities-Exchange-Request and Capabilities-Exchange- 247 Answer commands [RFC3588]. This application is referred as the 248 Diameter MIPv6 Bootstrapping Integrated scenario -- MIP6BSTI. From 249 the advertised Application ID the home Diameter server is able to 250 detect whether the Access Service Provider (and its NAS) supports 251 MIPv6 bootstrapping and MIPv6. If the NAS also supports the EAP 252 application and/or the Diameter NAS Application application 253 corresponding Application IDs should be advertised during the 254 capability exchange. 256 If the NAS receives a response with the Result-Code set to 257 DIAMETER_APPLICATION_UNSUPPORTED [RFC3588], it indicates that the 258 Diameter server in the ASA/MSA does not support MIPv6 Bootstrapping 259 Integrated application. In this case the NAS MAY attempt to fallback 260 to basic network access authentication without MIPv6 bootstrapping. 262 Whenever the mobile node authenticates using some EAP-based method 263 then the NAS SHOULD use the Diameter MIPv6 Bootstrapping Integrated 264 Application ID value of TBD in the Auth-Application-Id AVP in the 265 Diameter-EAP-Request command [RFC4072] and subsequently the answering 266 Diameter server in the Diameter-EAP-Answer command [RFC4072]. This 267 implies that the NAS and the Diameter server MUST support MIPv6 268 Bootstrapping Integrated application. If either end lacks the 269 required support, the NAS and subsequently also the Diameter server 270 falls back to the EAP application [RFC4072]. 272 If the mobile node does not use EAP-based network access 273 authentication then the NAS SHOULD use the Diameter MIPv6 274 Bootstrapping Integrated Application ID value of TBD in the Auth- 275 Application-Id AVP in the AA-Request command [RFC4005] and 276 subsequently the answering Diameter server in the AA-Answer command 277 [RFC4005]. This implies that the NAS and the Diameter server MUST 278 support MIPv6 bootstrapping integrated application. If either end 279 lacks the required support, the NAS and subsequently also the 280 Diameter server falls back to the Diameter NAS application [RFC4005]. 282 The value of zero (0) SHOULD be used as the Application-Id in all 283 STR/STA, ACR/ACA, ASR/ASA, and RAR/RAA commands, because these 284 commands are defined in the Diameter base protocol and no additional 285 mandatory AVPs for those commands are defined in this document. 287 4.2 Command Codes 289 This document re-uses the Diameter Base protocol [RFC3588], Diameter 290 NAS Application [RFC4072] and EAP commands . The following commands 291 are used to carry MIPv6 related bootstrapping AVPs: 293 Command-Name Abbrev. Code Reference Application 295 Diameter-EAP-Request DER 268 RFC 4072 MIP6BSTI 296 Diameter-EAP-Answer DEA 268 RFC 4072 MIP6BSTI 298 AA-Request AAR 265 RFC 4005 MIP6BSTI 299 AA-Answer AAA 265 RFC 4005 MIP6BSTI 301 Figure 2: MIPv6 Bootstrapping Integrated Application Command Codes 303 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 304 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 305 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 306 (ACR), and Accounting-Answer (ACA) commands are used together with 307 the Diameter MIPv6 Bootstrapping Integrated application, they follow 308 the rules in the Diameter NAS [RFC4005], EAP [RFC4072] and BASE 309 [RFC3588] applications. The accounting commands use Application 310 Identifier value of 3 (Diameter Base Accounting); the others use 0 311 (Diameter Common Messages). 313 4.3 Diameter-EAP-Request (DER) 315 The Diameter-EAP-Request (DER) command [RFC4072], indicated by the 316 Command-Code field set to 268 and the 'R' bit set in the Command 317 Flags field, may be sent by the NAS to the Diameter server providing 318 network access authentication and authorization services. At the 319 same time with the network access authentication and authorization 320 the NAS MAY request home agent assignment, to authorize for mobility 321 service usage and optionally to indicate the support of possible 322 local home agent assignment. The NAS indicates the support for MIPv6 323 Bootstrapping Integrated application by setting the 324 Auth-Application-Id to value of TBD. The DER command MAY also carry 325 the DNS Update Mobility Option and the MIPv6 Bootstrapping Feature 326 attribute. 328 The message format is the same as defined in [RFC4072] with an 329 addition of MIPv6 Bootstrapping Integrated application AVPs. The 330 figure below shows the DER message used with the MIPv6 Bootstrapping 331 Integrated application: 333 ::= < Diameter Header: 268, REQ, PXY > 334 < Session-Id > 335 { Auth-Application-Id } 336 { Origin-Host } 337 { Origin-Realm } 338 { Destination-Realm } 339 { Auth-Request-Type } 341 [ MIPv6-Bootstrapping-Feature ] 343 [ Destination-Host ] 344 ... 345 * [ AVP ] 347 Figure 3: Diameter EAP Request Command 349 4.4 Diameter-EAP-Answer (DEA) 351 The Diameter-EAP-Answer (DEA) message define in [RFC4072], indicated 352 by the Command- Code field set to 268 and 'R' bit cleared in the 353 Command Flags field is sent in response to the Diameter-EAP-Request 354 message (DER). If the mobility service is successfully authorized 355 and the Diameter server was able to fulfill the bootstrapping request 356 (if needed) then the response SHOULD include the MIP6-Home-Agent- 357 Address AVP, MIP6-Home-Agent-FQDN and MIP4-Home-Agent-address AVPs. 359 The message format is the same as defined in [RFC4072] with an 360 addition of MIPv6 Bootstrapping Integrated application AVPs. The 361 figure below shows the DEA message used with the MIPv6 Bootstrapping 362 Integrated application: 364 ::= < Diameter Header: 268, PXY > 365 < Session-Id > 366 { Auth-Application-Id } 367 { Auth-Request-Type } 368 { Result-Code } 369 { Origin-Host } 370 { Origin-Realm } 372 [ MIP6-Home-Agent-Address ] 373 [ MIP6-Home-Agent-FQDN ] 374 [ MIP4-Home-Agent-address ] 376 [ User-Name ] 377 ... 378 * [ AVP ] 380 Figure 4: Diameter EAP Answer Command 382 4.5 AA-Request (AAR) 384 The AA-Request (AAR) message, indicated by the Command-Code field set 385 to 265 and 'R' bit set in the Command Flags field, may be sent by 386 the NAS to the Diameter server providing network access configuration 387 services. At the same time with the network access configuration the 388 NAS MAY request home agent assignment, to authorize for mobility 389 service usage and optionally to indicate the support of possible 390 local home agent assignment. The NAS indicates the support for MIPv6 391 Bootstrapping Integrated application by setting the 392 Auth-Application-Id to value of (TBD). The AAR command MAY also 393 carry the DNS Update Mobility Option and the MIPv6 Bootstrapping 394 Feature attribute. 396 The message format is the same as defined in [RFC4005] with an 397 addition of MIPv6 Bootstrapping Integrated application AVPs. The 398 figure below shows the AAR message used with the MIPv6 Bootstrapping 399 Integrated application: 401 ::= < Diameter Header: 265, REQ, PXY > 402 < Session-Id > 403 { Auth-Application-Id } 404 { Origin-Host } 405 { Origin-Realm } 406 { Destination-Realm } 407 { Auth-Request-Type } 409 [ MIPv6-Bootstrapping-Feature ] 411 [ Destination-Host ] 412 ... 413 * [ AVP ] 415 Figure 5: AA Request Command 417 4.6 AA-Answer (AAA) 419 The AA-Answer (AAA) message, indicated by the Command-Code field set 420 to 265 and 'R' bit cleared in the Command Flags field is sent in 421 response to the AA-Request (AAR) message for confirmation of the 422 result of MIPv6 HA bootstrapping. If the mobility service is 423 successfully authorized and the Diameter server was able to fulfill 424 the bootstrapping request (if needed) then the response SHOULD 425 include the MIP6-Home-Agent-Address AVP, MIP6-Home-Agent-FQDN and 426 MIP4-Home-Agent-address AVPs. 428 The message format is the same as defined in [RFC4005] with an 429 addition of MIPv6 Bootstrapping Integrated application AVPs. The 430 figure below shows the DEA message used with the MIPv6 Bootstrapping 431 Integrated application: 433 ::= < Diameter Header: 265, PXY > 434 < Session-Id > 435 { Auth-Application-Id } 436 { Auth-Request-Type } 437 { Result-Code } 438 { Origin-Host } 439 { Origin-Realm } 441 [ MIP6-Home-Agent-Address ] 442 [ MIP6-Home-Agent-FQDN ] 443 [ MIP4-Home-Agent-address ] 445 [ User-Name ] 446 ... 447 * [ AVP ] 449 Figure 6: AA Answer Command 451 4.7 New AVPs 453 4.7.1 MIP6-Home-Agent-Address AVP 455 The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 456 and contains the Mobile IPv6 home agent address and the prefix length 457 of the said address. The AVP is a discriminated union, representing 458 IPv6 address in network byte order. The first two octets of this AVP 459 represents the home link prefix length followed by 16 octets of the 460 IPv6 address. 462 The Diameter server MAY decide to assign a MIPv6 home agent to the MN 463 that is in close proximity to the point of attachment (e.g. 464 determined by the NAS-Identifier). There may be other reasons for 465 dynamically assigning home agents to the MN, for example to share the 466 traffic load. The AVP also contains the prefix length so that the MN 467 can easily infer one of the possible Home Link prefixes from the home 468 agent address. 470 4.7.2 MIP6-Home-Agent-FQDN AVP 472 The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and 473 contains the FQDN of a Mobile IPv6 home agent. 475 4.7.3 MIP4-Home-Agent-Address AVP 477 The MIP4-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 478 and contains the IPv4 home agent address and the prefix length of the 479 said address. The AVP is a discriminated union, representing IPv4 480 address in network byte order. The first two octets of this AVP 481 represents the home link prefix length followed by 4 octets of the 482 IPv4 address. 484 The Diameter server MAY decide to assign a MIPv4 home agent to the MN 485 in a case where dual stack Mobile IP is supported [I-D.ietf-mip6- 486 nemo-v4traversal]. 488 4.7.4 MIPv6-Bootstrapping-Feature AVP 490 The MIPv6-Bootstrapping-Feature AVP (AVP Code TBD) is of type 491 Unsigned32 and contains a 32 bits flags field of supported features 492 by the NAS and the ASP. 494 By using this payload the NAS indicates to the Diameter server 495 certain capabilities and features. For example, the NAS might want 496 to indicate that local home agent assignment can be provided. 498 Local-Home-Agent-Assignment 1 499 This flag is set when the NAS knows that a local home agent 500 located in the ASP can be provided for the MN. 502 Dual-Stack-MIP-supported 2 503 This flag is set when the NAS and the local access network 504 supports dual stack Mobile IP as defined in [I-D.ietf-mip6-nemo- 505 v4traversal] and bootstrapping functionality can also be provided 506 for the Mobile IPv4 Home Address. 508 5. Diameter Client and Server Behavior During MIPv6 Bootstrapping 510 This section describes the Diameter server and client behavior in 511 case of the MIPv6 bootstrapping in the integrated scenario. The text 512 does several assumptions for brevity. 514 o The Diameter server is assumed to support at least the Diameter 515 BASE, EAP and NAS applications. 517 o The Diameter client (i.e. the NAS) is assumed to support at least 518 the Diameter BASE, EAP and NAS applications. 520 o The MN uses such network access authentication method and 521 credentials that are supported by the NAS/ASP and ASA/MSA. 523 o The MN has been provisioned with Mobile IPv6 service. 525 o The capability exchange has already completed, thus the NAS and 526 the Diameter server share the knowledge of mutually supported 527 applications. Cases where the ASA/MSA do not support MIPv6 528 bootstrapping are not discussed. In these cases the NAS has no 529 other choice than to carry out the network access authentication 530 as defined in the Diameter EAP or NAS applications. 532 5.1 Client (NAS) Behavior 534 If the ASP/NAS does not support MIPv6 integrated scenario 535 bootstrapping and/or the corresponding application then the NAS 536 either selects the Diameter NAS or EAP application depending on which 537 authentication method the MN has to use to authenticate itself. 538 Naturally after a successful or a failed authentication the NAS does 539 not have to do any MIPv6 bootstrapping related procedures. 541 Next we describe two different scenarios for the network access 542 authentication when the ASP/NAS supports MIPv6 integrated scenario 543 bootstrapping and the corresponding application. 545 1) The MN uses some EAP-based method (e.g. 802.11i/802.1X) to 546 authenticate to the network. In this scenario the NAS uses 547 commands originally defined for the EAP application. However, the 548 Application IDs included in messages are set to the value of (TBD) 549 indicating the MIP6BSTI application. Depending on the ASP 550 capabilities the NAS may include the MIPv6-Bootstrapping-Feature 551 AVP in the first DER message. This AVP indicates whether it is 552 possible to allocate home agents locally and whether Mobile IPv4 553 bootstrapping is also supported. 555 2) The MN uses some other than EAP-based method to authenticate to 556 the network. In this scenario the NAS uses commands originally 557 defined for the Diameter NAS application. However, the 558 Application IDs included in messages are set to the value of (TBD) 559 indicating the MIP6BSTI application. Depending on the ASP 560 capabilities the NAS may include the MIPv6-Bootstrapping-Feature 561 AVP in the first DER message. This AVP indicates whether it is 562 possible to allocate home agents locally and whether Mobile IPv4 563 bootstrapping is also supported. 565 If the network access authentication failed the NAS receives 566 appropriate error codes as defined for the Diameter EAP or NAS 567 applications. The NAS does not allow the MN to access the network 568 and does not do any MIPv6 bootstrapping related procedures. 570 If the network access authentication completed successfully, the NAS 571 looks for home agent defining AVPs in the reply messages (either DEA 572 or AAA depending on the used authentication method). The NAS 573 associates the received bootstrapping information to the MN that 574 initiated the access authentication and stores the information 575 internally (storing time is determined by the ASP policy). The 576 stored bootstrapping information is then available for the NAS and 577 the DHCP relay for later step during the MN bootstrapping process. 579 The actual bootstrapping from the MN point of view takes place after 580 the network access authentication has completed. The bootstrapping 581 may be realized e.g. using DHCP as defined in [I-D.ietf-mip6- 582 bootstrapping-integrated-dhc] and [RFC2132]. 584 The MN has actually no consistent way of indicating to the NAS that 585 it supports MIPv6 integrated scenario way of bootstrapping during the 586 network access authentication. Subsequently the NAS has no 587 possibilities to find out whether the terminal attempting to 588 authenticate is actually a MN with MIPv6 bootstrapping functionality 589 prior the network access authentication has completed. Thus it is 590 possible that the NAS initiates MIPv6 integrated scenario 591 bootstrapping configuration even if the MN is not able to make any 592 use of it later. The Diameter server in the ASA/MSA might be able to 593 detect this situation during the authentication phase based on MN's 594 identity -- assuming the ASA is able to verify from the MSA whether 595 the MN has been provisioned with a MIPv6 service. 597 5.2 Server Behavior 599 If the ASP/NAS does not support MIPv6 integrated scenario 600 bootstrapping and/or the corresponding application then the NAS 601 either selects the Diameter NAS or EAP application depending on which 602 access authentication method the MN has to use to authenticate. The 603 Diameter server in the ASA/MSA is able to detect this case (based on 604 used Application IDs) and does not have to do any MIPv6 bootstrapping 605 related procedures. 607 Next we describe two different scenarios for the network access 608 authentication using the MIPv6 integrated scenario bootstrapping and 609 the corresponding MIP6BSTI application. 611 1) The MN uses some EAP-based method to authenticate to the network. 612 In this scenario the NAS uses commands originally defined for the 613 EAP application. However, the Application IDs included in 614 messages are set to the value of (TBD) indicating the MIP6BSTI 615 application. Depending on the ASA/MSA policy the Diameter server 616 SHOULD assign a Mobile IPv6 home agent to the MN and include 617 corresponding MIP6-Home-Agent-Address and the MIP6-Home-Agent-FQDN 618 AVPs in the final DEA message. If the DER message received from 619 the NAS included MIPv6-Bootstrapping-Feature AVP with Dual-Stack- 620 MIP-supported flag set, the Diameter server MAY assign the MN with 621 a Mobile IPv4 home agent and include a corresponding MIP4-Home- 622 Agent-Address AVP in the final DEA message. If the MIPv6- 623 Bootstrapping-Feature AVP has the Local-Home-Agent-Assignment flag 624 set the Diameter server MAY attempt to assign a home agent located 625 in the ASP network to the MN. 627 2) The MN uses some other than EAP-based method to authenticate to 628 the network. In this scenario the NAS uses commands originally 629 defined for the Diameter NAS application. However, the 630 Application IDs included in messages are set to the value of (TBD) 631 indicating the MIP6BSTI application. Depending on the ASA/MSA 632 policy the Diameter server SHOULD assign the MN a Mobile IPv6 home 633 agent and include corresponding MIP6-Home-Agent-Address and the 634 MIP6-Home-Agent-FQDN AVPs in the final AAA message. If the AAR 635 message received from the NAS included MIPv6-Bootstrapping-Feature 636 AVP with Dual-Stack-MIP-supported flag set, the Diameter server 637 MAY assign the MN a Mobile IPv4 home agent and include a 638 corresponding MIP4-Home-Agent-Address AVP in the final AAA 639 message. If the MIPv6-Bootstrapping-Feature AVP has the Local- 640 Home-Agent-Assignment flag set the Diameter server MAY attempt to 641 assign a home agent located in the ASP network to the MN. 643 5.3 Example Message Flows 645 This section shows basic message flows of MIPv6 integrated scenario 646 bootstrapping and dynamic home agent assignment. In the Figure 7 647 network access authentication is based on EAP (e.g. 802.11i/802.1X). 648 The NAS informs home Diameter server that home agent assignment in 649 the foreign network is possible. The Diameter server assigns the MN 650 a home agent either in the home MSP or in the ASP. The assignment 651 procedure is out of scope of this document. The Diameter server then 652 replies to the NAS with home agent related bootstrapping information. 654 NAS Local proxy Home server 655 | | | 656 | Diameter-EAP-Request | | 657 | MIPv6-Bootstrapping-Feature=Local-Home-Agent-Assignment | 658 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 659 | EAP-Payload(EAP Start) | | 660 |------------------------------->|------------------------------->| 661 | | | 662 | : | 663 : ...more EAP Request/Response pairs... : 664 | : | 665 | | | 666 | | Diameter-EAP-Answer | 667 | MIP6-Home-Agent-Address(IPv6 address) | 668 | MIP6-Home-Agent-FQDN=ha.example.com | 669 | | Result-Code=DIAMETER_SUCCESS | 670 | | EAP-Payload(EAP Success) | 671 | | EAP-Master-Session-Key | 672 | | (authorization AVPs) | 673 | | ... | 674 |<-------------------------------|<-------------------------------| 675 | | | 677 Figure 7: MIPv6 integrated scenario bootstrapping example when EAP is 678 used for access authentication 680 6. AVP Occurrence Tables 682 6.1 DER and DEA Commands AVP Table 684 The following table lists the additional MIPv6 Bootstrapping 685 Integrated application (MIP6BSTI) AVPs that may be present in the DER 686 and DEA Commands, as defined in this document and in [RFC4072]. 688 +---------------+ 689 | Command-Code | 690 |-------+-------+ 691 Attribute Name | DER | DEA | 692 -------------------------------+-------+-------+ 693 MIP6-Home-Agent-Address | 0 | 1 | 694 MIP6-Home-Agent-FQDN | 0 | 0-1 | 695 MIP4-Home-Agent-address | 0 | 0-1 | 696 MIPv6-Bootstrapping-Feature | 0-1 | 0 | 697 +-------+-------+ 699 Figure 8: DER and DEA Commands AVP table 701 6.2 AAR and AAA Commands AVP Table 703 The following table lists the additional MIPv6 Bootstrapping 704 Integrated application (MIP6BSTI) AVPs that may be present in the AAR 705 and AAA Commands, as defined in this document and in [RFC4005]. 707 +---------------+ 708 | Command-Code | 709 |-------+-------+ 710 Attribute Name | AAR | AAA | 711 -------------------------------|-------+-------| 712 MIP6-Home-Agent-Address | 0 | 1 | 713 MIP6-Home-Agent-FQDN | 0 | 0-1 | 714 MIP4-Home-Agent-address | 0 | 0-1 | 715 MIPv6-Bootstrapping-Feature | 0-1 | 0 | 716 +-------+-------+ 718 Figure 9: AAR and AAA Commands AVP table 720 7. MIPv6 Bootstrapping Integrated AVPs 722 This section defines the AVPs that are specific to Diameter MIPv6 723 Bootstrapping Integrated application and that MAY be included in the 724 Diameter EAP [RFC4072] and the NAS [RFC4005] applications messages 725 listed in Section 4 of this document. The Diameter AVP rules are 726 defined in the Diameter Base [RFC3588], Section 4. These AVP rules 727 are observed in AVPs defined in this section. 729 The following table describes the Diameter AVPs defined in the 730 MIP6BSTI application, their AVP Code values, types, possible flag 731 values, and whether the AVP MAY be encrypted. The Diameter base 732 [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. 734 +--------------------+ 735 | AVP Flag rules | 736 +----+-----+----+----+----+ 737 AVP Section | | |SHLD|MUST| | 738 Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| 739 -----------------------------------------+----+-----+----+----+----+ 740 MIP6-Home-Agent- TBD x.y OctetString| M | P | | V | Y | 741 Address | | | | | | 742 MIP6-Home-Agent- TBD x.y UTF8String | M | P | | V | Y | 743 FQDN | | | | | | 744 MIP4-Home-Agent- TBD x.y OctetString| M | P | | V | Y | 745 address | | | | | | 746 MIPv6- TBD x.y Unsigned32 | M | P | | V | Y | 747 Bootstrapping-Feature | | | | | | 748 -----------------------------------------+----+-----+----+----+----+ 750 Figure 10: AVP flag rules table 752 8. IANA Considerations 754 This document defines seven new Diameter AVPs, a new Diameter 755 application and two new namespaces. 757 8.1 AVP Codes 759 This specification defines the following new AVPs: 761 MIP6-Home-Agent-Address is set to TBD 762 MIP6-Home-Agent-FQDN is set to TBD 763 MIP4-Home-Agent-address is set to TBD 764 MIPv6-Bootstrapping-Feature is set to TBD 766 8.2 Application Identifier 768 This specification defines new Diameter application called "MIPv6 769 Bootstrapping Integrated application" i.e. MIP6BSTI. The 770 Application Identifier code for this application is set to TBD. 772 8.3 Namespaces 774 This specification defines a new namespace for the MIPv6- 775 Bootstrapping-Feature AVP flag values: 777 Local-Home-Agent-Assignment is set to 1 778 Dual-Stack-MIP-supported is set to 2 780 9. Security Considerations 782 The security considerations for the Diameter interaction required to 783 accomplish the integrated scenario are described in [I-D.ietf-mip6- 784 bootstrapping-integrated-dhc] . Additionally, the security 785 considerations of the Diameter base protocol [RFC3588], Diameter NAS 786 application [RFC4005] / Diameter EAP [RFC4072] application (with 787 respect to network access authentication and the transport of keying 788 material) are applicable to this document. 790 10. Acknowledgements 792 This document is heavily based on the ongoing work for RADIUS MIPv6 793 interaction. Hence, credits go to Kuntal Chowdhury and Avi Lior for 794 their work with draft-chowdhury-mip6-radius-00.txt. Furthermore, the 795 author would like to thank the authors of 796 draft-le-aaa-diameter-mobileipv6-04.txt (Franck Le, Basavaraj Patil, 797 Charles E. Perkins, Stefano Faccin) for their work in context of 798 MIPv6 Diameter interworking. Their work influenced this document. 800 11. References 802 11.1 Normative References 804 [I-D.ietf-mip6-aaa-ha-goals] 805 Giaretta, G., "Goals for AAA-HA interface", 806 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 807 January 2006. 809 [I-D.ietf-mip6-bootstrap-ps] 810 Giaretta, G. and A. Patel, "Problem Statement for 811 bootstrapping Mobile IPv6", 812 draft-ietf-mip6-bootstrap-ps-05 (work in progress), 813 May 2006. 815 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 816 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 817 for the Integrated Scenario", 818 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 819 progress), June 2006. 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", March 1997. 824 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 825 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 827 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 828 in IPv6", RFC 3775, June 2004. 830 11.2 Informative References 832 [I-D.ietf-mip6-bootstrapping-split] 833 Giaretta, G., "Mobile IPv6 bootstrapping in split 834 scenario", draft-ietf-mip6-bootstrapping-split-02 (work in 835 progress), March 2006. 837 [I-D.ietf-mip6-nemo-v4traversal] 838 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 839 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-01 840 (work in progress), March 2006. 842 [I-D.jang-mip6-hiopt] 843 Jang, H., "DHCP Option for Home Information Discovery in 844 MIPv6", draft-jang-mip6-hiopt-00 (work in progress), 845 June 2006. 847 [I-D.tschofenig-mip6-aaa-ha-diameter] 848 Tschofenig, H., "Mobile IPv6 Bootstrapping using 849 Diameter", draft-tschofenig-mip6-aaa-ha-diameter-01 (work 850 in progress), October 2005. 852 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 853 Extensions", RFC 2132, March 1997. 855 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 856 RFC 3753, June 2004. 858 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 859 "Diameter Network Access Server Application", RFC 4005, 860 August 2005. 862 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 863 Authentication Protocol (EAP) Application", RFC 4072, 864 August 2005. 866 Authors' Addresses 868 Jouni Korhonen 869 TeliaSonera 870 Teollisuuskatu 13 871 Sonera FIN-00051 872 Finland 874 Email: jouni.korhonen@teliasonera.com 876 Julien Bournelle 877 GET/INT 878 9 rue Charles Fourier 879 Evry 91011 880 France 882 Email: julien.bournelle@int-evry.fr 884 Hannes Tschofenig 885 Siemens 886 Otto-Hahn-Ring 6 887 Munich, Bavaria 81739 888 Germany 890 Email: Hannes.Tschofenig@siemens.com 891 URI: http://www.tschofenig.com 892 Charles E. Perkins 893 Nokia 895 Email: charliep@iprg.nokia.com 897 Intellectual Property Statement 899 The IETF takes no position regarding the validity or scope of any 900 Intellectual Property Rights or other rights that might be claimed to 901 pertain to the implementation or use of the technology described in 902 this document or the extent to which any license under such rights 903 might or might not be available; nor does it represent that it has 904 made any independent effort to identify any such rights. Information 905 on the procedures with respect to rights in RFC documents can be 906 found in BCP 78 and BCP 79. 908 Copies of IPR disclosures made to the IETF Secretariat and any 909 assurances of licenses to be made available, or the result of an 910 attempt made to obtain a general license or permission for the use of 911 such proprietary rights by implementers or users of this 912 specification can be obtained from the IETF on-line IPR repository at 913 http://www.ietf.org/ipr. 915 The IETF invites any interested party to bring to its attention any 916 copyrights, patents or patent applications, or other proprietary 917 rights that may cover technology that may be required to implement 918 this standard. Please address the information to the IETF at 919 ietf-ipr@ietf.org. 921 Disclaimer of Validity 923 This document and the information contained herein are provided on an 924 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 925 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 926 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 927 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 928 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 929 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 931 Copyright Statement 933 Copyright (C) The Internet Society (2006). This document is subject 934 to the rights, licenses and restrictions contained in BCP 78, and 935 except as set forth therein, the authors retain all their rights. 937 Acknowledgment 939 Funding for the RFC Editor function is currently provided by the 940 Internet Society.