idnits 2.17.1 draft-ietf-mip6-hiopt-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 13, 2007) is 6161 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) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-02 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Hee Jin Jang 3 Internet-Draft Alper Yegin 4 Intended status: Standards Track SAMSUNG 5 Expires: December 15, 2007 Kuntal Chowdhury 6 Starent Networks 7 JinHyeock Choi 8 SAMSUNG 9 June 13, 2007 11 DHCP Option for Home Information Discovery in MIPv6 12 draft-ietf-mip6-hiopt-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 15, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This draft defines a DHCP-based scheme to enable dynamic discovery of 46 Mobile IPv6 home network information. New DHCP options are defined 47 which allow a mobile node to request the home agent IP address, FQDN, 48 or home subnet prefix and obtain it via the DHCP response. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. DHCP options for HA Dynamic Discovery . . . . . . . . . . . . 5 55 3.1. Home Network Identifier Option . . . . . . . . . . . . . . 5 56 3.2. MIP6 Relay Agent Option . . . . . . . . . . . . . . . . . 7 57 3.2.1. MIP6 Relay Agent Sub-option . . . . . . . . . . . . . 7 58 3.3. Home Network Information Option . . . . . . . . . . . . . 9 59 3.3.1. Home Network Information Sub-option . . . . . . . . . 10 60 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 4.1. Mobile Node Behavior . . . . . . . . . . . . . . . . . . . 12 62 4.2. NAS/DHCP Relay Agent Behavior . . . . . . . . . . . . . . 13 63 4.3. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 14 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 71 Intellectual Property and Copyright Statements . . . . . . . . . . 21 73 1. Introduction 75 Before a mobile node can engage in Mobile IPv6 signaling with a home 76 agent, it should either know the IP address of the home agent via 77 pre-configuration, or dynamically discover it. Mobile IPv6 78 specification [RFC3775] describes how home agents can be dynamically 79 discovered by mobile nodes that know the home subnet prefix. This 80 scheme does not work when prefix information is not already available 81 to the mobile node. This problem can be solved by delivering one or 82 more home subnet prefix information to the mobile node by means of 83 DHCP. Subsequently, the mobile node can engage in dynamic home agent 84 discovery using the prefix information. In addition to delivering 85 the prefix information, DHCP can also be used to provide the IP 86 addresses or FQDNs of the home agents that are available to the 87 mobile node. The solution involves defining new DHCP options to 88 carry home subnet prefix, home agent IP address and FQDN information. 90 As part of configuring the initial TCP/IP parameters, a mobile node 91 can obtain home network information for the subnet it is directly 92 attached to, other subnets in the visited domain, or a subnet from 93 its home domain. A mobile node can indicate its home network 94 identity when roaming to the visited network in order to obtain the 95 MIP6 bootstrap parameters from the home network. As an example, the 96 visited network may determine the home network of the mobile node 97 based on the realm portion of the NAI (Network Access Identifier) 98 used in access authentication. 100 The mobile node may or may not be connected to the "home" subnet when 101 it attempts to learn Mobile IPv6 home network information. This 102 allows operators to centrally deploy home agents while being able to 103 bootstrap mobile nodes that are already roaming. This scenario also 104 occurs when HMIPv6 [RFC4140] is used, where the mobile node is 105 required to discover the MAP (a special home agent) that is located 106 multiple hops away from the mobile node's attachment point. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 General mobility terminology can be found in [RFC3753]. The 115 following additional terms, as defined in [RFC4640], are used in this 116 document: 118 Access Service Provider (ASP): A network operator that provides 119 direct IP packet forwarding to and from the mobile node. 121 Mobility Service Provider (MSP): A service provider that provides 122 Mobile IPv6 service. In order to obtain such service, the mobile 123 node must be authenticated and authorized to obtain the Mobile IPv6 124 service. 126 Mobility Service Authorizer (MSA): A service provider that authorizes 127 Mobile IPv6 service. 129 3. DHCP options for HA Dynamic Discovery 131 This section introduces new DHCP options used for dynamic home agent, 132 FQDN, or home prefix information discovery in Mobile IPv6. The 133 drafts [I-D.ietf-mip6-radius] and 134 [I-D.ietf-mip6-bootstrapping-integrated-dhc] describe the complete 135 procedure for home agent assignment among the mobile node, NAS, DHCP, 136 and AAA entities for bootstrapping procedure in the integrated 137 scenario. 139 3.1. Home Network Identifier Option 141 This option is used to carry the identifier of the target home 142 network. The mobile node MUST include this option along with its 143 Option Request option in its request. 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | OPTION_MIP6-HNID | option-len | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | id-type | reserved | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 151 . . 152 . Home Network Identifier . 153 . . 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 option-code 158 OPTION_MIP6-HNID (TBD) 160 option-len 162 Total length of the option in octets 164 id-type 166 The type of Home Network Identifier: 168 0 Visited domain (local ASP) 170 1 Target MSP 172 2 No preference 174 reserved 176 An 8-bit field reserved for future use. The value MUST 177 be initialized to 0 by the sender and MUST be ignored by 178 the receiver. 180 Home Network Identifier 182 The identifier to specify the requested home network of 183 the mobile node. This field MUST be set in the form of 184 user's NAI [RFC4282] when the id-type is 1. 186 The id-type 0 indicates the mobile node is interested in learning the 187 home network information that pertains to the currently visited 188 network. This type can be used to discover local home agents in the 189 local ASP. In this case, the Home Network Identifier field SHOULD be 190 set to 0. 192 The id-type 1 indicates the mobile node is interested in learning the 193 home network information that pertains to the given realm. This type 194 can be used to discover home agents that are hosted by a user's home 195 domain (MSA domain, as indicated by his/her NAI-based username 196 --user@HomeRealm) or by any target domain. The requested domain is 197 specified in the Home Network Identifier field and can be a mobile 198 node's home MSP or any MSP which has trust roaming relationship with 199 the mobile node's MSA. 201 If the mobile node has no preference, the id-type is set to 2 and the 202 Home Network Identifier SHOULD be initialized to 0. In this case, 203 the assignment of the home network information is within the server's 204 own discretion. For the detailed processing, refer to section 4. 206 3.2. MIP6 Relay Agent Option 208 This option carries the RADIUS or Diameter attributes that are 209 received at the NAS from the AAAH. The DHCP relay agent sends this 210 option to the DHCP server in the Relay-Forward message. 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | OPTION_MIP6-RELAY | option-len | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 . sub-options . 217 . . 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 option-code 222 OPTION_MIP6-RELAY (TBD). 224 option-len 226 Total length of the option in octets 228 sub-options 229 A series of sub-options carrying MIP6 bootstrap 230 information. 232 3.2.1. MIP6 Relay Agent Sub-option 234 This sub-option carries the assigned home network information to the 235 DHCP server. 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | sub-opt-code | sub-opt-len | reserved | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 241 . . 242 . Home Network Information . 243 . . 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 sub-opt-code 248 The sub-option identifies the type of the following 249 Home Network Information field. Possible values are: 251 0 Home subnet prefix 253 1 Complete IPv6 address of the home agent 255 2 FQDN of the home agent 257 sub-opt-len 259 An 8-bit unsigned integer. Total length of the following 260 Home Network Information field. 262 reserved 264 An 8-bit field reserved for future use. The value MUST 265 be initialized to 0 by the sender and MUST be ignored by 266 the receiver. 268 Home Network Information 270 A home subnet prefix, home agent IP address or home agent 271 FQDN to be provided to a mobile node according to the 272 sub-opt-code. 274 When the sub-opt-code is set to 0, the data field MUST contain the 275 8-bit prefix length information followed by the 128-bit IPv6 address 276 beginning with the available network prefix. 278 When the sub-opt-code is set to 1, the data field MUST contain the 279 128-bit IPv6 address of the home agent. 281 When the sub-opt-code is set to 2, the data field MUST contain the 282 FQDN as described in [RFC1035]. 284 Multiple sub-options may exist in a MIP6 Relay Agent option to carry 285 more than one home information. 287 3.3. Home Network Information Option 289 This option is used to carry home network information to a mobile 290 node in the form of one or more of home subnet prefix(es), home agent 291 address(es) and home agent FQDN(s). 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | OPTION_MIP6-HNINF | option-len | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | id-type | reserved | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 299 . sub-options . 300 . . 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 option-code 305 OPTION_MIP6-HNINF (TBD). 307 option-len 309 Total length of the option in octets 311 id-type 313 The type of Home Network Identifier: 315 0 Visited domain (local ASP) 317 1 Home domain 319 2 No preference 321 reserved 323 An 8-bit field reserved for future use. The value MUST 324 be initialized to 0 by the sender and MUST be ignored by 325 the receiver. 327 sub-options 329 A series of sub-options carrying MIP6 bootstrap 330 information. 332 3.3.1. Home Network Information Sub-option 334 This sub-option carries the assigned home network information to the 335 DHCP client. 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | sub-opt-code | sub-opt-len |V| reserved | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 341 . . 342 . Home Network Information . 343 . . 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 sub-opt-code 348 The type of the following Home Network Information field. 349 Possible values are: 351 0 Home subnet prefix 353 1 Complete IPv6 address of the home agent 355 2 FQDN of the home agent 357 sub-opt-len 359 An 8-bit unsigned integer. Total length of the following 360 Home Network Information field. 362 V flag 364 This flag specifies the location of home network where 365 the home agent is assigned. If it is set to 1, it means 366 that the following Home Network Information is allocated 367 from the visited network. 369 reserved 371 A 7-bit field reserved for future use. The value MUST 372 be initialized to 0 by the sender and MUST be ignored by 373 the receiver. 375 Home Network Information 377 A home subnet prefix, home agent IP address or home agent 378 FQDN to be provided to a mobile node according to the 379 sub-opt-code. 381 The sub-opt-code, sub-opt-len and Home Network Information fields are 382 set in the same manner as those of a MIP6 Relay Agent sub-option. 384 Multiple sub-options may exist in a Home Network Information option 385 to carry more than one home information. 387 The detailed processing for each id-type is described in section 4. 389 4. Option Usage 391 The requesting and sending of the proposed DHCP options follow the 392 rules for DHCP options in [RFC3315]. The following DHCP options 393 [RFC3315] are also required in the solution for normal DHCP 394 operation: 396 - Option Request option 398 - Client Identifier option 400 - Relay Message option 402 - Interface-Id option 404 4.1. Mobile Node Behavior 406 In order to acquire the home network information, the mobile node 407 SHALL send an Information Request to the 408 All_DHCP_Relay_Agents_and_Servers multicast address. In this message 409 the mobile node (DHCP client) SHALL include the Option Code for Home 410 Network Identifier option in the OPTION_ORO. The mobile node SHALL 411 also include the OPTION_CLIENTID [RFC3315] to identify itself to the 412 DHCP server. 414 During the process of requesting the bootstrapping information, the 415 mobile node MUST clarify the preference about the requested home 416 network with the id-type in the Home Network Identifier option. Even 417 if the mobile node does not care about the location of the home 418 network where the home agent to be assigned, it MUST clarify the fact 419 by setting the id-type to 2. In this case the Home Network 420 Identifier SHOULD be set to 0. 422 The mobile node can request more than one home information by using 423 multiple Home Network Identifier options in the request. For 424 instance, if the mobile node wants to retrieve home network 425 information from both the visited network (ASP) and the home network 426 with a single transaction, it can request the information by using 427 two Home Network Identifier options with the id-type 0 and the id- 428 type 1. It can also request the home information for more than one 429 target MSPs at the same time by including multiple Home Network 430 Identifier options with id-type 1. 432 When the mobile node receives a Reply message from the DHCP server 433 and gets more than one home agent address(es), it MUST have a 434 selection mechanism to determine which one to use for establishing a 435 Mobile IPv6 session. For example, if the mobile node acquires both 436 IPv6 address and FQDN of the home agent, it may try to use the 437 address information of the home agent first. 439 If a Home Network Information option carries sub-option whose 'V' 440 flag does not match the id-type, the mobile node SHOULD skip that 441 sub-option. 443 When the mobile node requests the home network information with the 444 id-type 0 or 1 but cannot be provided with the proper information, 445 that is, option-len = 0 in the Home Network Information option, then 446 it may request again by setting the id-type to 2 in the Home Network 447 Identifier option. 449 4.2. NAS/DHCP Relay Agent Behavior 451 The NAS and the DHCP relay agent are assumed to be collocated in this 452 solution. The NAS communicates with the mobile node during the 453 network access authentication and interacts with the AAAH (via the 454 AAAV) using either Diameter NASREQ [RFC4005] or RADIUS 455 [I-D.ietf-mip6-radius] [Editor's note: The Diameter AVPs need to be 456 defined]. 458 Upon receiving the MIP6 related RADIUS or Diameter attributes 459 returned by the AAAH, the NAS passes the information to the 460 collocated DHCP relay agent. 462 Upon receiving the Information Request from the mobile node, the DHCP 463 relay agent MUST forward the message to the DHCP server as per 464 [RFC3315]. The relay agent SHALL use the OPTION_CLIENTID to identify 465 the mobile node (user). This is required to check whether there are 466 some additional information for the user that need to be appended 467 while relaying the information request message to the DHCP server. 468 If the relay agent determines that the NAS has passed home network 469 information for this mobile node, the relay agent MUST include the 470 received home network information in the MIP6 Relay Agent option, and 471 attach this option in the Relay-Forward message. The relay agent MAY 472 include the Interface-Id option [RFC3315] in the Relay-Forward 473 message. 475 The sub-options that carry home information for the same home agent 476 should be listed in sequential order of a sub-opt-code in the MIP6 477 Relay Agent option so as to indicate the coupling among home network 478 information for the same home agent. For example, the sub-options 479 for HA1 and HA2 are listed as follows. 481 sub-opt-code = 1 (HA1's IPv6 address) 483 sub-opt-code = 2 (HA1's FQDN) 484 sub-opt-code = 0 (Home subnet prefix under HA2) 486 sub-opt-code = 1 (HA2's IPv6 address) 488 sub-opt-code = 2 (HA2's FQDN) 490 Upon receiving a Reply message from the DHCPv6 server, the relay 491 agent SHALL follow the guidelines defined in [RFC3315] to forward the 492 message to the mobile node. 494 4.3. DHCP Server Behavior 496 The DHCP server MUST follow the following logic to process an 497 Information Request from the mobile node. 499 Information Request message includes: 501 A. OPTION_ORO and Home Network Identifier option with the id-type 0, 502 Interface-Id option, Client Identifier option, MIP6 Relay Agent 503 option. 505 If the DHCP server is configured with the local home information, it 506 MUST include the corresponding information in the Home Network 507 Information option of the Reply message, and set all of the V flag(s) 508 in its sub-option(s) to 1(s). The information may have been 509 configured statically in the server. 511 B. OPTION_ORO and Home Network Identifier option with the id-type 1, 512 Interface-Id option, Client Identifier option, MIP6 Relay Agent 513 option. 515 If the received Home Network Identifier option does not carry any 516 target MSP, the option MUST be skipped. 518 If the DHCP server has the corresponding information for the target 519 MSP, it MUST include the home information in the Home Network 520 Information option, and set all of the V flag(s) in its sub-option(s) 521 to 0(s). The server may provide the matching information extracted 522 from the MIP6 Relay Agent option. 524 C. OPTION_ORO and Home Network Identifier option with the id-type 2, 525 Interface-Id option, Client Identifier option, MIP6 Relay Agent 526 option. 528 In this case, the assignment of the home information relies on the 529 server's local policy, and the DHCP server SHOULD have its own policy 530 so that it can reply with the proper information in the Home Network 531 Information option. The policy can be determined based on several 532 factors such as the home agent availability and the authorization 533 information of the mobile node. However, the specific policy setting 534 is not in the scope of this document. The V flag(s) is/are set to 535 0(s) or 1(s) according to the type of provided home network 536 information. 538 The server SHOULD provide all of the matching home information in 539 Home Network Information option(s). When the server has more than 540 one home network information to provide for a single Home Network 541 Identifier option, it SHOULD include each of them in Home Network 542 Information sub-options and include these sub-options in a single 543 Home Network Information option. The sub-options for the same home 544 agent SHOULD be listed in sequential order of a sub-opt-code in the 545 Home Network Information option as described in section 4.2. In case 546 of the id-type 0 and 1, the V flags in all sub-options in a Home 547 Network Information option SHOULD be set to 1s and 0s respectively. 549 If the request message carries more than one Home Network Identifier 550 options, the reply message MUST contain Home Network Information 551 options as many as Home Network Identifier options in the request. 552 Though the server cannot find any home information for a specific id- 553 type, it MUST return the Home Network Information option by setting 554 the id-type to the requested id-type and the option-len to 0. The 555 Home Network Information options in the reply SHOULD appear in the 556 same order as Home Network Identifier options in the request and the 557 matching is based on the sequential order of options. This provides 558 a way of matching for Home Network Information options with the same 559 id-type. 561 In all Reply messages, the DHCP server MUST return the Interface-Id 562 option as received in the Information Request. The DHCP server 563 SHOULD use the Client Identifier option to identify the mobile node. 565 There can be various ways that a DHCP server learns mechanism to know 566 or retrieve the requested home network information. For instance, as 567 described in [I-D.ietf-mip6-radius], the NAS can learn the 568 information via RADIUS during network access authentication, and NAS- 569 collocated DHCP relay can transfer it to the DHCP server by the 570 proposed DHCP option in this document. However, the mechanism by 571 which the DHCP server is provisioned with the home network 572 information or obtains it dynamically is outside the scope of this 573 document. 575 5. Security Considerations 577 Secure delivery of home agent and home network information from a 578 DHCP server to the mobile node (DHCP client) relies on the same 579 security as DHCP. The particular option defined in this draft does 580 not have additional impact on DHCP security. 582 Aside from the DHCP client to server interaction, an operator must 583 also ensure secure delivery of mobile IP information to the DHCP 584 server. This is outside the scope of DHCP and the newly defined 585 option. 587 6. IANA Consideration 589 This document defines three new DHCPv6 options, Home Network 590 Identifier option, MIP6 Relay Agent option and Home Network 591 Information option. 593 IANA is requested to assign the following new DHCPv6 Option Codes in 594 the registry maintained in 595 http://www.iana.org/assignments/dhcpv6-parameters: 597 o OPTION_MIP6-HNID for the Home Network Identifier option 598 o OPTION_MIP6-RELAY for the MIP6 Relay Agent option 599 o OPTION_MIP6-HNINF for the Home Network Information option 601 7. Acknowledgements 603 The authors would like to thank Kilian Weniger, Domagoj Premec, 604 Basavaraj Patil, Vijay Devarapalli, Gerardo Giaretta, Behcet 605 Sarikaya, Vidya Narayanan and Miguel A. Diaz for their valuable input 606 and comments. 608 8. References 610 8.1. Normative References 612 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 613 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 614 Integrated Scenario", 615 draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in 616 progress), June 2007. 618 [I-D.ietf-mip6-radius] 619 Chowdhury, K., "RADIUS Mobile IPv6 Support", 620 draft-ietf-mip6-radius-02 (work in progress), March 2007. 622 [RFC1035] Mockapetris, P., "Domain names - implementation and 623 specification", STD 13, RFC 1035, November 1987. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 629 and M. Carney, "Dynamic Host Configuration Protocol for 630 IPv6 (DHCPv6)", RFC 3315, July 2003. 632 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 633 in IPv6", RFC 3775, June 2004. 635 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 636 "Diameter Network Access Server Application", RFC 4005, 637 August 2005. 639 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 640 Network Access Identifier", RFC 4282, December 2005. 642 8.2. Informative References 644 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 645 RFC 3753, June 2004. 647 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 648 Bellier, "Hierarchical Mobile IPv6 Mobility Management 649 (HMIPv6)", RFC 4140, August 2005. 651 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 652 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 653 September 2006. 655 Authors' Addresses 657 Hee Jin Jang 658 Samsung Advanced Institute of Technology 659 P.O. Box 111 660 Suwon 440-600 661 Korea 663 Email: heejin.jang@samsung.com 665 Alper E. Yegin 666 Samsung Electronics 667 Istanbul 668 Turkey 670 Email: alper01.yegin@partner.samsung.com 672 Kuntal Chowdhury 673 Starent Networks 674 30 International Place 675 Tewksbury, MA 01876 676 US 678 Email: kchowdhury@starentnetworks.com 680 JinHyeock Choi 681 Samsung Advanced Institute of Technology 682 P.O. Box 111 683 Suwon 440-600 684 Korea 686 Email: athene@sait.samsung.co.kr 688 Full Copyright Statement 690 Copyright (C) The IETF Trust (2007). 692 This document is subject to the rights, licenses and restrictions 693 contained in BCP 78, and except as set forth therein, the authors 694 retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 700 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 701 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Intellectual Property 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Acknowledgment 730 Funding for the RFC Editor function is provided by the IETF 731 Administrative Support Activity (IASA).