idnits 2.17.00 (12 Aug 2021) /tmp/idnits56735/draft-ietf-mip6-radius-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1210. 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 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 7, 2007) is 5553 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: '19' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1140, but no explicit reference was found in the text == Outdated reference: draft-ietf-mip6-bootstrapping-integrated-dhc has been published as RFC 6611 == Outdated reference: draft-ietf-mip6-bootstrapping-split has been published as RFC 5026 ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '15') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '16') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '17') (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Starent Networks 4 Intended status: Standards Track A. Lior 5 Expires: September 8, 2007 Bridgewater Systems 6 H. Tschofenig 7 Siemens 8 March 7, 2007 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 8, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 A Mobile IPv6 node requires a home agent(HA) address, a home 45 address(HOA), and IPsec security association with its HA before it 46 can start utilizing Mobile IPv6 service. RFC 3775 requires that some 47 or all of these parameters are statically configured. Ongoing work 48 aims to make this information dynamically available to the mobile 49 node. An important aspect of the Mobile IPv6 bootstrapping solution 50 is to support interworking with existing authentication, 51 authorization and accounting (AAA) infrastructure. This document 52 defines new attributes to facilitate Mobile IPv6 bootstrapping via a 53 RADIUS infrastructure. This information exchange may take place as 54 part of the initial network access authentication procedure or as 55 part of a separate protocol exchange between the mobile node, the HA 56 and the AAA infrastructure. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6 64 3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7 65 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9 66 4.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9 67 4.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9 68 4.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9 69 4.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9 70 4.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 9 71 4.6. Use of existing RADIUS Attributes . . . . . . . . . . . . 9 72 4.6.1. User-Name . . . . . . . . . . . . . . . . . . . . . . 9 73 4.6.2. Service-Type . . . . . . . . . . . . . . . . . . . . . 10 74 4.6.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . 10 75 4.6.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . 10 76 4.6.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . 10 77 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 11 79 5.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 12 80 5.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 13 81 5.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 14 82 5.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 15 83 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 17 85 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 17 86 6.1.2. HA allocation in the ASP (visited network) . . . . . . 18 87 6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 19 88 6.2.1. Mobile Service Provider and Mobile Service 89 Authorizer are the same entity. . . . . . . . . . . . 19 90 6.2.2. Mobile Service Provider and Mobile Service 91 Authorizer are different entities. . . . . . . . . . . 21 92 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 22 93 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 22 94 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 22 95 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 23 96 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 23 97 7.5. Provisioning of Configuration Parameters . . . . . . . . . 23 98 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 24 99 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 25 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 107 Intellectual Property and Copyright Statements . . . . . . . . . . 32 109 1. Introduction 111 Mobile IPv6 specification [6] requires a Mobile Node (MN) to perform 112 registration with an HA with information about its current point of 113 attachment (Care-of Address). The HA creates and maintains binding 114 between the MN's HOA and the MN's Care-of Address. 116 In order to register with a HA, the MN needs to know some information 117 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 118 prefix Length and security related information in order to secure the 119 Binding Update. 121 The aforementioned set of information may be statically provisioned 122 in the MN. However, static provisioning of this information has its 123 drawbacks. It increases provisioning and network maintenance burden 124 for the operator. Moreover, static provisioning does not allow load 125 balancing, failover, opportunistic home link assignment etc. For 126 example, the user may be accessing the network from a location that 127 may be geographically far away from the preconfigured home link; the 128 administrative burden to configure the MN's with the respective 129 addresses is large and the ability to react on environmental changes 130 is minimal. In these situations static provisioning may not be 131 desirable. 133 Dynamic assignment of Mobile IPv6 home registration information is a 134 desirable feature for ease of deployment and network maintenance. 135 For this purpose, the RADIUS infrastructure, which is used for access 136 authentication, can be leveraged to assign some or all of the 137 necessary parameters. The RADIUS server in the Access Service 138 Provider (ASP) or in the Mobility Service Provider's (MSP) network 139 may return these parameters to the AAA client. The AAA client might 140 either be the NAS, in case of the integrated scenario, or the HA, in 141 case of the split scenario. The terms integrated and split are 142 described in the terminology section and were introduced in [7]. 144 2. Terminology 146 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [1]. 150 General mobility terminology can be found in [8]. The following 151 additional terms, as defined in [7], are used in this document: 153 Access Service Authorizer (ASA): 155 A network operator that authenticates a MN and establishes the 156 MN's authorization to receive Internet service. 158 Access Service Provider (ASP): 160 A network operator that provides direct IP packet forwarding to 161 and from the MN. 163 Mobility Service Authorizer (MSA): 165 A service provider that authorizes Mobile IPv6 service. 167 Mobility Service Provider (MSP): 169 A service provider that provides Mobile IPv6 service. In order to 170 obtain such service, the MN must be authenticated and authorized 171 to obtain the Mobile IPv6 service. 173 Split Scenario: 175 A scenario where the mobility service and the network access 176 service are authorized by different entities. 178 Integrated Scenario: 180 A scenario where the mobility service and the network access 181 service are authorized by the same entity. 183 3. Solution Overview 185 This document addresses the authentication, authorization and 186 accounting functionality required by for the MIPv6 bootstrapping as 187 outlined in the MIPv6 bootstrapping problem statement document (see 188 [7]). As such, the AAA functionality for the integrated and the 189 split scenario needs to be defined. This requires the ability to 190 offer support for the HA to AAA server and the network access server 191 to AAA server communication. 193 To highlight the main use cases, we briefly describe the integrated 194 and the split scenarios in Section 3.1 and Section 3.2, respectively. 196 3.1. Integrated Scenario 198 In the integrated scenario MIPv6 bootstrapping is provided as part of 199 the network access authentication procedure. Figure 1 shows the 200 participating entity. 202 +---------------------------+ +-----------------+ 203 |Access Service Provider | |ASA/MSA/(/MSP) | 204 |(Mobility Service Provider)| | | 205 | | | +-------+ | 206 | +-------+ | | |Remote | | 207 | |Local | RADIUS | | |RADIUS | | 208 | |RADIUS |-------------------------|Server | | 209 | |Proxy | | | +-------+ | 210 | +-------+ | | ^ | 211 | ^ ^ | | |RADIUS | 212 | | | | | | | 213 | | | | | v | 214 | RADIUS| | | +-------+ | 215 | | | +-------+ | | |Local | | 216 | | | RADIUS |Home | | | |Home | | 217 | | +------->|Agent | | | |Agent | | 218 | | |in ASP | | | +-------+ | 219 | v +-------+ | +-----------------+ 220 +-------+ IEEE | +-----------+ +-------+ | 221 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 222 |Node |----------+-|RADIUS |---|Server | | 223 | | PANA,... | |Client | | | | 224 +-------+ DHCP | +-----------+ +-------+ | 225 +---------------------------+ 227 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 229 In the typical Mobile IPv6 access scenario as shown above, the MN 230 attaches in a ASP's network. During this network attachment 231 procedure, the NAS/RADIUS client interacts with the MN. As shown in 232 Figure 1, the authentication and authorization happens via a RADIUS 233 infrastructure. 235 At the time of authorizing the user for IPv6 access, the RADIUS 236 server in the MSA detects that the user is authorized for Mobile IPv6 237 access. Based on the MSA's policy, the RADIUS server may allocate 238 several parameters to the MN for use during the subsequent Mobile 239 IPv6 protocol interaction with the HA. 241 Depending on the details of the solution interaction with the DHCPv6 242 server may be required, as described in [2]. 244 3.2. Split Scenario 246 In the split scenario, Mobile IPv6 bootstrapping is not provided as 247 part of the network access authentication procedure. The Mobile IPv6 248 bootstrapping procedure is executed with the Mobility Service 249 Provider when desired by the MN. Two variations can be considered: 251 1. the MSA and the MSP are the same entity. 253 2. the MSA and the MSP are different entities. 255 Since scenario (2) is the more generic scenario we show it in 256 Figure 2. 258 +----------------------+ 259 | | 260 |Mobility +-------+ | 261 |Service |Remote | | 262 |Authorizer |RADIUS | | 263 |(MSA) |Server | | 264 | +-------+ | 265 +---------------^------+ 266 | 267 |RADIUS 268 | 269 | 270 +---------------------------------|------+ 271 |Mobility Service Provider (MSP) v | 272 +-------+ | +-----------+ +-------+ | 273 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 274 |Node |-------------|RADIUS |-------------- |RADIUS | | 275 | | IKEv2 | |Client | |Proxy | | 276 +-------+ | +-----------+ +-------+ | 277 +----------------------------------------+ 279 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 280 MSP) 282 As shown in Figure 2 the interaction between the RADIUS client and 283 the RADIUS server is triggered by the protocol interaction between 284 the MN and the HA/RADIUS client using IKEv2 (see [3] and [9]). The 285 HA / RADIUS Client interacts with the RADIUS infrastructure to 286 perform authentication, authorization, accounting and parameter 287 bootstrapping. The exchange is triggered by the HA and an 288 interaction with the RADIUS infrastructure is initiated. When the 289 protocol exchange is completed then the HA needs to possess the 290 Mobile IPv6 specific parameters (see [7]). 292 Additionally, the MN might instruct the RADIUS server (via the HA) to 293 perform a dynamic DNS update. 295 4. RADIUS Attribute Overview 297 4.1. MIP6-HA Attribute 299 The RADIUS server may decide to assign a HA to the MN that is in 300 close proximity to the point of attachment (e.g., as determined by 301 the NAS-ID). There may be other reasons for dynamically assigning 302 HAs to the MN, for example to share the traffic load. The attribute 303 also contains the prefix length so that the MN can easily infer the 304 Home Link prefix from the HA address. 306 4.2. MIP6-HA-FQDN Attribute 308 The RADIUS server may assign an FQDN of the HA to the MN. The mobile 309 node can perform DNS query with the FQDN to derive the HA address. 311 4.3. MIP6-HL-Prefix Attribute 313 For the same reason as the HA assignment, the RADIUS server may 314 assign a Home Link that is in close proximity to the point of 315 attachment (NAS-ID). The MN can perform [6] specific procedures to 316 discover other information for Mobile IPv6 registration. 318 4.4. MIP6-HOA Attribute 320 The RADIUS server may assign a HOA to the MN. This allows the 321 network operator to support mobile devices that are not configured 322 with static addresses. The attribute also contains the prefix length 323 so that the MN can easily infer the Home Link prefix from the HA 324 address. 326 4.5. MIP6-DNS-MO Attribute 328 By using this payload the RADIUS client instructs the RADIUS server 329 to perform a dynamic DNS update. When this payload is included in 330 the reverse direction, i.e., from the RADIUS server to the RADIUS 331 client, it informs about the status of the dynamic DNS update. When 332 the payload is sent from the RADIUS client to the RADIUS server then 333 the response MUST include the MIP6-DNS-MO attribute. 335 4.6. Use of existing RADIUS Attributes 337 4.6.1. User-Name 339 If authentication via IKEv2 is used then the User-Name attribute 340 SHALL be set to the IDi payload received in the IKE_AUTH exchange. 342 4.6.2. Service-Type 344 If the HA uses Service-Type(6) is SHALL set its value to "Framed"(2). 346 4.6.3. NAS-Port-Type 348 In order for the AAA to distingiues the source of the Access-Request 349 NAS-Port-Type(61) is used as follows: 351 In the split scenario when the Access-Request originates from an MIP6 352 HA, NAS-Port-Type MUST be included and its value set to HA6(IANA- 353 TBD1). 355 4.6.4. Calling-Station-Id 357 In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) 358 to send the MN's COA to the AAA. If used, the string value of the 359 Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. 361 4.6.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 363 To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize 364 the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [4]. The 365 first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, 366 and the next up to 32 octets are stored into the MS-MPPE-Send-Key. 367 The encryption of these attributes is described in [4]. 369 5. RADIUS attributes 371 This section defines format and syntax for the attribute that carries 372 the Mobile IPv6 parameters that are described in the previous 373 section. 375 The attributes MAY be present in Access-Request, Access-Accept, and 376 Accounting-Request packets. 378 5.1. MIP6-HA Attribute 380 One or more of this attribute is sent by the RADIUS server to the NAS 381 in an Access-Accept packet. The attribute carries the assigned HA 382 address. 384 This attribute MAY beMIP6-DNS-MO Attribute sent by the NAS to the 385 RADIUS server in an Access-Request packet as a hint to suggest a 386 dynamic HA that may be assigned to the MN. The RADIUS server MAY use 387 this value or may ignore this suggestion. 389 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 390 FQDN SHOULD appear in accounting packets to indicate the identity of 391 the serving HA for this session. 393 0 1 2 3 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | Reserved | Prefix-Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | IPv6 address of assigned HA | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | IPv6 address of assigned HA cont. | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | IPv6 address of assigned HA cont. | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | IPv6 address of assigned HA cont. | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | IPv6 address of assigned HA cont. | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | IPv6 address of assigned HA cont. | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Type: 413 ASSIGNED-HA-ADDR-TYPE to be defined by IANA. 415 Length: 417 = 21 octets 419 Reserved: 421 Reserved for future use. The bits MUST be set to zero by the 422 sender, and MUST be ignored by the receiver. 424 Prefix-Length: 426 This field indicates the prefix length of the Home Link. 428 IPv6 address of assigned HA: 430 128-bit IPv6 address of the assigned HA. 432 5.2. MIP6-HA-FQDN Attribute 434 One or more of this attribute is sent by the RADIUS server to the NAS 435 in an Access-Accept packet. The attribute carries the FQDN of the 436 assigned HA. 438 This attribute MAY be sent by the NAS to the RADIUS server in an 439 Access-Request packet as a hint to suggest a dynamic HA that may be 440 assigned to the MN. The RADIUS server MAY use this value or may 441 ignore this suggestion. 443 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 444 MIP6-HA SHOULD appear in accounting packets to indicate the identity 445 of the serving HA for this session. 447 0 1 2 3 448 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | FQDN of the assigned HA ..... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Type: 455 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 457 Length: 459 Variable length. 461 FQDN of the assigned HA: 463 The data field MUST contain a FQDN as described in [10]. 465 5.3. MIP6-HL-Prefix Attribute 467 This attribute is sent by the RADIUS-MIP server to the NAS in an 468 Access-Accept packet. The attribute carries the assigned Home Link 469 prefix. 471 This attribute MAY be sent by the NAS to the RADIUS server in an 472 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 473 attribute as a hint to suggest a Home Link prefix that may be 474 assigned to the MN. The RADIUS server MUST use this value if it 475 accepts the NAS's HA suggestion. 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type | Length | Reserved | Prefix-Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 | | 484 | Home Link Prefix | 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Type: 490 ASSIGNED-HL-TYPE to be defined by IANA. 492 Length: 494 >= 4 octets + the minimum length of a prefix. 496 Reserved: 498 Reserved for future use. The bits MUST be set to zero by the 499 sender, and MUST be ignored by the receiver. 501 Prefix-Length: 503 This field indicates the prefix length of the Home Link. 505 Home Link Prefix: 507 Home Link prefix (upper order bits) of the assigned Home Link 508 where the MN should send binding update. 510 5.4. MIP6-HOA Attribute 512 This attribute is sent by the RADIUS server to the NAS in an Access- 513 Accept packet. The attribute carries the assigned Home IPv6 Address 514 for the MN. 516 This attribute MAY be sent by the NAS to the RADIUS server in an 517 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 518 attribute as a hint to suggest a Home Address that may be assigned to 519 the MN. The RADIUS server MUST use this value if it accepts the 520 NAS's HA suggestion. 522 If available at the NAS, this attribute SHOULD appear in the 523 accounting packets so that the IPv6 addressed used for this session 524 is known in the accounting stream. 526 0 1 2 3 527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Length | Reserved | Prefix-Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 | | 533 | Assigned IPv6 HOA | 534 | | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Type: 539 ASSIGNED-HOA-TYPE to be defined by IANA. 541 Length: 543 = 20 octets. 545 Reserved: 547 Reserved for future use. The bits MUST be set to zero by the 548 sender, and MUST be ignored by the receiver. 550 Prefix-Length: 552 This field indicates the prefix length of the Home Link. 554 Assigned IPv6 HOA: 556 IPv6 HOA that is assigned to the MN. 558 5.5. MIP6-DNS-MO Attribute 560 The MIP6-DNS-MO attribute is used for triggering a DNS update by the 561 RADIUS server and to return the result to the RADIUS client. The 562 request MUST carry the MN's FQDN but the attribute carried in 563 response to the request MAY not carry a FQDN value. 565 0 1 2 3 566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Reserved-1 | Status | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |R| Reserved-2 | FQDN ... 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Type: 575 DNS-UPDATE-TYPE to be defined by IANA. 577 Length: 579 Variable length. 581 Reserved-1: 583 Reserved for future use. The bits MUST be set to zero by the 584 sender, and MUST be ignored by the receiver. 586 Status: 588 This 8 bit unsigned integer field indicates the result of the 589 dynamic DNS update procedure as defined in [3]. This field 590 MUST be set to 0 and ignored by the RADIUS server when the 591 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 592 server. When the MIP6-DNS-MO is provided in the response, 593 values of the Status field less than 128 indicate that the 594 dynamic DNS update was performed successfully by the RADIUS 595 server. Values greater than or equal to 128 indicate that the 596 dynamic DNS update was not successfully completed. The 597 following values for the Status field are currently defined: 599 0 DNS update performed 601 128 Reason unspecified 603 129 Administratively prohibited 604 130 DNS Update Failed 606 R flag: 608 If this bit for the R flag is set then the RADIUS client 609 requests the RADIUS server to remove the DNS entry identified 610 by the FQDN included in this attribute. If not set, the RADIUS 611 client is requesting the RADIUS server to create or update a 612 DNS entry with the FQDN specified in this attribute and the 613 Home Address carried in another attribute specified in this 614 document. 616 Reserved-2: 618 Reserved for future use. The bits MUST be set to zero by the 619 sender, and MUST be ignored by the receiver. 621 FQDN of the MN: 623 In an Access-Request packet the data field MUST contain a FQDN. 624 In an Access-Accept packet the data field MAY contain an FQDN. 625 FQDN is described in [10]. 627 6. Message Flows 629 6.1. Integrated Scenario (MSA=ASA) 631 This section is based on [2] and uses the previously defined RADIUS 632 attributes. 634 6.1.1. HA allocation in the MSP 636 RADIUS is used to authenticate the MN, to authorize it for the 637 mobility service and to send information about the assigned HA to the 638 NAS. 640 | 641 --------------ASP------>|<--ASA+MSA-- 642 | 643 +----+ +------+ +-------+ +-------+ 644 | | |RADIUS| | | | | 645 | | |Client| | | | | 646 | MN | |NAS/ | | DHCP | |Home | 647 | | |DHCP | | Server| |RADIUS | 648 | | |Relay | | | |Server | 649 +----+ +------+ +-------+ +-------+ 650 | | | | 651 | 1 | 1 | | 652 |<------------->|<---------------------->| 653 | | | | 654 | | | | 655 | 2 | | | 656 |-------------->| | | 657 | | | | 658 | | 3 | | 659 | |------------>| | 660 | | | | 661 | | 4 | | 662 | |<------------| | 663 | | | | 664 | 5 | | | 665 |<--------------| | | 666 | | | | 668 HA allocation in the MSP 670 In step (1), the MN executes the normal network access authentication 671 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 672 acts as an authenticator in "pass-through" mode, i.e., the endpoint 673 of the authentication dialogue is the MN's home RADIUS server. This 674 is the typical scenario in case the messages involved in the 675 authentication protocol are transported in EAP. 677 As per [11], the NAS encapsulates/decapsulates EAP packets into/from 678 RADIUS packets until an Access-Response (either an Access-Accept or 679 an Access/Reject packet is received by the NAS). This concludes the 680 network access authentication phase. 682 Depending on the RADIUS server configuration, the MIP6-HA attribute 683 or the the MIP6-HA-FQDN attribute may be appended to the Access- 684 Accept packet. In the latter case the MN needs to perform a DNS 685 query in order to discover the HA address. 687 The MIP6-HA or MIP6-HA-FQDN attribute is appended to the Access- 688 Accept in case the home RADIUS server knows or has allocated a HA to 689 the Access-Request (this is assumed in this scenario). 691 In step (2) the MN sends a DHCPv6 Information Request message to 692 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 693 for the Home Network Identifier Option shall be included in that 694 message. The Home Network Identifier Option should have id-type of 695 1, the message is a request to discover home network information that 696 pertains to the given realm, i.e., the user's home domain (identified 697 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 698 identify itself to the DHCP server. 700 In step (3) the DHCP relay agent forwards this request to the DHCP 701 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 702 message. This option carries the RADIUS MIP6-HA Attribute from the 703 Access-Accept packet. 705 In step (4), the DHCP server identifies the client (by DUID) and 706 finds out that it requests HA information in the MSP (by the Home 707 Network Identifier Option = 1). The DHCP server extracts the HA 708 address from OPTION_MIP6-RELAY-Option and places it into Home Network 709 Information Option in the Reply message. 711 In step (5), the Relay Agent forwards the Reply Message to the MN. 712 On reception of this message, the HA address or the FQDN of the HA is 713 available at the MN. 715 6.1.2. HA allocation in the ASP (visited network) 717 This scenario is similar to the one described in Section 6.1.1. The 718 difference is in step (2), where the type-id field in the Home 719 Network Identifier Option is set to zero, indicating that a HA is 720 requested in the ASP instead of in the MSP. Thus, the information 721 received by the home RADIUS server, via the DHCP relay, in the 722 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 723 server allocates a HA from its list of possible HAs and returns it in 724 the Reply message (Home Network Information Option). 726 6.2. Split Scenario (MSA!=ASA) 728 6.2.1. Mobile Service Provider and Mobile Service Authorizer are the 729 same entity. 731 The assumption in this scenario is that the MN has the domain name of 732 the MSP preconfigured. 734 In this scenario there is no relationship between the network access 735 authentication procedure and the MIPv6 bootstrapping procedure. 737 In order to learn the IP address of the HA, the MN either performs a 738 DNS lookup of the HA Name or a DNS lookup by service name. In the 739 first case, the MN is preconfigured with the FQDN of the HA, and thus 740 sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request 741 for IPv6 address of HA). A DNS reply message is returned by the DNS 742 server with the HA address. 744 The MN then runs IKEv2 [12] with the HA in order to set up IPsec SAs 745 (MN-HA). As part of this,the MN authenticates itself to the RADIUS 746 server in the MSA domain, and obtains authorization for mobility 747 service (including the Home Address). 749 The MN shares credentials with the RADIUS server in the MSA domain. 750 The RADIUS communication between the HA and the this RADIUS server is 751 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 752 within IKEv2 [12], the MN is authenticated and authorized for the 753 IPv6 mobility service and is also assigned a HOA. 755 The setup of SAs and mutual authentication between MN and AAAH using 756 RADIUS (and EAP) is similar to the one described for Diameter 757 protocol in [13]. The described mechanism ensureas that common 758 keying material will be available at the MN and HA after successful 759 completion. 761 ----------------------------ASP--------->|<-----MSA/MSP 763 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 764 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 765 +----+ +----+ +--------------------+ 767 MN HA Remote RADIUS server 768 -- -- -------------------- 769 IKE_SA_INIT 770 <------------------------------> 772 HDR, SK{IDi,[CERTREQ,] [IDr,] 773 SAi2, TSi, TSr} 774 -------------------------------> 775 RADIUS Access-Request(EAP-Response) 776 ----------------------------------> 777 RADIUS Access-Challenge(EAP-Request) 778 <----------------------------------- 779 HDR, SK {IDr, [CERT,] AUTH, 780 EAP } 781 <------------------------------- 782 HDR, SK {EAP} 783 --------------------------------> 784 RADIUS Access-Request(EAP-Response) 785 ----------------------------------> 786 RADIUS Access-Challenge(EAP-Request) 787 <----------------------------------- 788 HDR, SK{EAP-Request} 789 <------------------------------- 790 HDR, SK{EAP-Response} 791 --------------------------------> 792 RADIUS Access-Request(EAP-Response) 793 ----------------------------------> 794 ... ... 796 RADIUS Access-Accept(EAP-Success) 797 <------------------------ 799 HDR, SK{EAP-Success} 800 <------------------------------- 801 HDR, SK{AUTH} 802 -------------------------------> 803 HDR, SK {AUTH, SAr2, TSi, TSr } 804 <------------------------------- 806 Split Scenario Exchange 808 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 809 defined in the IKEv2 specification [12], negotiating crypto 810 algorithms and running DH key exchange). IKEv2 supports integration 811 with EAP. The MN indicates its desire to use EAP by not including 812 the AUTH payload in the third message. However, it indicates its 813 identity (NAI) by using the IDi field. If the HA supports EAP for 814 authentication, as per [11] it forwards the identity to the Remote 815 RADIUS server by sending a RADIUS Access-Request packet containing 816 the identity in the EAP-Payload AVP and in the RADIUS User-Name 817 attribute. Based on this identity, the Remote RADIUS server chooses 818 authentication method and sends the first EAP-Request in the RADIUS 819 Access-Challenge packet. During the EAP authentication phase, the HA 820 relays EAP packets between the MN and the Remote RADIUS server. If 821 the authentication succeeds and if the MN is authorized to use Mobile 822 IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept 823 packet containing the EAP-Success and the AAA-Key derived from the 824 EAP authentication method. EAP authentication methods that do not 825 derive keys are not recommended. This key is used by both MN and HA 826 to generate the AUTH payload. In subsequent messages, MN and HA 827 setup IPsec SAs for Mobile IPv6. 829 6.2.2. Mobile Service Provider and Mobile Service Authorizer are 830 different entities. 832 The HA address discovery is performed as described in Section 6.2.1. 834 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 836 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 837 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 838 +----+ +----+ |RADIUS| |RADIUS| 839 |Proxy | |Server| 840 +------+ +------+ 842 MSP#MSA Exchange 844 The scenario is similar to previously described scenarios with the 845 difference of utilizing AAA roaming agreements between the MSP and 846 the MSA. 848 7. Goals for the HA-AAA Interface 850 Here, we follow the classification and labels listed in the MIPv6- 851 AAA-Goals document [14]. 853 7.1. General Goals 855 G1.1-G1.4 Security 857 These are standard requirements for a AAA protocol - mutual 858 authentication, integrity, replay protection, confidentiality. IPsec 859 can be used to achieve the goals. Goal G1.5 regarding inactive peer 860 detection needs further investigations since heartbeat messages do 861 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 863 7.2. Service Authorization 865 G2.1. The AAA-HA interface should allow the use of Network Access 866 Identifier (NAI) to identify the MN. The User-Name attribute can be 867 used for the purpose to carry the NAI. 869 G2.2 The HA should be able to query the AAAH server to verify Mobile 870 IPv6 service authorization for the MN. Any node implementing RADIUS 871 functionality[5] can possibly initiate a request message. In 872 combination with the ability of the RADIUS protocol to carry EAP 873 messages [11] , our solution will enable an HA to query a RADIUS 874 server and verify MIPv6 authorization for the MN. 876 G2.3 The AAAH server should be able to enforce explicit operational 877 limitations and authorization restrictions on the HA (e.g., packet 878 filters, QoS parameters). Work in progress in the area, including 879 NAS-Filter-Rule, RADIUS quality of service support, prepaid 880 extensions etc. is performed. The relevant attributes may be reused 881 for providing required functionality over the AAAH-HA interface. 883 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 884 session by the AAAH server, e.g., authorization lifetime, extension 885 of the authorization lifetime and explicit session termination by the 886 AAAH server side. 888 The attribute Session-Timeout may be sent in Access-Challenge or 889 Access-Accept packet by the RADIUS server, thus limiting the 890 authorization session duration. In order to reauthenticate/ 891 reauthorize the user, the Termination-Action attribute can be 892 included, with value 1, meaning the NAS should send a new RADIUS- 893 Request packet. Additional AVPs for dealing with pre-paid sessions 894 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 895 specified in RADIUS prepaid extension. Exchanging of application 896 specific authorization request/answer messages provides extension of 897 the authorization session (e.g., Authorize Only Access-Request sent 898 by the HA (NAS) to the RADIUS server). Initiation of the re- 899 authorization by both sides could be supported. Both sides could 900 initiate session termination - the RADIUS server by sending 901 Disconnect message [15]. 903 7.3. Accounting 905 G3.1 The AAA-HA interface must support the transfer of accounting 906 records needed for service control and charging. These include (but 907 may not be limited to): time of binding cache entry creation and 908 deletion, octets sent and received by the MN in bi-directional 909 tunneling, etc. 911 The requirements for accounting over the AAAH-HA interface does not 912 require enhancements to the existing accounting functionality. 914 7.4. MN Authentication 916 G4.1 The AAA-HA interface MUST support pass-through EAP 917 authentication with the HA working as EAP authenticator operating in 918 pass-through mode and the AAAH server working as back-end 919 authentication server. 921 These issues require the functionality of AAAH server working as a 922 back-end authentication server and HA working as NAS and EAP 923 authenticator in pass-through mode for providing a MN authentication. 924 This document suggests this mode of operation in the context of the 925 relevant scenarios. 927 7.5. Provisioning of Configuration Parameters 929 G5.1 The HA should be able to communicate to the AAAH server the HOA 930 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 931 update on behalf of the MN). 933 This document describes needed AVPs for this purpose, see section 934 "DNS Update Mobility Option Attribute" 936 8. Table of Attributes 938 The following tables provides a guide to which attributes may be 939 found in RADIUS packet and in what number. 941 The following defines the meaning of the notation used in the following 942 tables: 944 0 This attribute MUST NOT be present. 945 0-1 Zero or one instance of this attribute MAY be present. 947 Request Accept Reject Challenge Type Attribute 949 0-1[a] 0-1[a] 0 0 MIP6-HA-TYPE MIP6-HA Attribute 950 0-1[a] 0-1[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 951 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 952 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA Attribute 953 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 955 Notes: 957 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 959 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 960 then these attributes MUST also be present in the Access-Request. 961 If the RADIUS server accepts the NAS suggestion for the HA, then 962 the RADIUS server MUST also include the values received for these 963 attributes in the Access-Accept. 965 As used in accounting packets: 967 Request Interim Stop Type Attribute 969 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 970 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 971 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 972 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 973 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 975 9. Diameter Considerations 977 When used in Diameter, the attributes defined in this specification 978 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 979 attribute compatibility space). No additional Diameter Code values 980 are therefore allocated. The data types and flag rules for the 981 attributes are as follows: 983 +---------------------+ 984 | AVP Flag rules | 985 |----+-----+----+-----|----+ 986 | | |SHLD| MUST| | 987 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 988 -------------------------------|----+-----+----+-----|----| 989 MIP6-HA Address | M | P | | V | Y | 990 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 991 MIP6-HL-Prefix OctetString| M | P | | V | Y | 992 MIP6-HOA Address | M | P | | V | Y | 993 MIP6-DNS-MO OctetString| M | P | | V | Y | 994 -------------------------------|----+-----+----+-----|----| 996 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 997 have no special translation requirements for Diameter to RADIUS or 998 RADIUS to Diameter gateways; they are copied as is, except for 999 changes relating to headers, alignment, and padding. See also [16] 1000 Section 4.1 and [17] Section 9. MIP6-HA and HOA-IPv6 must be 1001 translated between their RADIUS representation of String to a 1002 Diameter Address format which requires that the AddressType field be 1003 set to 2 for IP6 (IP version 6) 1005 What this specification says about the applicability of the 1006 attributes for RADIUS Access-Request packets applies in Diameter to 1007 AA-Request [17] or Diameter-EAP-Request [18]. What is said about 1008 Access-Challenge applies in Diameter to AA-Answer [17] or Diameter- 1009 EAP-Answer [18] with Result-Code AVP set to 1010 DIAMETER_MULTI_ROUND_AUTH. 1012 What is said about Access-Accept applies in Diameter to AA-Answer or 1013 Diameter-EAP-Answer messages that indicate success. Similarly, what 1014 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1015 Answer or Diameter-EAP-Answer messages that indicate failure. 1017 What is said about Accounting-Request applies to Diameter Accounting- 1018 Request [17] as well. 1020 10. Security Considerations 1022 Assignment of these values to a user should be based on successful 1023 authentication of the user at the NAS and/or at the HA. The RADIUS 1024 server should only assign these values to a user who is authorized 1025 for Mobile IPv6 service (this check could be performed with the 1026 user's subscription profile in the Home Network). 1028 The NAS and the HA to the RADIUS server transactions must be 1029 adequately secured. Otherwise there is a possibility that the user 1030 may receive fraudulent values from a rogue RADIUS server potentially 1031 hijacking the user's Mobile IPv6 session. 1033 These new attributes do not introduce additional security 1034 considerations besides the ones identified in [5]. 1036 11. IANA Considerations 1038 The following RADIUS attribute Type values MUST be assigned by IANA. 1040 MIP6-HA-TYPE 1042 MIP6-HA-FQDN-TYPE 1044 MIP6-HL-PREFIX-TYPE 1046 MIP6-HOA-TYPE 1048 MIP6-DNS-MO-TYPE 1050 A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) 1052 12. Acknowledgements 1054 We would like to thank the following individuals for their review and 1055 constructive comments during the development of this document: 1057 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1058 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1060 13. References 1062 13.1. Normative References 1064 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1065 Levels", BCP 14, RFC 2119, March 1997. 1067 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1068 Integrated Scenario", 1069 draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in 1070 progress), February 2007. 1072 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1073 draft-ietf-mip6-bootstrapping-split-04 (work in progress), 1074 December 2006. 1076 [4] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1077 RFC 2548, March 1999. 1079 [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1080 Authentication Dial In User Service (RADIUS)", RFC 2865, 1081 June 2000. 1083 13.2. Informative References 1085 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1086 IPv6", RFC 3775, June 2004. 1088 [7] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 1089 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 1090 progress), May 2006. 1092 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 1093 RFC 3753, June 2004. 1095 [9] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1096 IKEv2 and the revised IPsec Architecture", 1097 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1098 December 2006. 1100 [10] Mockapetris, P., "Domain names - implementation and 1101 specification", STD 13, RFC 1035, November 1987. 1103 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1104 In User Service) Support For Extensible Authentication Protocol 1105 (EAP)", RFC 3579, September 2003. 1107 [12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1108 RFC 4306, December 2005. 1110 [13] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", 1111 draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), 1112 October 2005. 1114 [14] Giaretta, G., "AAA Goals for Mobile IPv6", 1115 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1116 September 2006. 1118 [15] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1119 "Dynamic Authorization Extensions to Remote Authentication Dial 1120 In User Service (RADIUS)", RFC 3576, July 2003. 1122 [16] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1123 "Diameter Base Protocol", RFC 3588, September 2003. 1125 [17] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1126 Network Access Server Application", RFC 4005, August 2005. 1128 [18] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1129 Authentication Protocol (EAP) Application", RFC 4072, 1130 August 2005. 1132 [19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1133 "DNS Security Introduction and Requirements", RFC 4033, 1134 March 2005. 1136 [20] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1137 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1138 Agents", RFC 3776, June 2004. 1140 [21] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1141 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1142 April 1997. 1144 Authors' Addresses 1146 Kuntal Chowdhury 1147 Starent Networks 1148 30 International Place 1149 Tewksbury, MA 01876 1150 US 1152 Phone: +1 214-550-1416 1153 Email: kchowdhury@starentnetworks.com 1155 Avi Lior 1156 Bridgewater Systems 1157 303 Terry Fox Drive, Suite 100 1158 Ottawa, Ontario 1159 Canada K2K 3J1 1161 Phone: +1 613-591-6655 1162 Email: avi@bridgewatersystems.com 1164 Hannes Tschofenig 1165 Siemens 1166 Otto-Hahn-Ring 6 1167 Munich, Bavaria 81739 1168 Germany 1170 Email: Hannes.Tschofenig@siemens.com 1172 Full Copyright Statement 1174 Copyright (C) The IETF Trust (2007). 1176 This document is subject to the rights, licenses and restrictions 1177 contained in BCP 78, and except as set forth therein, the authors 1178 retain all their rights. 1180 This document and the information contained herein are provided on an 1181 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1182 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1183 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1184 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1185 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1186 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1188 Intellectual Property 1190 The IETF takes no position regarding the validity or scope of any 1191 Intellectual Property Rights or other rights that might be claimed to 1192 pertain to the implementation or use of the technology described in 1193 this document or the extent to which any license under such rights 1194 might or might not be available; nor does it represent that it has 1195 made any independent effort to identify any such rights. Information 1196 on the procedures with respect to rights in RFC documents can be 1197 found in BCP 78 and BCP 79. 1199 Copies of IPR disclosures made to the IETF Secretariat and any 1200 assurances of licenses to be made available, or the result of an 1201 attempt made to obtain a general license or permission for the use of 1202 such proprietary rights by implementers or users of this 1203 specification can be obtained from the IETF on-line IPR repository at 1204 http://www.ietf.org/ipr. 1206 The IETF invites any interested party to bring to its attention any 1207 copyrights, patents or patent applications, or other proprietary 1208 rights that may cover technology that may be required to implement 1209 this standard. Please address the information to the IETF at 1210 ietf-ipr@ietf.org. 1212 Acknowledgment 1214 Funding for the RFC Editor function is provided by the IETF 1215 Administrative Support Activity (IASA).