idnits 2.17.1 draft-ietf-mip6-hiopt-03.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 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 661. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 (May 16, 2007) is 6189 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: '10' is defined on line 574, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3315 (ref. '4') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') ** Obsolete normative reference: RFC 3775 (ref. '6') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4005 (ref. '7') (Obsoleted by RFC 7155) ** Downref: Normative reference to an Informational RFC: RFC 4640 (ref. '9') -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 4140 (ref. '11') (Obsoleted by RFC 5380) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-02 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-03 Summary: 8 errors (**), 0 flaws (~~), 5 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 Expires: November 17, 2007 SAMSUNG 5 Kuntal Chowdhury 6 Starent Networks 7 JinHyeock Choi 8 SAMSUNG 9 May 16, 2007 11 DHCP Option for Home Information Discovery in MIPv6 12 draft-ietf-mip6-hiopt-03.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 November 17, 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 agent address, home agent FQDN and home subnet. New 47 DHCP options are defined to carry the information from a DHCP server 48 to the DHCP client running on the mobile node. 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 . . . . . . . . . 9 60 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.1. Mobile Node Behavior . . . . . . . . . . . . . . . . . . . 11 62 4.2. NAS/DHCP Relay Agent Behavior . . . . . . . . . . . . . . 12 63 4.3. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction 72 Before a mobile node can engage in Mobile IPv6 signaling with a home 73 agent, it should either know the IP address of the home agent via 74 pre-configuration, or dynamically discover it. Mobile IPv6 75 specification [6] describes how home agents can be dynamically 76 discovered by mobile nodes that know the home subnet prefix. This 77 scheme does not work when prefix information is not already available 78 to the mobile node. This problem can be solved by delivering one or 79 more home subnet prefix information to the mobile node by means of 80 DHCP. Subsequently, the mobile node can engage in dynamic home agent 81 discovery using the prefix information. In addition to delivering 82 the prefix information, DHCP can also be used to provide the IP 83 addresses or FQDNs of the home agents that are available to the 84 mobile node and the home address that the mobile node can use to 85 register with the home agent. The solution involves defining new 86 DHCP options to carry home subnet prefix, home agent IP address and 87 home agent's FQDN information. 89 As part of configuring the initial TCP/IP parameters, a mobile node 90 can obtain home network information for the subnet it is directly 91 attached to, other subnets in the visited domain, or a subnet from 92 its home domain. A mobile node can convey the target home subnet's 93 identity in order to receive corresponding information. For example 94 the mobile node can provide realm portion of its user NAI (Network 95 Access Identifier) and expect that a home network information from 96 its home domain is returned. The availability of the requested 97 information depends on the DHCP server having prior knowledge or 98 dynamically discovering it. While the specific details are outside 99 the scope of this document, use of static tables and AAA-assisted 100 discovery are possible options [12]. 102 The mobile node may or may not be connected to the "home" subnet when 103 it attempts to learn Mobile IPv6 home network information. This 104 allows operators to centrally deploy home agents while being able to 105 bootstrap mobile nodes that are already roaming. This scenario also 106 occurs when HMIPv6 [11] is used, where the mobile node is required to 107 discover the MAP (a special home agent) that is located multiple hops 108 away from the mobile node's attachment point. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [2]. 116 General mobility terminology can be found in RFC3753 [5]. The 117 following additional terms, as defined in RFC4640 [9], are used in 118 this document: 120 Access Service Provider (ASP): A network operator that provides 121 direct IP packet forwarding to and from the mobile node. 123 Mobility Service Provider (MSP): A service provider that provides 124 Mobile IPv6 service. In order to obtain such service, the mobile 125 node must be authenticated and authorized to obtain the Mobile IPv6 126 service. 128 3. DHCP options for HA Dynamic Discovery 130 This section introduces new DHCP options used for dynamic home 131 information discovery in Mobile IPv6. The draft [13] describes the 132 whole interworking procedure for Home Agent assignment among MN, NAS, 133 DHCP, and AAA entities for bootstrapping procedure in the integrated 134 scenario. 136 3.1. Home Network Identifier Option 138 This option is used to carry the identifier of the target home 139 network. The mobile node MUST include this option along with its 140 Option Request option in its request. 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | OPTION_MIP6-HNID | option-len | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | id-type | reserved | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 148 . . 149 . Home Network Identifier . 150 . . 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 option-code 155 OPTION_MIP6-HNID (TBD) 157 option-len 159 Total length of the option in octets 161 id-type 163 The type of Home Network Identifier: 165 0 Visited domain (local ASP) 167 1 The target network 169 2 No preference 171 reserved 173 An 8-bit field reserved for future use. The value MUST 174 be initialized to 0 by the sender and MUST be ignored by 175 the receiver. 177 Home Network Identifier 179 The identifier to specify the requested home network of the 180 mobile node. This field MUST be set to the network realm as 181 the FQDN defined in [3] when the id-type is 1. 183 The id-type 0 indicates the mobile node is interested in learning the 184 home network information that pertains to the currently visited 185 network. This type can be used to discover local home agents in the 186 local ASP. In this case, the Home Network Identifier field SHOULD be 187 set to 0. 189 The id-type 1 indicates the mobile node is interested in learning the 190 home network information that pertains to the given realm. This type 191 can be used to discover home agents that are hosted by a user's home 192 domain (as indicated by his/her NAI-based username -- user@ 193 HomeRealm). The Home Network Identifier field MUST be set to the 194 requested target network which is not in the visited domain. The 195 target network can be a home MSP or a MSP which has trust roaming 196 relationship with the mobile node's home MSP. 198 If the mobile node has no preference, the id-type is set to 2 and the 199 Home Network Identifier SHOULD be initialized to 0. In this case, 200 the assignment of the home network information is within the server's 201 own discretion. For the detailed processing, refer to Section 4. 203 3.2. MIP6 Relay Agent Option 205 This option carries the RADIUS or Diameter attributes that are 206 received at the NAS from the AAAH. The DHCP relay agent sends this 207 option to the DHCP server in the Relay-Forward message. 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | OPTION_MIP6-RELAY | option-len | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 . sub-options . 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 option-code 218 OPTION_MIP6-RELAY (TBD). 220 option-len 222 Total length of the option in octets 224 sub-options 225 A series of sub-options carrying MIP6 bootstrap 226 information. 228 3.2.1. MIP6 Relay Agent Sub-option 230 This sub-option carries the assigned home network information to the 231 DHCP server. 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | sub-opt-code | sub-opt-len | reserved | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 237 . . 238 . Home Network Information . 239 . . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 sub-opt-code 244 The sub-option identifies the type of the following 245 Home Network Information field. Possible values are: 247 0 Home subnet prefix 249 1 Complete IPv6 address of the home agent 251 2 FQDN of the home agent 253 sub-opt-len 255 An 8-bit unsigned integer. Total length of the 256 following Home Network Information field. 258 reserved 260 An 8-bit field reserved for future use. The value MUST 261 be initialized to 0 by the sender, and MUST be ignored by 262 the receiver. 264 Home Network Information 266 A home subnet prefix, home agent IP address or home 267 agent FQDN to be provided to a mobile node. 269 When the sub-opt-code is set to 0, the data field MUST contain the 270 8-bit prefix length information followed by the 128-bit IPv6 address 271 beginning with the available network prefix. 273 When the sub-opt-code is set to 1, the data field MUST contain the 274 128-bit IPv6 address of the home agent. 276 When the sub-opt-code is set to 2, the data field MUST contain the 277 FQDN as described in RFC1035 [1]. 279 Multiple sub-options may exist in a MIP6 Relay Agent option to carry 280 more than one home information. 282 3.3. Home Network Information Option 284 This option is used to carry home network information to a mobile 285 node in the form of one or more of home subnet prefix(es), home agent 286 address(es) and home agent FQDN(s). The server SHOULD provide all of 287 the matching home information in a Home Network Information option. 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | OPTION_MIP6-HNINF | option-len | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 . sub-options . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 option-code 298 OPTION_MIP6-HNINF (TBD). 300 option-len 302 Total length of the option in octets 304 sub-options 305 A series of sub-options carrying MIP6 bootstrap 306 information. 308 3.3.1. Home Network Information Sub-option 310 This sub-option carries the assigned home network information to the 311 DHCP client. 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | sub-opt-code | sub-opt-len | reserved | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 317 . . 318 . Home Network Information . 319 . . 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 sub-opt-code 324 The type of the following Home Network Information field. 325 Possible values are: 327 0 Home subnet prefix 329 1 Complete IPv6 address of the home agent 331 2 FQDN of the home agent 333 sub-opt-len 335 An 8-bit unsigned integer. Total length of the following 336 Home Network Information field. 338 reserved 340 An 8-bit field reserved for future use. The value MUST 341 be initialized to 0 by the sender, and MUST be ignored by 342 the receiver. 344 Home Network Information 346 A home subnet prefix, home agent IP address or home agent 347 FQDN to be provided to a mobile node. 349 All fields are set in the same manner as those of a MIP6 Relay Agent 350 sub-option. 352 Multiple sub-options may exist in a Home Network Information option 353 to carry more than one home information. 355 The detailed processing for each id-type is described in Section 4. 357 4. Option Usage 359 The requesting and sending of the proposed DHCP options follow the 360 rules for DHCP options in [4]. The following DHCP options [4] are 361 also required in the solution for normal DHCP operation: 363 - Option Request option 365 - Client Identifier option 367 - Relay Message option 369 - Interface-Id option 371 4.1. Mobile Node Behavior 373 In order to acquire the home network information, the mobile node 374 SHALL send an Information Request to the 375 All_DHCP_Relay_Agents_and_Servers multicast address. In this message 376 the mobile node (DHCP client) SHALL include the Option Code for Home 377 Network Identifier option in the OPTION_ORO. The mobile node SHALL 378 also include the OPTION_CLIENTID [4] to identify itself to the DHCP 379 server. 381 During requesting the information, the mobile node MUST clarify the 382 preference about the requested home network with the id-type in the 383 Home Network Identifier option. Even if the mobile node does not 384 care about the location of the home network where the home agent to 385 be assigned, it MUST clarify the fact by setting the id-type to 2. 386 In this case the Home Network Identifier SHOULD be set to 0. 388 When the mobile node receives the Reply message from the DHCP server 389 and gets more than one home agent address(es), it MUST have a 390 selection mechanism to determine which one to use for establishing a 391 Mobile IPv6 session. For example, if the mobile node acquires both 392 IPv6 address(es) and FQDN(s) of the home agent(s), it may try to use 393 the address information of the home agent(s) first. 395 If the mobile node wants to retrieve home network information from 396 both the visited network (ASP) and the target MSP with a single 397 transaction, it should request the information by using two Home 398 Network Identifier options with the id-type 0 and the id-type 1. 400 When the mobile node requests the home network information with the 401 id-type 0 or 1 but cannot be provided with the proper information, 402 that is, option-len = 0 in the Home Network Information option, then 403 it may request again by setting the id-type to 2 in the Home Network 404 Identifier option. 406 4.2. NAS/DHCP Relay Agent Behavior 408 The NAS and the DHCP relay agent are assumed to be collocated in this 409 solution. The NAS communicates with the mobile node during the 410 network access authentication and interacts with the AAAH (via the 411 AAAV) using either Diameter NASREQ RFC4005 [7] or RADIUS [12] 412 [Editor's note: The Diameter AVPs need to be defined]. 414 Upon receiving the MIP6 related RADIUS or Diameter attributes 415 returned by the AAAH, the NAS passes the information to the 416 collocated DHCP relay agent. 418 Upon receiving the Information Request from the mobile node, the DHCP 419 relay agent MUST forward the message to the DHCP server as per [4]. 420 The relay agent SHALL use the OPTION_CLIENTID to identify the mobile 421 node (user). This is required to check whether there are some 422 additional information for the user that need to be appended while 423 relaying the information request message to the DHCP server. If the 424 relay agent determines that the NAS has passed home network 425 information for this mobile node, the relay agent MUST include the 426 received home network information in the MIP6 Relay Agent option, and 427 attach this option in the Relay-Forward message. The relay agent MAY 428 include the Interface-Id option [4] in the Relay-Forward message. 430 The sub-options that carry home information for the same home agent 431 should be listed in sequential order of a sub-opt-code in the MIP6 432 Relay Agent option so as to indicate the coupling among home network 433 information for the same home agent or home subnet. For example, the 434 sub-options for HA1 and HA2 are listed as follows. 436 sub-opt-code = 1 (HA1's IPv6 address) 438 sub-opt-code = 2 (HA1's FQDN) 440 sub-opt-code = 0 (Home subnet prefix under HA2) 442 sub-opt-code = 1 (HA2's IPv6 address) 444 sub-opt-code = 2 (HA2's FQDN) 446 The DHCP relay agent MUST insert MN-NAI option [8] in the Relay- 447 Forward message in order to indicate the home network of the user to 448 the DHCP server. This information is compared with the target 449 network in the Home Network Information option when the DHCP server 450 returns the corresponding home network information. 452 Upon receiving the Reply message from the DHCPv6 server, the relay 453 agent SHALL follow the guidelines defined in [4] to forward the 454 message to the mobile node. 456 4.3. DHCP Server Behavior 458 The DHCP server MUST follow the following logic to process 459 Information Request from the mobile node. 461 Information Request message includes: 463 A. OPTION_ORO and Home Network Identifier option with the id-type 0, 464 Interface-Id option, Client Identifier option, MIP6 Relay Agent 465 option. 467 If the DHCP server is configured with the local home information, it 468 MUST include the corresponding information in the Home Network 469 Information option of the Reply message. The information may have 470 been configured statically in the server. 472 B. OPTION_ORO and Home Network Identifier option with the id-type 1, 473 Interface-Id option, Client Identifier option, MIP6 Relay Agent 474 option. 476 If the received Home Network Identifier option does not carry any 477 home MSP, the option is ignored. 479 If the DHCP server has the corresponding information for the 480 specified home MSP, it MUST include the corresponding information in 481 the Home Network Information option. The server may provide the 482 matching information extracted from the MIP6 Relay Agent option. 484 C. OPTION_ORO and Home Network Identifier option with the id-type 2, 485 Interface-Id option, Client Identifier option, MIP6 Relay Agent 486 option. 488 In this case, the assignment of the home information relies on the 489 server's local policy, and the DHCP server SHOULD have its own policy 490 so that it can reply with the proper information. The policy can be 491 determined based on several factors such as the home agent 492 availability and the authorization information of the mobile node. 493 However, the specific policy setting is not in the scope of this 494 document. 496 It is assumed that a DHCP server has some mechanism to know or 497 retrieve the requested Mobile IPv6 information. For instance, as 498 described in [12], the NAS can learn the information via RADIUS 499 during network access authentication, and NAS-collocated DHCP relay 500 can transfer it to the DHCP server by the proposed DHCP option in 501 this document. The DHCP server may gather the home network 502 information in other ways, but the specifics of these mechanisms are 503 outside the scope of this document. 505 When the DHCP server provides the home information that is retrieved 506 from the MIP6 Relay Agent option, it MUST compare the NAI's realm 507 information of MN-NAI option with the target network in Home Network 508 Identifier option. If they match, the DHCP server replies with the 509 Reply message after copying the home information in MIP6 Relay Agent 510 option to Home Network Information option. 512 In case the server cannot find any home information for the requested 513 id-type, it MUST return a Home Network Information option with the 514 0-length data. 516 The sub-options for the same home agent SHOULD be listed in 517 sequential order of a sub-opt-code in the Home Network Information 518 option. 520 In all Reply messages, the DHCP server MUST return the Interface-Id 521 option as received in the Information Request. The DHCP server 522 SHOULD use the Client Identifier option to identify the mobile node. 524 5. Security Considerations 526 Secure delivery of home agent, home address, and home link 527 information from a DHCP server to the mobile node (DHCP client) 528 relies on the overall DHCP security. The particular option defined 529 in this draft does not have additional impact on the DHCP security. 531 Aside from the DHCP client to server interaction, an operator must 532 also ensure secure delivery of mobile IP information to the DHCP 533 server. This is outside the scope of DHCP and the newly defined 534 option. 536 6. IANA Consideration 538 This document introduces two new DHCPv6 options, Home Agent Request 539 option and Home Agent Reply option. The type numbers for new DHCP 540 options are currently TBD. An appropriate request will be made to 541 IANA if this Internet draft gets accepted as an RFC. 543 7. Normative References 545 [1] Mockapetris, P., "Domain names - implementation and 546 specification", STD 13, RFC 1035, November 1987. 548 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 549 Levels", BCP 14, RFC 2119, March 1997. 551 [3] Aboba, B. and M. Beadles, "The Network Access Identifier", 552 RFC 2486, January 1999. 554 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 555 Carney, "Dynamic Host Configuration Protocol for IPv6 556 (DHCPv6)", RFC 3315, July 2003. 558 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 559 RFC 3753, June 2004. 561 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 562 IPv6", RFC 3775, June 2004. 564 [7] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 565 Network Access Server Application", RFC 4005, August 2005. 567 [8] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 568 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 569 RFC 4283, November 2005. 571 [9] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 572 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 574 [10] Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents", 575 draft-ietf-dhc-mipadvert-opt-02 (work in progress), 576 February 2004. 578 [11] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 579 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 580 RFC 4140, August 2005. 582 [12] Chowdhury, K., "RADIUS Mobile IPv6 Support", 583 draft-ietf-mip6-radius-02 (work in progress), March 2007. 585 [13] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 586 Integrated Scenario", 587 draft-ietf-mip6-bootstrapping-integrated-dhc-03 (work in 588 progress), April 2007. 590 Authors' Addresses 592 Hee Jin Jang 593 Samsung Advanced Institute of Technology 594 P.O. Box 111 595 Suwon 440-600 596 Korea 598 Email: heejin.jang@samsung.com 600 Alper E. Yegin 601 Samsung Electronics 602 Istanbul 603 Turkey 605 Email: alper01.yegin@partner.samsung.com 607 Kuntal Chowdhury 608 Starent Networks 609 30 International Place 610 Tewksbury, MA 01876 611 US 613 Email: kchowdhury@starentnetworks.com 615 JinHyeok Choi 616 Samsung Advanced Institute of Technology 617 P.O. Box 111 618 Suwon 440-600 619 Korea 621 Email: athene@sait.samsung.co.kr 623 Full Copyright Statement 625 Copyright (C) The IETF Trust (2007). 627 This document is subject to the rights, licenses and restrictions 628 contained in BCP 78, and except as set forth therein, the authors 629 retain all their rights. 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Intellectual Property 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 663 Acknowledgment 665 Funding for the RFC Editor function is provided by the IETF 666 Administrative Support Activity (IASA).