idnits 2.17.1 draft-jang-mip6-hiopt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When an MN sends a Binding Update message to home agent by using HoA which is assigned in Home Network Information option, the requested lifetime in Binding Update message MUST not be shorter than the lifetime of the HoA. Since the HoA lifetime is not greater than its prefix lifetime, it is guaranteed that binding cache entry's lifetime is not greater than the home prefix lifetime. Note that, according to 10.3.1 of MIPv6, the lifetime for the binding cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix of HoA specified with the Binding Update. -- 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 8, 2006) is 6531 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) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 3315 (ref. '4') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2486 (ref. '5') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-hmipv6 (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: December 10, 2006 JinHyeock Choi 5 SAMSUNG AIT 6 Kuntal Chowdhury 7 Starent Networks 8 June 8, 2006 10 DHCP Option for Home Information Discovery in MIPv6 11 draft-jang-mip6-hiopt-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 10, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This draft defines a DHCP-based scheme to enable dynamic discovery of 45 Mobile IPv6 home agent address, home address, and home subnet. New 46 DHCP options are defined to carry the information from a DHCP server 47 to the DHCP client running on the mobile node. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. DHCP options for HA Dynamic Discovery . . . . . . . . . . . . 5 54 3.1. Home Network Identifier Option . . . . . . . . . . . . . . 5 55 3.2. Home Network Information Option . . . . . . . . . . . . . 6 56 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 4.1. DHCP Server - Home Agent Relation . . . . . . . . . . . . 9 58 4.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 9 59 4.3. DHCP Server Considerations . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 64 Intellectual Property and Copyright Statements . . . . . . . . . . 14 66 1. Introduction 68 Before a mobile node can engage in Mobile IPv6 signaling with a home 69 agent, it should either know the IP address of the home agent via 70 preconfiguration, or dynamically discover it. Mobile IPv6 71 specification [2] describes how home agents can be dynamically 72 discovered by mobile nodes that know the home subnet prefix. This 73 scheme does not work when prefix information is not already available 74 to the mobile node. This problem can be solved by delivering one or 75 more home subnet prefix information to the mobile node by means of 76 DHCP. Subsequently, the mobile node can engage in dynamic home agent 77 discovery using the prefix information. In addition to delivering 78 the prefix information, DHCP can also be used to provide the IP 79 addresses or FQDNs of the home agents that are available to the 80 mobile node and the home address that the mobile node can use to 81 register with the home agent. 83 The solution involves defining new DHCP options to carry home subnet 84 prefix, home agent IP address, home agent's FQDN information, and 85 home address of the mobile node. A similar solution has already been 86 defined for Mobile IPv4 home agents [3]. 88 As part of configuring the initial TCP/IP parameters, a mobile node 89 can obtain home network information for the subnet it is directly 90 attached to, other subnets in the visited domain, or a subnet from 91 its home domain. A mobile node can convey the target home subnet's 92 identity in order to receive corresponding information. For example 93 the mobile node can provide realm portion of its user NAI (Network 94 Access Identifier) and expect that a home network information from 95 its home domain is returned. The availability of the requested 96 information depends on the DHCP server having prior knowledge or 97 dynamically discovering it. While the specific details are outside 98 the scope of this document, use of static tables and AAA-assisted 99 discovery are possible options [8]. 101 The mobile node may or may not be connected to the "home" subnet when 102 it attempts to learn Mobile IPv6 home network information. This 103 allows operators to centrally deploy home agents while being able to 104 bootstrap mobile nodes that are already roaming. This scenario also 105 occurs when HMIP [7] is used, where the mobile node is required to 106 discover the MAP (a special home agent) that is located multiple hops 107 away from the mobile node's attachment point. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119 [1]. 115 Most of terms used in this draft are defined in Mobile IPv6 [2] and 116 RFC3315 [4]. 118 3. DHCP options for HA Dynamic Discovery 120 This section introduces two DHCP options used for dynamic home agent 121 discovery in Mobile IPv6. 123 3.1. Home Network Identifier Option 125 This option is used to carry the identifier of the target home 126 network. This identification allows mobile node to request 127 information for a home subnet within the visited domain, or from a 128 specific domain. It is assumed that the DHCP server has some 129 mechanism to know or retrieve the requested Mobile IPv6 information 130 such as [9]. The specifics of these mechanisms are outside the scope 131 of this draft. 133 The mobile node MUST include this option along with its Option 134 Request option in its request. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | OPTION_HNId | option-len | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | id-type |A| reserved | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 143 | | 144 . . 145 . Home Network Identifier . 146 + + 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 option-code 152 OPTION_HNId (TBD) 154 option-len 156 Total length of the option 158 id-type 160 The type of Home Network Identifier: 162 0 Local (visited) domain 163 1 Network realm 165 A flag 167 A flag to specify whether the client requests a home 168 address or not. 170 reserved 172 8-bit field reserved for future use. The value MUST be 173 initialized to zero by the sender, and MUST be ignored 174 by the receiver. 176 Id-type 0 indicates the mobile node is interested in learning the 177 home network information that pertains to the immediately connected 178 (visited) network. In that case, Home Network Identifier field is 179 not used. This type can be used to discover local home agents in a 180 visited network. 182 Id-type 1 indicates the format of Home Network Identifier field is a 183 network realm as defined in [5]. In this case, the mobile node is 184 interested in learning home network information that pertains to the 185 given realm. This type can be used to discover home agents that are 186 hosted by a user's home domain (as indicated by his/her NAI-based 187 username -- user@HomeRealm). 189 If A flag is set in this option, the server should assign a home 190 address to the client in the returned Home Network Information 191 option. Otherwise, the server should not assign a home address 192 option. 194 3.2. Home Network Information Option 196 This option is used to carry home network information to a mobile 197 node in the form of one or more of home subnet prefix(es), home agent 198 address(es), home agent FQDN(s), and mobile node's home address. 200 The server MUST provide all of the matching home subnet prefix(es), 201 home agent address(es) or FQDN(s) in a Home Network Information 202 option. If the server has no information to provide, it MUST set the 203 option-len field to zero in this option. If the client set the A 204 flag in Home Network Identifier option, it MUST provide an available 205 home address to a client. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | OPTION_HNInf | option-len | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | hninfo-type | hninfo-len | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 214 | | 215 . . 216 . Home Network Information . 217 + + 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 option-code 223 OPTION_HNInf (TBD) 225 option-len 227 Total length of the option 229 hninfo-type 231 The type of following Home Network Information field. 232 Possible values are: 234 0 Home subnet prefix 236 1 Complete IPv6 address of the home agent 238 2 FQDN of the home agent 240 3 IPv6 Home address 242 hninfo-len 244 8-bit unsigned integer. Total length of the following 245 Home Network Information field. 247 Home Network Information 249 A home subnet prefix, home agent IP address, FQDN 250 and home address to be assigned to a mobile node. 252 When hninfo-type is set to 0, the data field MUST 253 contain 8-bit prefix length information followed 254 by a 128-bit IPv6 address beginning with the 255 available network prefix. 257 When hninfo-type is set to 1, the data field MUST 258 contain a 128-bit IPv6 address of the home agent. 260 When hninfo-type is set to 2, the data field MUST 261 contain a FQDN as described in RFC1035 [6]. 263 When hninfo-type is set to 3, the data field MUST 264 contain the 8-bit reserved field, 8-bit prefix length 265 field of the following home address, 32-bit lifetime 266 of the following home address and the 128-bit home 267 address to be assigned to a client. The lifetime is 268 expressed in units of seconds. 270 The home address, or hninfo-type = 3, should be included if and only 271 if the client sets A flag in Home Network Identifier option. Setting 272 the lifetime to 0xffffffff ("infinity") means a permanent assignment 273 of an address to the client. The lifetime of the assigned home 274 address should not be longer than the lifetime of its prefix since 275 the home address cannot survive the prefix lifetime. 277 If id-type is 0 in Home Network Identifier option, the server should 278 reply with the available home agent(es) or home address information 279 in the visited network. Otherwise, it should return that information 280 in the specified home network in Home Network Identifier field in the 281 request option. 283 Single option can carry multiple information preceded by hninfo-type 284 and hninfo-len fields. The length fields help identify the 285 information boundaries. 287 4. Option Usage 289 The requesting and sending of this option follows the rules for DHCP 290 options in [4]. 292 4.1. DHCP Server - Home Agent Relation 294 The DHCP server does not have to be co-located with a home agent, or 295 even be on the home subnet of the mobile node. Its location with 296 respect to home network does not matter as long as it possesses the 297 requested information. 299 4.2. Mobile Node Considerations 301 When a Mobile IPv6 mobile node finds itself with neither a home 302 subnet prefix/home address nor a home agent address, it may request 303 the needed information with Option Request option. For instance, a 304 mobile node connecting to a network for the first time may acquire a 305 DHCP address and solicit for home network information at the same 306 time. 308 A mobile node MUST identify the desired information with Home Network 309 Identifier option. For example, a DHCP server may have information 310 about home agents from several domains (and subnets). It relies on 311 the mobile node to select the domain for determining which ones it 312 should provide in response to the client's request. 314 When the mobile node gets more than one home agent address, it MUST 315 have a selection mechanism to determine which one to use for 316 establishing a Mobile IPv6 session. In case it retrieves only home 317 subnet prefix(es), it needs to perform dynamic home agent discovery 318 to learn the IP addresses of the home agents. Similarly, if FQDN of 319 a home agent is retrieved, the mobile node can use DNS to resolve it 320 to IPv6 address(es) of the home agents. If the mobile node receives 321 both IPv6 address(es) and FQDN(s) of the home agents, it SHALL use 322 the IPv6 information of the home agents. When the mobile node 323 requests and receives the home address information from the DHCP 324 server, it SHALL use it to perform Mobile IPv6 home registration. 325 For detailed mobile node behavior, refer to section 3.6 of [9]. 327 When an MN sends a Binding Update message to home agent by using HoA 328 which is assigned in Home Network Information option, the requested 329 lifetime in Binding Update message MUST not be shorter than the 330 lifetime of the HoA. Since the HoA lifetime is not greater than its 331 prefix lifetime, it is guaranteed that binding cache entry's lifetime 332 is not greater than the home prefix lifetime. Note that, according 333 to 10.3.1 of MIPv6, the lifetime for the binding cache entry MUST NOT 334 be greater than the remaining valid lifetime for the subnet prefix of 335 HoA specified with the Binding Update. 337 4.3. DHCP Server Considerations 339 It is assumed that the DHCP server has access to home network 340 information for its clients for this option to be useful. The DHCP 341 server can rely on pre-configuration, or some dynamic discovery 342 mechanisms for obtaining this information. In case it does not have 343 any information, or it cannot locate matching information based on 344 Home Network Identifier, it returns a Home Network Information option 345 with 0-length data. The DHCP server can either return the IPv6 346 address(es) of home agent or the FQDN(s) of home agents. It is not 347 required for the DHCP server to return both. 349 When a DHCP server assigns a HoA to an MN, it should guarantee that 350 the lifetime of assigned HoA MUST NOT be greater than that of the 351 subnet prefix in the MN's HoA. The lifetimes of HoAs for assignments 352 are can be negotiated when the home prefix is delivered from the home 353 agent, or configured by DHCP administrator's policy. The details are 354 outside the scope of this document. 356 5. Security Considerations 358 Secure delivery of home agent, home address, and home link 359 information from a DHCP server to the mobile node (DHCP client) 360 relies on the overall DHCP security. The particular option defined 361 in this draft does not have additional impact on the DHCP security. 363 Aside from the DHCP client to server interaction, an operator must 364 also ensure secure delivery of mobile IP information to the DHCP 365 server. This is outside the scope of DHCP and the newly defined 366 option. 368 6. IANA Consideration 370 This document introduces two new DHCPv6 options, Home Agent Request 371 option and Home Agent Reply option. The type numbers for new DHCP 372 options are currently TBD. An appropriate request will be made to 373 IANA if this Internet draft gets accepted as an RFC. 375 7. Normative References 377 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 378 Levels", BCP 14, RFC 2119, March 1997. 380 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 381 IPv6", RFC 3775, June 2004. 383 [3] Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents", 384 draft-ietf-dhc-mipadvert-opt-02 (work in progress), 385 February 2004. 387 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 388 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 389 RFC 3315, July 2003. 391 [5] Aboba, B. and M. Beadles, "The Network Access Identifier", 392 RFC 2486, January 1999. 394 [6] Mockapetris, P., "Domain names - implementation and 395 specification", STD 13, RFC 1035, November 1987. 397 [7] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 398 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 399 draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. 401 [8] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6 402 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work 403 in progress), November 2004. 405 [9] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 406 the Integrated Scenario", 407 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 408 progress), October 2005. 410 Authors' Addresses 412 Hee Jin Jang 413 Samsung Advanced Institute of Technology 414 P.O. Box 111 415 Suwon 440-600 416 Korea 418 Email: heejin.jang@samsung.com 420 Alper E. Yegin 421 Samsung Advanced Institute of Technology 422 Istanbul 423 Turkey 425 Email: alper01.yegin@partner.samsung.com 427 JinHyeok Choi 428 Samsung Advanced Institute of Technology 429 P.O. Box 111 430 Suwon 440-600 431 Korea 433 Email: athene@sait.samsung.co.kr 435 Kuntal Chowdhury 436 Starent Networks 437 30 International Place 438 Tewksbury, MA 01876 439 US 441 Email: kchowdhury@starentnetworks.com 443 Intellectual Property Statement 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Disclaimer of Validity 469 This document and the information contained herein are provided on an 470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 Copyright Statement 479 Copyright (C) The Internet Society (2006). This document is subject 480 to the rights, licenses and restrictions contained in BCP 78, and 481 except as set forth therein, the authors retain all their rights. 483 Acknowledgment 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society.