idnits 2.17.1 draft-ietf-mip6-bootstrapping-integrated-dhc-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 59 lines 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 636 has weird spacing: '...iaretta gera...' == Line 638 has weird spacing: '...j Patil bas...' == Line 652 has weird spacing: '...rapalli vijay...' == Line 654 has weird spacing: '...owdhury kcho...' == Line 656 has weird spacing: '...urnelle juli...' == (1 more instance...) == 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 16, 2005) is 6738 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: 'RFC1035' is defined on line 677, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. 'BOOT-PS') == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-01 -- Possible downref: Normative reference to a draft: ref. 'HAOPT' == Outdated reference: A later version (-02) exists of draft-chowdhury-mip6-radius-00 -- Possible downref: Normative reference to a draft: ref. 'MIP6-RADIUS' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-00 Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury, Editor 3 Internet-Draft Starent Networks 4 Expires: April 19, 2006 A. Yegin 5 Samsung 6 October 16, 2005 8 MIP6-bootstrapping via DHCPv6 for the Integrated Scenario 9 draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Mobile IPv6 bootstrapping problem statement describes two main 43 scenarios. In the first scenario (i.e. the split scenario), the 44 mobile node's mobility service is authorized by a different service 45 authorizer than the basic network access authorizer. In the second 46 scenario (i.e. the integrated scenario), the mobile node's mobility 47 service is authorized by the same service authorizer as the basic 48 network access service authorizer. This document defines a method 49 for home agent information discovery based on DHCPv6 for the 50 integrated scenario. 52 Table of Contents 54 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Logical Diagram of the Integrated Scenario . . . . . . . . 5 58 3.2 Bootstrapping Message Sequence, Success Case . . . . . . . 6 59 3.2.1 Home Agent allocation in the MSP . . . . . . . . . . . 6 60 3.2.2 Home Agent allocation in the ASP . . . . . . . . . . . 8 61 3.3 Bootstrapping Message Sequence: Fallback case . . . . . . 10 62 3.4 HoA and IKEv2 SA Bootstrapping in the Integrated 63 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.5 DHCPv6 options . . . . . . . . . . . . . . . . . . . . . . 10 65 3.5.1 DHC Relay Agent Option to carry Mobile IPv6 66 parameters . . . . . . . . . . . . . . . . . . . . . . 11 67 3.5.2 MIP6 home agent sub-option . . . . . . . . . . . . . . 11 68 3.6 Mobile Node Behavior . . . . . . . . . . . . . . . . . . . 12 69 3.7 NAS, DHCP Relay Agent Behavior . . . . . . . . . . . . . . 13 70 3.8 DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 14 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 77 8.2 Informative References . . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 79 Intellectual Property and Copyright Statements . . . . . . . . 22 81 1. Introduction and Scope 83 The Mobile IPv6 protocol [RFC3775] requires the mobile node to have 84 knowledge of its Home Address, the home agent address and the 85 cryptographic materials for establishing an IPsec security 86 association with the home agent prior to performing home 87 registration. The mechanism via which the mobile node obtains these 88 information is called Mobile IPv6 bootstrapping. In order to allow a 89 flexible deployment model for Mobile IPv6, it is desirable to define 90 a bootstrapping mechanism for the mobile node to acquire these 91 parameters dynamically. The [BOOT-PS] describes the problem 92 statement for Mobile IPv6 bootstrapping. It also defines two 93 bootstrapping scenarios based on the relationship between the entity 94 that authenticates and authorizes the mobile node for network access 95 (i.e., the Access Service Authorizer) and the entity that 96 authenticates and authorizes the mobile node for mobility service 97 (i.e., the Mobility Service Authorizer). The scenario in which the 98 Access Service Authorizer is not the Mobility Service Authorizer is 99 called the "Split" scenario. The bootstrapping solution for split 100 scenario is defined in [BOOT-SPLIT]. The scenario in which the 101 Access Service Authorizer is also the Mobility Service Authorizer is 102 called the "Integrated" scenario. This document defines a 103 bootstrapping solution using DHCPv6 for the Integrated scenario. 105 [BOOT-SPLIT] identifies four different components of the 106 bootstrapping problem: home agent address discovery, HoA assignment, 107 IPsec Security Association setup and Authentication and Authorization 108 with the MSA. This document defines a mechanism for home agent 109 address discovery. For the rest of components, please refer to 110 [BOOT-SPLIT]. 112 In the integrated scenario, the bootstrapping of the home agent 113 information can be performed via DHCPv6. DHCPv6 is designed for 114 configuration management and it is being deployed by operators to 115 handle their configuration management needs in their networks. 117 2. Terminology 119 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 121 this document are to be interpreted as described in [RFC2119]. 123 General mobility terminology can be found in [RFC3753]. The 124 following additional terms, as defined in [BOOT-PS], are used in this 125 document: 127 Access Service Authorizer (ASA): 128 A network operator that authenticates a mobile node and 129 establishes the mobile node's authorization to receive Internet 130 service. 132 Access Service Provider (ASP): 133 A network operator that provides direct IP packet forwarding 134 to and from the mobile node. 136 Mobility Service Authorizer (MSA): 137 A service provider that authorizes Mobile IPv6 service. 139 Mobility Service Provider (MSP): 140 A service provider that provides Mobile IPv6 service. In order 141 to obtain such service, the mobile node must be authenticated 142 and authorized to obtain the Mobile IPv6 service. 144 Split scenario: 145 A scenario where the mobility service and the network access 146 service are authorized by different entities. 148 Integrated Scenario: 149 A scenario where the mobility service and the network access 150 service are authorized by the same entity. 152 3. Solution Overview 154 3.1 Logical Diagram of the Integrated Scenario 156 In the integrated scenario the mobile node may use the security 157 credentials for network access to bootstrap Mobile IPv6. As such, it 158 is assumed that the access service authorizer is mobility service 159 aware. This allows for Mobile IPv6 bootstrapping at the time of 160 access authentication and authorization. Also, the mechanism defined 161 in this document requires the NAS to support Mobile IPv6 specific AAA 162 attributes and a collocated DHCP relay agent. 164 The following diagram shows the network elements and layout in the 165 integrated scenario: 167 | 168 ASP(/MSP) | ASA/MSA(/MSP) 169 | 170 | 171 +-------+ | +-------+ 172 | | | | | 173 |AAAV |-----------|--------|AAAH | 174 | | | | | 175 | | | | | 176 +-------+ | +-------+ 177 | | 178 | | 179 | | 180 | | 181 | | 182 | | 183 | | 184 +-----+ +------+ | 185 +----+ | | |DHCP | | 186 | MN |------| NAS/|----|Server| | 187 +----+ |Relay| | | | 188 +-----+ +------+ | 189 | 190 | 191 +--------+ | +--------+ 192 | HA | | | HA | 193 | in ASP | | |in MSP | 194 +--------+ | +--------+ 196 Figure 1. Integrated Scenario, Network Diagram with DHCP 198 Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA 199 proxy in the visited network and a AAA server in the home network. 200 The user's home network authorizes the mobile node for network access 201 and also for mobility services. Note that a home agent for usage 202 with the mobile node might be selected in the access service 203 provider's network or alternatively in the mobility service 204 provider's network. 206 The mobile node interacts with the DHCP Server via the Relay Agent 207 (ideally collocated with the NAS) after the network access 208 authentication as part of the mobile node configuration procedure. 210 3.2 Bootstrapping Message Sequence, Success Case 212 In the success case, the mobile node is able to acquire the home 213 agent address via a DHCPv6 query. The message flows for home agent 214 allocation in the ASP and the MSP are illustrated below. Since, in 215 the integrated scenario, the ASA and the MSA are the same, it can be 216 safely assumed that the AAAH used for network access authentication 217 (ASA) has access to the same database as the AAAH used for the 218 mobility service authentication (MSA). Hence, the same AAAH can 219 authorize the mobile node for network access and mobility service at 220 the same time. 222 3.2.1 Home Agent allocation in the MSP 224 This section describes a scenario where the home agent is allocated 225 in the mobile node's home MSP network. in order to provide the mobile 226 node with information about the assigned home agent the AAAH conveys 227 the assigned home agent's information to the NAS via AAA protocol. 229 | 230 --------------ASP------>|<--ASA+MSA-- 231 | 232 +----+ +------+ +-------+ +-----+ 233 | | | | | | | | 234 | MN/| |NAS/ | | DHCP | |AAAH | 235 |User| |DHCP | | Server| | | 236 | | |relay | | Server| | | 237 +----+ +------+ +-------+ +-----+ 238 | | | | 239 | 1 | 1 | | 240 |<------------->|<---------------------->| 241 | | | | 242 | | | | 243 | 2 | | | 244 |-------------->| | | 245 | | | | 246 | | 3 | | 247 | |------------>| | 248 | | | | 249 | | 4 | | 250 | |<------------| | 251 | | | | 252 | 5 | | | 253 |<--------------| | | 254 | | | | 256 Figure 2. The home agent allocation in the home MSP 258 Figure 2 shows the message sequence for home agent allocation in the 259 home MSP. 261 (1) The mobile node executes the network access authentication 262 procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the 263 NAS. The NAS is in the ASP and it interacts with the AAAH, which is 264 in the ASA/MSA, to authenticate the mobile node. In the process of 265 authorizing the mobile node the AAAH verifies in the AAA profile that 266 the mobile node is allowed to use Mobile IPv6 service. The AAAH 267 assigns a home agent in the home MSP and returns this information to 268 the NAS. 270 (2) The mobile node sends a DHCPv6 Information Request message 271 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 272 In this message the mobile node (DHCP client) SHALL include the 273 Option Code for Home Network Identifier Option [HAOPT] in the 274 OPTION_ORO, Home Network Identifier Option with id-type set to 1 and 275 the Home Network Identifier field set to the network realm of the 276 home MSP [HAOPT]. The mobile node SHALL also include the 277 OPTION_CLIENTID to identify itself to the DHCP server. 279 (3) The Relay Agent intercepts the Information Request from the 280 mobile node and forwards it to the DHCP server. The Relay Agent also 281 includes the received home agent information from the AAAH in the 282 OPTION_MIP6-RELAY-Option (see section 3.5). 284 (4) The DHCP server identifies the client by looking at the DUID for 285 the client in the OPTION_CLIENTID. The DHCP server also determines 286 that the mobile node is requesting home agent information in the MSP 287 by looking at the Home Network Identifier Option (id-type 1). The 288 DHCP server determines that the home agent is allocated by the AAAH 289 by looking at the MIP6 home agent sub-option in the OPTION_MIP6- 290 RELAY-Option. The DHCP server extracts the allocated home agent 291 information from the OPTION_MIP6-RELAY-Option and includes it in the 292 Home Network Information Option [HAOPT] in the Reply Message. 294 (5) The Relay Agent relays the Reply Message from the DHCP server to 295 the mobile node. At this point, the mobile node has the home agent 296 information that it requested. 298 3.2.2 Home Agent allocation in the ASP 300 This section describes a scenario where the mobile node requests for 301 home agent allocation in the ASP by setting the id-type field to zero 302 in the Home Network Identifier Option in the DHCPv6 request message. 303 In this scenario, the ASP becomes the MSP for the duration of the 304 network access authentication session. 306 | 307 --------------ASP-------->|<--ASA+MSA-- 308 | 309 +----+ +-------+ +-------+ +------+ 310 | | | | | | | | 311 | MN/| | NAS/ | | DHCP | |AAAH | 312 |User| | DHCP | | Server| | | 313 | | | relay | | Server| | | 314 +----+ +-------+ +-------+ +------+ 315 | | | | 316 | 1 | 1 | | 317 |<------------->|<------------------------>| 318 | | | | 319 | | | | 320 | 2 | | | 321 |-------------->| | | 322 | | | | 323 | | 3 | | 324 | |------------->| | 325 | | | | 326 | | 4 | | 327 | |<-------------| | 328 | | | | 329 | 5 | | | 330 |<--------------| | | 331 | | | | 333 Figure 3. The home agent allocation in the ASP 335 Figure 3 shows the message sequence for home agent allocation in the 336 ASP. 338 (1) The mobile node executes the network access authentication 339 procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the 340 NAS. The NAS is in the ASP and it interacts with the AAAH, which is 341 in the ASA/MSA, to authenticate the mobile node. In the process of 342 authorizing the mobile node the AAAH verifies in the AAA profile that 343 the mobile node is allowed to use Mobile IPv6 services. The AAAH 344 assigns a home agent in the home MSP and returns this information to 345 the NAS. Note that the AAAH is not aware of the fact that the mobile 346 node will rather request for a home agent allocation in the ASP. 347 Therefore the assigned home agent may not be used by the mobile node. 348 This leaves the location of the mobility anchor point decision to the 349 mobile node. 351 (2) The mobile node sends a DHCPv6 Information Request message 352 [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. 354 In this message the mobile node (DHCP client) SHALL include the 355 Option Code for Home Network Identifier Option [HAOPT] in the 356 OPTION_ORO, Home Network Identifier Option with id-type set to 0. 357 The mobile node SHALL also include the OPTION_CLIENTID to identify 358 itself to the DHCP server. 360 (3) The Relay Agent intercepts the Information Request from the 361 mobile node and forwards it to the DHCP server. The Relay Agent 362 (which is the NAS) also includes the received AAA AVP from the AAAH 363 in the OPTION_MIP6-RELAY-Option. 365 (4) The DHCP server identifies the client by looking at the DUID for 366 the client in the OPTION_CLIENTID. The DHCP server also determines 367 that the mobile node is requesting home agent information in the ASP 368 by looking at the Home Network Identifier Option (id-type 0). If 369 configured to do so, the DHCP server allocates an home agent from its 370 configured list of home agents and includes it in the Home Network 371 Information Option [HAOPT] in the Reply Message. Note that in this 372 case, the DHCP server does not use the received information in the 373 OPTION_MIP6-RELAY-Option. 375 (5) The Relay Agent relays the Reply Message from the DHCP server to 376 the mobile node. At this point, the mobile node has the home agent 377 information that it requested. 379 3.3 Bootstrapping Message Sequence: Fallback case 381 In the fallback case, the mobile node is not able to acquire the home 382 agent information via DHCPv6. The mobile node performs DNS queries 383 to discover the home agent address as defined in [BOOT-SPLIT]. To 384 perform DNS based home agent discovery, the mobile node needs to know 385 the DNS server address. How the mobile node knows the DNS server 386 address is outside the scope of this document. 388 3.4 HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 390 In the integrated scenario, the HoA, IPsec Security Associations 391 setup, and Authentication and Authorization with the MSA are 392 bootstrapped via the same mechanism as described in the bootstrapping 393 solution for split scenario [BOOT-SPLIT]. 395 3.5 DHCPv6 options 397 The following DHCP options are used in this solution to carry the 398 home agent information from the DHCP relay agent to the DHCP serever: 400 3.5.1 DHC Relay Agent Option to carry Mobile IPv6 parameters 402 This option carries the RADIUS or Diameter attributes that are 403 received at the NAS from the AAAH. The DHCP relay agent sends this 404 option to the DHCP server in the Relay-Forward message. 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | OPTION_MIP6-RELAY-Option | option-len | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 . sub-options . 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 option-code OPTION_MIP6-RELAY-Option (TBD-1 by IANA). 415 option-len Length of OPTION_MIP6-RELAY-Option. 417 sub-options A series of sub-options carrying MIP6 418 bootstrap information. The values are: 419 1 - MIP6 home agent. 420 other values are reserved. 422 3.5.2 MIP6 home agent sub-option 424 This sub-option carries the assigned home agent information to the 425 DHCP server. 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | sub-option=1 | sub-option-len | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 . . 432 . assigned-MIP6-HA . 433 . . 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 sub-option-code MIP6 home agent (1). 438 option-len Length of assigned home agent field. 440 assigned-MIP6-HA IPv6 address or FQDN of the 441 assigned home agent. 443 The following DHCP options are used in this solution to carry the 444 home agent information and home agent bootstrap request information 445 between the mobile node and the DHCP server: 447 Home Network Information Option [HAOPT]. 449 Home Network Identifier Option [HAOPT]. 451 The following DHCP options are requried in this solution for normal 452 DHCP operation: 454 Option Request Option [RFC3315]. 456 Client Identifier Option [RFC3315]. 458 Relay Message Option [RFC3315]. 460 Interface-Id Option [RFC3315]. 462 3.6 Mobile Node Behavior 464 If configured to do so, the mobile node MUST first try to perform 465 home agent discovery using DHCPv6. In order to acquire the home 466 agent information, the mobile node SHALL send an Information Request 467 to the All_DHCP_Relay_Agents_and_Servers multicast address. In this 468 message the mobile node (DHCP client) SHALL include the Option Code 469 for Home Network Identifier Option [HAOPT] in the OPTION_ORO, Home 470 Network Identifier Option with id-type set to either 1 or 0. The 471 mobile node SHALL also include the OPTION_CLIENTID [RFC3315] to 472 identify itself to the DHCP server. 474 Upon receiving the Reply message from the DHCP server, the mobile 475 node SHALL check for the requested configuration options. Here are 476 the possible scenarios: 478 Home Network info 479 Option mobile node Action 480 ________________________________________________________ 482 hninfo-type 0,1,2 Use home agent address 484 hninfo-type 0,1 Use home agent address 486 hninfo-type 0 Use home agent address 488 hninfo-type 1,2 Use home agent address 490 hninfo-type 1 Use home agent address 492 hninfo-type 0,2 Use home agent address 494 hninfo-type 2 Use HA-FQDN, ref 495 [BOOT-SPLIT] 496 for DNS based 497 home agent discovery. 499 No Ref [BOOT-SPLIT] 500 for DNS based home 501 agent discovery. 503 The mobile node MAY request for local home agent assignment by 504 including the Home Network Identifier Option [HAOPT] in the 505 Information Request message and by setting the id-type to 0. 507 If the mobile node wants to discover an home agent in a particular 508 MSP, the mobile node SHALL request for home agent assignment in that 509 MSP by including the Home Network Identifier Option [HAOPT] in the 510 Information Request message. In this option the mobile node SHALL 511 set the id-type to 1 and the Home Network Identifier field to the 512 network realm of the MSP. 514 3.7 NAS, DHCP Relay Agent Behavior 516 The NAS and the DHCP relay agent are assumed to be collocated in this 517 solution. The NAS communicates with the mobile node during the 518 network access authentication and interacts with the AAAH (via the 519 AAAV) using either Diameter NASREQ [RFC4005] or RADIUS [MIP6-RADIUS] 520 [Editor's note: The Diameter AVPs need to be defined]. 522 Upon receiving the MIP6 related RADIUS or Diameter attributes 523 returned by the AAAH, the NAS passes the information to the 524 collocated DHCP Relay Agent. 526 Upon receiving the Information Request from the mobile node, the DHCP 527 relay agent MUST forward the message to the DHCP server as per 528 [RFC3315]. The relay agent SHALL use the OPTION_CLIENTID to identify 529 the mobile node (user). This is required to check whether there are 530 some additional information for the user that need to be appended 531 while relaying the information request message to the DHCP server. 532 If the relay agent determines that the NAS has passed home agent 533 information for this mobile node, the relay agent MUST include the 534 received home agent information in the OPTION_MIP6-RELAY-Option and 535 include this option in the Relay-Forward message. The relay agent 536 MAY include the Interface-Id Option [RFC3315] in the Relay-Forward 537 message. 539 Upon receiving the Reply message from the DHCPv6 server, the relay 540 agent SHALL follow the guidelines defined in [RFC3315] to forward the 541 message to the mobile node. 543 3.8 DHCP Server Behavior 545 The DHCP server MUST follow the following logic to process 546 Information Request from the mobile node: 548 Information Request message includes: 550 a. OPTION_MIP6-RELAY-Option, OPTION_ORO and Home Network Identifier 551 Option with id-type 1 (home agent assignment request in the home 552 MSP), Interface-Id Option, Client Identifier Option. 554 The DHCP server MUST extract the assigned home agent information from 555 the OPTION_MIP6-RELAY-Option and include it in the Home Network 556 Information Option of the Reply message. 558 b. OPTION_MIP6-RELAY-Option, OPTION_ORO and Home Network Identifier 559 Option with id-type 0 (home agent assignment request in the ASP), 560 Interface-Id Option, Client Identifier Option. 562 If the DHCP server is configured with information about a local home 563 agent, select a home agent address or FQDN for the home agent from 564 locally provisioned configuration and include it in the Home Network 565 Information Option of the Reply message. 567 If the DHCP server is not configured with information about a local 568 home agent, but it received the assigned home agent info in the 569 OPTION_MIP6-RELAY-Option, then it MUST extract the assigned home 570 agent info from this option and MUST include it in the Home Network 571 Information Option of the Reply message. 573 If the DHCP server is not configured with information about a local 574 home agent, and no OPTION_MIP6-RELAY-Option is received, then it MAY 575 return any other option in the Reply message that is requested. In 576 this case no home agent is assigned to the mobile node. 578 In all cases, in the Reply message the DHCP server MUST return the 579 Interface-Id Option as received in the Information Request. The DHCP 580 server SHOULD use the Client Identifier Option to identify the mobile 581 node. 583 4. Security Considerations 585 The transport of the assigned home agent information via the AAA 586 infrastructure (i.e., from the AAA server to the AAA client) to the 587 NAS is subject to the standard RADIUS and Diameter security 588 considerations. No new security considerations are imposed by the 589 usage of this document. The security mechanisms provided by 590 [RFC2865] and [RFC3588] are applicable and provide adequate security 591 for this purpose. 593 The communication between the NAS/DHCP relay agent to the DHCP server 594 must be authenticated, integrity and replay protected. Deployments 595 MAY either rely on lower-layer security, (i.e., physical or link 596 layer security), or rely on security mechanisms specifically defined 597 for DHCPv6, such as [RELAY-IPSEC] or [RFC4030]. 599 The communication between the DHCP client and the DHCP server for the 600 exchange of home agent information is security sensitive and requires 601 authentication, integrity and replay protection. Either lower-layer 602 security (such as link layer security established as part of the 603 network access authentication protocol run) or DHCP security 604 [RFC3118] can be used. The latter approach is only applicable in 605 non-roaming environments due to the limited applicability of the DHCP 606 security mechanisms. An adversary that is able to modify home agent 607 information can force the mobile node to use a different home agent 608 than intended by the MSA. However, this type of attack can be 609 detected by the security mechanism between the mobile node and the 610 home agent. 612 Overall, the home agent information carried by the AAA protocols and 613 DHCP does not impose any new security concerns for the transport 614 protocols. 616 5. IANA Considerations 618 The following DHCP option code MUST be assigned by IANA: 620 option-code for OPTION_MIP6-RELAY-Option: TBD-1. 622 6. Acknowledgements 624 TBD. 626 7. Contributors 628 This contribution is a joint effort of the bootstrapping solution 629 design team of the MIP6 WG. The contributors include Gerardo 630 Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, 631 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 632 Chowdhury, Julien Bournelle, and Hannes Tschofenig. 634 The design team members can be reached at: 636 Gerardo Giaretta gerardo.giaretta@tilab.com 638 Basavaraj Patil basavaraj.patil@nokia.com 640 Alpesh Patel alpesh@cisco.com 642 Jari Arkko jari.arkko@kolumbus.fi 644 James Kempf kempf@docomolabs-usa.com 646 Gopal Dommety gdommety@cisco.com 648 Alper Yegin alper.yegin@samsung.com 650 Junghoon Jee jhjee@etri.re.kr 652 Vijay Devarapalli vijayd@iprg.nokia.com 654 Kuntal Chowdhury kchowdhury@starentnetworks.com 656 Julien Bournelle julien.bournelle@int-evry.fr 658 Hannes Tschofenig hannes.tschofenig@siemens.com 660 8. References 662 8.1 Normative References 664 [BOOT-PS] Patel et. al., A., "Problem Statement for bootstrapping 665 Mobile IPv6.", draft-ietf-mip6-bootstrap-ps-03.txt (work 666 in progress), July 2005. 668 [HAOPT] Hee Jang et. al., A., "DHCP Option for Home Agent 669 Discovery in MIPv6.", draft-jang-dhc-haopt-01.txt (work in 670 progress), April 2005. 672 [MIP6-RADIUS] 673 Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.", 674 draft-chowdhury-mip6-radius-00.txt (work in progress), 675 October 2005. 677 [RFC1035] Mockapetris, P., "Domain names - implementation and 678 specification", STD 13, RFC 1035, November 1987. 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 684 "Remote Authentication Dial In User Service (RADIUS)", 685 RFC 2865, June 2000. 687 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 688 Messages", RFC 3118, June 2001. 690 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 691 and M. Carney, "Dynamic Host Configuration Protocol for 692 IPv6 (DHCPv6)", RFC 3315, July 2003. 694 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 695 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 697 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 698 RFC 3753, June 2004. 700 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 701 in IPv6", RFC 3775, June 2004. 703 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 704 "Diameter Network Access Server Application", RFC 4005, 705 August 2005. 707 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 708 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 709 Option", RFC 4030, March 2005. 711 8.2 Informative References 713 [BOOT-SPLIT] 714 Giaretta et. al., A., "Mobile IPv6 bootstrapping in split 715 scenario.", draft-ietf-mip6-bootstrapping-split-00.txt 716 (work in progress), June 2005. 718 [RELAY-IPSEC] 719 Droms, R., "Authentication of DHCP Relay Agent Options 720 Using IPsec.", draft-ietf-dhc-relay-agent-ipsec-02.txt 721 (work in progress), May 2005. 723 Authors' Addresses 725 Kuntal Chowdhury 726 Starent Networks 727 30 International Place 728 Tewksbury, MA 01876 729 US 731 Phone: +1 214-550-1416 732 Email: kchowdhury@starentnetworks.com 734 Alper Yegin 735 Samsung 736 Email: alper.yegin@yegin.org 738 Intellectual Property Statement 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the procedures with respect to rights in RFC documents can be 747 found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at 760 ietf-ipr@ietf.org. 762 Disclaimer of Validity 764 This document and the information contained herein are provided on an 765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 767 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 768 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 769 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 772 Copyright Statement 774 Copyright (C) The Internet Society (2005). This document is subject 775 to the rights, licenses and restrictions contained in BCP 78, and 776 except as set forth therein, the authors retain all their rights. 778 Acknowledgment 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.