idnits 2.17.1 draft-chowdhury-mip6-radius-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. ** 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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack 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 (October 21, 2005) is 6755 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: 'AAA-Goals' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'MIP6-IKEv2' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC3776' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 647, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-00 -- No information found for draft-ietf-mip6-bootstrapping-integrated-DHC - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DHCP-INT' == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-00 == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-03 == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-03 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 10 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 Expires: April 24, 2006 A. Lior 5 Bridgewater Systems 6 H. Tschofenig 7 Siemens 8 October 21, 2005 10 RADIUS Mobile IPv6 Support 11 draft-chowdhury-mip6-radius-00.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 April 24, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 A Mobile IPv6 node requires a home agent address, a home address, and 45 IPsec security association with its home agent before it can start 46 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 47 these parameters are statically configured. Ongoing work aims to 48 make this information dynamically available to the mobile node. An 49 important aspect of the Mobile IPv6 bootstrapping solution is to 50 support interworking with existing authentication, authorization and 51 accounting infrastructure. This document defines the new attributes 52 to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. 53 This information exchange may take place as part of the initial 54 network access authentication procedure or as part of a separate 55 protocol exchange between the mobile node, the home agent and the AAA 56 infrastructure. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . 5 63 3.1 Integrated Scenario . . . . . . . . . . . . . . . . . . . 5 64 3.2 Split Scenario . . . . . . . . . . . . . . . . . . . . . . 6 65 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . 8 66 4.1 Home Agent Address Attribute . . . . . . . . . . . . . . . 8 67 4.2 Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 8 68 4.3 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 8 69 4.4 Home Address Attribute . . . . . . . . . . . . . . . . . . 8 70 4.5 DNS Update Mobility Option Attribute . . . . . . . . . . . 8 71 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . 9 72 5.1 Home Agent Address Attribute . . . . . . . . . . . . . . . 9 73 5.2 Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 10 74 5.3 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 10 75 5.4 Home Address Attribute . . . . . . . . . . . . . . . . . . 11 76 5.5 DNS Update Mobility Option Attribute . . . . . . . . . . . 12 77 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . 14 78 7. Mapping of the Requirements . . . . . . . . . . . . . . . . 15 79 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . 16 80 9. Security Considerations . . . . . . . . . . . . . . . . . . 17 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 12.1 Normative References . . . . . . . . . . . . . . . . . . 20 85 12.2 Informative References . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 87 Intellectual Property and Copyright Statements . . . . . . . 22 89 1. Introduction 91 Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to 92 perform registration with a Home Agent with information about its 93 current point of attachment (Care-of Address). The Home Agent 94 creates and maintains binding between the MN's Home Address and the 95 MN's Care-of Address. 97 In order to register with a Home Agent, the MN needs to know some 98 information such as, the Home Link prefix, the Home Agent Address, 99 the Home Address, the Home Link prefix Length and security related 100 information in order to secure the Binding Update. 102 The aforementioned set of information may be statically provisioned 103 in the MN. However, static provisioning of this information has its 104 drawbacks. It increases provisioning and network maintenance burden 105 for the operator. Moreover, static provisioning does not allow load 106 balancing, failover, opportunistic home link assignment etc. For 107 example, the user may be accessing the network from a location that 108 may be geographically far away from the preconfigured home link; the 109 administrative burden to configure the MN's with the respective 110 addresses is large and the ability to react on environmental changes 111 is minimal. In these situations static provisioning may not be 112 desirable. 114 Dynamic assignment of Mobile IPv6 home registration information is a 115 desirable feature for ease of deployment and network maintenance. 116 For this purpose, the RADIUS infrastructure, which is used for access 117 authentication, can be leveraged to assign some or all of the 118 necessary parameters. The RADIUS server in the Access Service 119 Provider (ASP) or in the Mobility Service Provider's (MSP) network 120 may return these parameters to the AAA client. The AAA client might 121 either be the NAS, in case of the integrated scenario, or the home 122 agent, in case of the split scenario. The terms integrated and split 123 are described in the terminology section and were introduced in 124 [BOOT-PS]. 126 2. Terminology 128 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 130 this document are to be interpreted as described in [RFC2119]. 132 General mobility terminology can be found in [RFC3753]. The 133 following additional terms, as defined in [BOOT-PS], are used in this 134 document: 136 Access Service Authorizer (ASA): A network operator that 137 authenticates a mobile node and establishes the mobile node's 138 authorization to receive Internet service. 140 Access Service Provider (ASP): A network operator that provides 141 direct IP packet forwarding to and from the mobile node. 143 Mobility Service Authorizer (MSA): A service provider that authorizes 144 Mobile IPv6 service. 146 Mobility Service Provider (MSP): A service provider that provides 147 Mobile IPv6 service. In order to obtain such service, the mobile 148 node must be authenticated and authorized to obtain the Mobile IPv6 149 service. 151 Split scenario: A scenario where the mobility service and the network 152 access service are authorized by different entities. 154 Integrated Scenario: A scenario where the mobility service and the 155 network access service are authorized by the same entity. 157 3. Solution Overview 159 This document addresses the authentication, authorization and 160 accounting functionality required by for the MIPv6 bootstrapping as 161 outlined in the MIPv6 bootstrapping problem statement document (see 162 [BOOT-PS]). As such, the AAA functionality for the integrated and 163 the split scenario needs to be defined. This requires the ability to 164 offer support for the home agent to AAA server and the network access 165 server to AAA server communication. 167 To highlight the main use cases, we briefly describe the integrated 168 and the split scenarios in Section 3.1 and Section 3.2, respectively. 170 3.1 Integrated Scenario 172 In the integrated scenario MIPv6 bootstrapping is provided as part of 173 the network access authentication procedure. Figure 1 shows the 174 participating entity. 176 +---------------------------+ +-----------------+ 177 |Access Service Provider | |ASA/MSA/(/MSP) | 178 |(Mobility Service Provider)| | | 179 | | | +-------+ | 180 | +-------+ | | |Remote | | 181 | |Local | RADIUS | | |RADIUS | | 182 | |RADIUS |-------------------------|Server | | 183 | |Proxy | | | +-------+ | 184 | +-------+ | | ^ | 185 | ^ | | |RADIUS | 186 | | | | | | 187 | | | | v | 188 | |RADIUS | | +-------+ | 189 | | +-------+ | | |Local | | 190 | | RADIUS |Home | | | |Home | | 191 | | +----->|Agent | | | |Agent | | 192 | | | |in ASP | | | +-------+ | 193 | v v +-------+ | +-----------------+ 194 +-------+ IEEE | +-----------+ +-------+ | 195 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 196 |Node |----------+-|RADIUS |---|Server | | 197 | | PANA,... | |Client | | | | 198 +-------+ DHCP | +-----------+ +-------+ | 199 +---------------------------+ 201 Figure 1. Mobile IPv6 service access in the integrated scenario 202 In the typical Mobile IPv6 access scenario as shown above, the MN 203 attaches in a Access Service Provider's network. During this network 204 attachment procedure, the NAS/RADIUS client interacts with the mobile 205 node. As shown in Figure 1, the authentication and authorization 206 happens via a RADIUS infrastructure. 208 At the time of authorizing the user for IPv6 access, the RADIUS 209 server in the MSA detects that the user is authorized for Mobile IPv6 210 access. Based on the MSA's policy, the RADIUS server may allocate 211 several parameters to the MN for use during the subsequent Mobile 212 IPv6 protocol interaction with the home agent. 214 Depending on the details of the solution interaction with the DHCPv6 215 server may be required, as described in [DHCP-INT]. 217 3.2 Split Scenario 219 In the split scenario, Mobile IPv6 bootstrapping is not provided as 220 part of the network access authentication procedure. The Mobile IPv6 221 bootstrapping procedure is executed with the Mobility Service 222 Provider when desired by the mobile node. Two variations can be 223 considered: 225 a) the MSA and the MSP are the same entity. 227 b) the MSA and the MSP are different entities. 229 Since scenario (b) is the more generic scenario we show it in Figure 230 2. 232 +----------------------+ 233 | | 234 |Mobility +-------+ | 235 |Service |Remote | | 236 |Authorizer |RADIUS | | 237 |(MSA) |Server | | 238 | +-------+ | 239 +---------------^------+ 240 | 241 |RADIUS 242 | 243 | 244 +---------------------------------|------+ 245 |Mobility Service Provider (MSP) v | 246 +-------+ | +-----------+ +-------+ | 247 |Mobile | MIPv6 / | |Home Agent/| RADIUS |Local | | 248 |Node |-------------|RADIUS |-------------- |RADIUS | | 249 | | IKEv2 | |Client | |Proxy | | 250 +-------+ | +-----------+ +-------+ | 251 +----------------------------------------+ 253 Figure 2. Mobile IPv6 service access in the split scenario (MAS != 254 MSP) 256 As shown in Fig. 2 the interaction between the RADIUS client and the 257 RADIUS server is triggered by the protocol interaction between the 258 mobile node and the home agent/RADIUS client using IKEv2 (see [BOOT- 259 SPLIT]). The home agent / RADIUS Client interacts with the RADIUS 260 infrastructure to perform authentication, authorization, accounting 261 and parameter bootstrapping. The exchange is triggered by the home 262 agent and an interaction with the RADIUS infrastructure is initiated. 263 When the protocol exchange is completed then the home agent needs to 264 possess the Mobile IPv6 specific parameters (see [BOOT-PS]). 266 Additionally, the mobile node might instruct the RADIUS server (via 267 the home agent) to perform a dynamic DNS update. 269 4. RADIUS Attribute Overview 271 4.1 Home Agent Address Attribute 273 The RADIUs server may decide to assign a Home Agent to the MN that is 274 in close proximity to the point of attachment (e.g., determined by 275 the NAS-ID). There may be other reasons for dynamically assigning 276 Home Agents to the MN, for example to share the traffic load. The 277 attribute also contains the prefix length so that the MN can easily 278 infer the Home Link prefix from the Home Agent address. 280 4.2 Home Agent FQDN Attribute 282 The RADIUS server may assign an FQDN of the home address to the MN. 283 The mobile node can perform DNS query with the FQDN to derive the 284 home agent address. 286 4.3 Home Link Prefix Attribute 288 For the same reason as the HA assignment, the RADIUS server may 289 assign a Home Link that is in close proximity to the point of 290 attachment (NAS-ID). The MN can perform [RFC3775] specific 291 procedures to discover other information for Mobile IPv6 292 registration. 294 4.4 Home Address Attribute 296 The RADIUS server may assign a Home Address to the MN. This allows 297 the network operator to support mobile devices that are not 298 configured with static addresses. The attribute also contains the 299 prefix length so that the MN can easily infer the Home Link prefix 300 from the Home Agent address. 302 4.5 DNS Update Mobility Option Attribute 304 By using this payload the RADIUS client instructs the RADIUS server 305 to perform a dynamic DNS update. When this payload is included in 306 the reverse direction, i.e., from the RADIUS server to the RADIUS 307 client, it informs about the status of the dynamic DNS update. When 308 the payload is sent from the RADIUS client to the RADIUS server then 309 the response MUST include the DNS Update Mobility Option attribute. 311 5. RADIUS attributes 313 This section defines format and syntax for the attribute that carries 314 the Mobile IPv6 parameters that are described in the previous 315 section. 317 The attributes MAY be present in Access-Accept, Accounting-Request. 319 5.1 Home Agent Address Attribute 321 This attribute is sent by the RADIUS server to the NAS in an Access- 322 Accept message. The attribute carries the assigned Home Agent 323 address. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | Reserved | Prefix-Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 | | 332 | IPv6 address of assigned Home Agent | 333 | | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Type: 339 ASSIGNED-HA-ADDR-TYPE to be defined by IANA. 341 Length: 343 = 20 octets 345 Reserved: 347 Reserved for future use. All bits set to 0. 349 Prefix-Length: 351 This field indicates the prefix length of the Home Link. 353 IPv6 address of assigned Home Agent: 355 128-bit IPv6 address of the assigned Home Agent. 357 5.2 Home Agent FQDN Attribute 359 This attribute is sent by the RADIUS server to the NAS in an Access- 360 Accept message. The attribute carries the FQDN of the assigned home 361 agent. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | FQDN of the assigned home agent ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Type: 373 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 375 Length: 377 Variable length. 379 Reserved: 381 Reserved for future use. All bits set to 0. 383 FQDN of the assigned home agent: 385 The data field MUST contain a FQDN as described in [RFC1035]. 387 5.3 Home Link Prefix Attribute 389 This attribute is sent by the RADIUS-MIP server to the NAS in an 390 Access-Accept message. The attribute carries the assigned Home Link 391 prefix. 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 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 | | 400 | Home Link Prefix | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Type: 406 ASSIGNED-HL-TYPE to be defined by IANA. 408 Length: 410 >= 4 octets + the minimum length of a prefix. 412 Reserved: 414 Reserved for future use. All bits set to 0. 416 Home Link Prefix: 418 Home Link prefix (upper order bits) of the assigned Home Link 419 where the MN should send binding update. 421 5.4 Home Address Attribute 423 This attribute is sent by the RADIUS server to the NAS in an Access- 424 Accept message. The attribute carries the assigned Home IPv6 Address 425 for the MN. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | Reserved | Prefix-Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 | | 434 | Assigned IPv6 Home Address | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Type: 439 ASSIGNED-HOA-TYPE to be defined by IANA. 441 Length: 443 = 20 octets. 445 Reserved: 447 Reserved for future use. All bits set to 0. 449 Prefix-Length: 451 This field indicates the prefix length of the Home Link. 453 Assigned IPv6 Home Address: 455 IPv6 Home Address that is assigned to the MN. 457 5.5 DNS Update Mobility Option Attribute 459 The DNS Update Mobility Option attribute is used for triggering a DNS 460 update by the RADIUS server and to return the result to the RADIUS 461 client. The request MUST carry the mobile node's FQDN but the 462 attribute carried in response to the request MAY not carry a FQDN 463 value. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type | Length | Reserved-1 | Status | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |R| Reserved-2 | FQDN ... 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Type: 475 DNS-UPDATE-TYPE to be defined by IANA. 477 Length: 479 Variable length. 481 Reserved-1: 483 Reserved for future use. All bits set to 0. 485 Status: 487 This 8 bit unsigned integer field indicates the result of the 488 dynamic DNS update procedure. This field MUST be set to 0 and 489 ignored by the RADIUS server when the DNS Update Mobility 490 Option is sent from the RADIUS client to the RADIUS server. 491 When the DNS Update Mobility Option is provided in the 492 response, values of the Status field less than 128 indicate 493 that the dynamic DNS update was performed successfully by the 494 RADIUS server. Values greater than or equal to 128 indicate 495 that the dynamic DNS update was not successfully completed. 496 The following values for the Status field are currently 497 defined: 499 0 DNS update performed 501 128 Reason unspecified 503 129 Administratively prohibited 505 130 DNS Update Failed 507 R flag: 509 If this bit for the R flag is set then the RADIUS client 510 requests the RADIUS server to remove the DNS entry identified 511 by the FQDN included in this attribute. If not set, the RADIUS 512 client is requesting the RADIUS server to create or update a 513 DNS entry with the FQDN specified in this attribute and the 514 Home Address carried in another attribute specified in this 515 document. 517 Reserved-2: 519 Reserved for future use. All bits set to 0. 521 FQDN of the mobile node: 523 The data field MUST contain a FQDN as described in [RFC1035]. 525 6. Message Flows 527 [Editor's Note: A future version of this document will provide 528 example message flows.] 530 7. Mapping of the Requirements 532 [Editor's Note: A future version of this document will map the 533 requirements listed in [AAA-Goals]] with the solution provided in 534 this document.] 536 8. Table of Attributes 538 The following table provides a guide to which attributes may be found 539 in RADIUS message and in what number. 541 Request Accept Reject Challenge Attribute 543 0-1 0-1 0 0 Home Agent Address Attribute 544 0-1 0-1 0 0 Home Agent FQDN Attribute 545 0-1 0-1 0 0 Home Link Prefix Attribute 546 0-1 0-1 0 0 Home Address Attribute 547 0-1 0-1 0 0 DNS Update Mobility Option 548 Attribute 550 The following table defines the meaning of the above table entries. 552 0 This attribute MUST NOT be present. 553 0-1 Zero or one instance of this attribute MAY be present. 555 9. Security Considerations 557 Assignment of these values to a user should be based on successful 558 authentication of the user at the NAS and/or at the home agent. The 559 RADIUS server should only assign these values to a user who is 560 authorized for Mobile IPv6 service (this check could be performed 561 with the user's subscription profile in the Home Network). 563 The NAS and the home agent to the RADIUS server transactions must be 564 adequately secured. Otherwise there is a possibility that the user 565 may receive fraudulent values from a rogue RADIUS server potentially 566 hijacking the user's Mobile IPv6 session. 568 These new attributes do not introduce additional security 569 considerations besides the ones identified in [RFC2865]. 571 10. IANA Considerations 573 The following RADIUS attribute Type values MUST be assigned by IANA. 575 ASSIGNED-HA-ADDR-TYPE 577 ASSIGNED-HA-FQDN-TYPE 579 ASSIGNED-HL-TYPE 581 ASSIGNED-HOA-TYPE 583 DNS-UPDATE-TYPE 585 11. Acknowledgements 587 We would like to thank the following individuals for their review and 588 constructive comments during the development of this document: 590 Mark Watson, Jayshree Bharatia of Nortel. 592 12. References 594 12.1 Normative References 596 [BOOT-SPLIT] 597 Giaretta et. al., G., "Mobile IPv6 bootstrapping in split 598 scenario.", draft-ietf-mip6-bootstrapping-split-00.txt 599 (work in progress), June 2005. 601 [DHCP-INT] 602 Chowdhury et. al., K., "MIP6-bootstrapping via DHCPv6 for 603 the Integrated Scenario.", 604 draft-ietf-mip6-bootstrapping-integrated-DHC-00.txt (work 605 in progress), October 2005. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 611 "Remote Authentication Dial In User Service (RADIUS)", 612 RFC 2865, June 2000. 614 12.2 Informative References 616 [AAA-Goals] 617 Giaretta et. al., G., "Goals for AAA-HA interface.", 618 draft-ietf-mip6-aaa-ha-goals-00.txt (work in progress), 619 April 2005. 621 [BOOT-PS] Patel et. al., A., "Problem Statement for bootstrapping 622 Mobile IPv6.", draft-ietf-mip6-bootstrap-ps-03.txt (work 623 in progress), July 2005. 625 [MIP6-IKEv2] 626 Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the 627 revised IPsec.", draft-ietf-mip6-ikev2-ipsec-03.txt (work 628 in progress), September 2005. 630 [RFC1035] Mockapetris, P., "Domain names - implementation and 631 specification", STD 13, RFC 1035, November 1987. 633 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 634 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 635 RFC 2136, April 1997. 637 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 638 RFC 3753, June 2004. 640 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 641 in IPv6", RFC 3775, June 2004. 643 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 644 Protect Mobile IPv6 Signaling Between Mobile Nodes and 645 Home Agents", RFC 3776, June 2004. 647 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 648 Rose, "DNS Security Introduction and Requirements", 649 RFC 4033, March 2005. 651 Authors' Addresses 653 Kuntal Chowdhury 654 Starent Networks 655 30 International Place 656 Tewksbury, MA 01876 657 US 659 Phone: +1 214-550-1416 660 Email: kchowdhury@starentnetworks.com 662 Avi Lior 663 Bridgewater Systems 664 303 Terry Fox Drive, Suite 100 665 Ottawa, Ontario 666 Canada K2K 3J1 668 Phone: +1 613-591-6655 669 Email: avi@bridgewatersystems.com 671 Hannes Tschofenig 672 Siemens 673 Otto-Hahn-Ring 6 674 Munich, Bavaria 81739 675 Germany 677 Email: Hannes.Tschofenig@siemens.com 679 Intellectual Property Statement 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Disclaimer of Validity 705 This document and the information contained herein are provided on an 706 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 707 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 708 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 709 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 710 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 711 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 713 Copyright Statement 715 Copyright (C) The Internet Society (2005). This document is subject 716 to the rights, licenses and restrictions contained in BCP 78, and 717 except as set forth therein, the authors retain all their rights. 719 Acknowledgment 721 Funding for the RFC Editor function is currently provided by the 722 Internet Society.