idnits 2.17.1 draft-jang-dhc-haopt-01.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 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. ** 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 -- 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 (April 25, 2005) is 6935 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: '7' is defined on line 330, but no explicit reference was found in the text ** 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' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Hee Jin Jang 3 Internet-Draft Alper Yegin 4 Expires: October 27, 2005 JinHyeock Choi 5 SAMSUNG AIT 6 April 25, 2005 8 DHCP Option for Home Agent Discovery in MIPv6 9 draft-jang-dhc-haopt-01.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 October 27, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This draft defines a DHCP-based scheme to enable dynamic discovery of 43 Mobile IPv6 home agent address and home subnet. New DHCP options are 44 defined to carry the information from a DHCP server to the DHCP 45 client running on the mobile node. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. DHCP options for HA Dynamic Discovery . . . . . . . . . . . . 5 52 3.1 Home Network Identifier Option . . . . . . . . . . . . . . 5 53 3.2 Home Network Information Option . . . . . . . . . . . . . 6 54 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.1 DHCP Server - Home Agent Relation . . . . . . . . . . . . 8 56 4.2 Mobile Node Considerations . . . . . . . . . . . . . . . . 8 57 4.3 DHCP Server Considerations . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . 13 64 1. Introduction 66 Before a mobile node can engage in Mobile IPv6 signaling with a home 67 agent, it should either know the IP address of the home agent via 68 preconfiguration, or dynamically discover it. Mobile IPv6 69 specification[2] describes how home agents can be dynamically 70 discovered by mobile nodes that know the home subnet prefix. This 71 scheme does not work when prefix information is not already available 72 to the mobile node. This problem can be solved by delivering one or 73 more home subnet prefix information to the mobile node by means of 74 DHCP. Subsequently, the mobile node can engage dynamic home agent 75 discovery using the prefix information. In addition to delivering 76 the prefix information, DHCP can also be used to directly provide the 77 IP addresses or FQDNs of the home agents that are available to the 78 mobile node. 80 The solution involves defining new DHCP options to carry home subnet 81 prefix, home agent IP address and FQDN information. A similar 82 solution has already been defined for Mobile IPv4 home agents[3]. 84 As part of configuring the initial TCP/IP parameters, a mobile node 85 can obtain home network information for the subnet it is directly 86 attached to, other subnets in the visited domain, or a subnet from 87 its home domain. Mobile node can convey the target home subnet's 88 identity in order to receive corresponding information. For example 89 the mobile node can provide realm portion of its user NAI and expect 90 that a home agent information from its home domain is returned. The 91 availability of the requested information depends on the DHCP server 92 having prior knowledge or dynamically discovering it. While the 93 specific details are outside the scope of this document, use of 94 static tables and AAA-assisted discovery are possible options[8]. 96 The mobile node may or may not be connected to the "home" subnet when 97 it attempts to learn Mobile IPv6 home network information. This 98 allows operators to centrally deploy home agents while being able to 99 bootstrap mobile nodes that are already roaming. This scenario 100 occurs when HMIP[7]is used, where the mobile node is required to 101 discover the MAP (a special home agent) that is located multiple hops 102 away from the mobile node's attachment point. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119[1]. 110 Most of terms used in this draft are defined in Mobile IPv6[2] and 111 RFC3315[4]. 113 3. DHCP options for HA Dynamic Discovery 115 This section introduces two DHCP options used for dynamic home agent 116 discovery in Mobile IPv6. 118 3.1 Home Network Identifier Option 120 This option is used to carry the identifier of the target home 121 network. This identification allows mobile node to request 122 information for a home subnet within the visited domain, or from a 123 specific domain. It is assumed that the DHCP server has some 124 mechanism to know or retrieve the requested Mobile IPv6 information. 125 The specifics of these mechanisms are outside the scope of this 126 draft. 128 The mobile node MUST include this option along with its Option 129 Request option in its request. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | OPTION_HNId | option-len | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | id-type | | 137 +-+-+-+-+-+-+-+-+ + 138 | | 139 . . 140 . Home Network Identifier . 141 + + 142 | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 option-code 147 OPTION_HNId (TBD) 149 option-len 151 Total length of the option 153 id-type 155 The type of Home Network Identifier: 157 0 Local (visited) domain 158 1 Network realm 160 Id-type 0 indicates the mobile node is interested in learning the 161 home network information that pertains to the immediately connected 162 (visited) network. In that case, Home Network Identifier field is 163 not used. This type can be used to discover local home agents in a 164 visited network. 166 Id-type 1 indicates the format of Home Network Identifier field is a 167 network realm as defined in [5]. In this case, the mobile node is 168 interested in learning home network information that pertains to the 169 given realm. This type can be used to discover home agents that are 170 hosted by a user's home domain (as indicated by his/her NAI-based 171 username -- user@HomeRealm). 173 3.2 Home Network Information Option 175 This option is used to carry home network information in the form of 176 one or more of home subnet prefix(es), home agent address(es), and 177 FQDN(s) to a mobile node. 179 The server MUST provide all of the matching home subnet prefix(es), 180 home agent address(es) and FQDN(s) in a Home Network Information 181 option. If the server has no information to provide, it MUST set the 182 option-len field to zero in this option. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | OPTION_HNInf | option-len | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | hainfo-type | hainfo-len | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 191 | | 192 . . 193 . Home Network Information . 194 + + 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 option-code 199 OPTION_HNInf (TBD) 201 option-len 203 Total length of the option 205 hainfo-type 207 The type of following Home Network Information field. 208 Possible values are: 210 0 Home subnet prefix 212 1 Complete IPv6 address of the home agent 214 2 FQDN of the home agent 216 hainfo-len 218 8-bit unsigned integer. Length of the home agent 219 information field plus 1. 221 Home Network Information 223 A home subnet prefix, home agent IP address or FQDN. 225 When hninfo-type is set to 0, the data field MUST 226 contain 8-bit prefix length information followed 227 by a 128-bit IPv6 address. 229 When hninfo-type is set to 1, the data field MUST 230 contain a 128-bit IPv6 address. 232 When hninfo-type is set to 2, the data field MUST 233 contain a FQDN as described in RFC1035[6]. 235 Single option can carry multiple information preceded by hninfo-type 236 and hninfo-len fields. The length fields help identify the 237 information boundaries. 239 4. Option Usage 241 The requesting and sending of this option follows the rules for DHCP 242 options in [4]. 244 4.1 DHCP Server - Home Agent Relation 246 The DHCP server does not have to be co-located with a home agent, or 247 even be on the home subnet of the mobile node. Its location with 248 respect to home network does not matter as long as it possesses the 249 requested information. 251 4.2 Mobile Node Considerations 253 When a Mobile IPv6 Mobile Node finds itself with neither a home 254 subnet prefix nor a home agent address, it may request the needed 255 information with Option Request option. For instance, a mobile node 256 connecting to a network for the first time may acquire a DHCP address 257 and solicit for home network information at the same time. 259 A mobile node MUST identify the desired information with Home Network 260 Identifier option. For example, a DHCP server may have information 261 about home agents from several domains (and subnets). It relies on 262 the mobile node to select the domain for determining which ones it 263 should provide in response to the client's request. 265 When the mobile node gets more than one home agent address, it MUST 266 have a selection mechanism to determine which one to use for 267 establishing a Mobile IPv6 session. In case it retrieves only home 268 subnet prefix(es), it needs to perform dynamic home agent discovery 269 to learn the IP addresses of the home agents. Similarly, if FQDN of 270 a home agent is retrieved, the mobile node can use DNS to resolve it 271 to IPv6 address(es). 273 4.3 DHCP Server Considerations 275 It is assumed that the DHCP server has access to home network 276 information for its clients for this option to be useful. The DHCP 277 server can rely on pre-configuration, or some dynamic discovery 278 mechanisms for obtaining this information. In case it does not have 279 any information, or it cannot locate matching information based on 280 Home Network Identifier, it returns a Home Network Information option 281 with 0-length data. 283 The DHCP server MUST NOT send the Home Network Information option if 284 the client sends a Option Request option and the code for the Home 285 Network Information option does not appear in the parameter request 286 list, even if the Home Network Identifier option appears in the 287 client's list of options. 289 5. Security Considerations 291 Secure delivery of home agent and home link information from a DHCP 292 server to the mobile node (DHCP client) relies on the overall DHCP 293 security. The particular option defined in this draft does not have 294 additional impact on the DHCP security. 296 Aside from the DHCP client to server interaction, an operator must 297 also ensure secure delivery of mobile IP information to the DHCP 298 server. This is outside the scope of DHCP and the newly defined 299 option. 301 6. IANA Consideration 303 This document introduces two new DHCPv6 options, Home Agent Request 304 option and Home Agent Reply option. The type numbers for new DHCP 305 options are currently TBD. An appropriate request will be made to 306 IANA if this Internet draft gets accepted as an RFC. 308 7. Normative References 310 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 311 Levels", BCP 14, RFC 2119, March 1997. 313 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 314 IPv6", RFC 3775, June 2004. 316 [3] Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents", 317 draft-ietf-dhc-mipadvert-opt-02 (work in progress), 318 February 2004. 320 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 321 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 322 RFC 3315, July 2003. 324 [5] Aboba, B. and M. Beadles, "The Network Access Identifier", 325 RFC 2486, January 1999. 327 [6] Mockapetris, P., "Domain names - implementation and 328 specification", STD 13, RFC 1035, November 1987. 330 [7] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 331 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 332 draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. 334 [8] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6 335 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work 336 in progress), November 2004. 338 Authors' Addresses 340 Hee Jin Jang 341 i-Networking Lab Samsung AIT 342 P.O. Box 111 Suwon 343 440-600 Korea 345 Email: heejin.jang@samsung.com 346 Alper E. Yegin 347 i-Networking Lab Samsung AIT 348 75 West Plumeria Drive 349 San Jose, CA 95134 USA 351 Email: alper.yegin@samsung.com 353 JinHyeok Choi 354 i-Networking Lab Samsung AIT 355 P.O. Box 111 Suwon 356 440-600 Korea 358 Email: athene@sait.samsung.co.kr 360 Intellectual Property Statement 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in 365 this document or the extent to which any license under such rights 366 might or might not be available; nor does it represent that it has 367 made any independent effort to identify any such rights. Information 368 on the procedures with respect to rights in RFC documents can be 369 found in BCP 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an 373 attempt made to obtain a general license or permission for the use of 374 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary 380 rights that may cover technology that may be required to implement 381 this standard. Please address the information to the IETF at 382 ietf-ipr@ietf.org. 384 Disclaimer of Validity 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 389 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 390 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 391 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Copyright Statement 396 Copyright (C) The Internet Society (2005). This document is subject 397 to the rights, licenses and restrictions contained in BCP 78, and 398 except as set forth therein, the authors retain all their rights. 400 Acknowledgment 402 Funding for the RFC Editor function is currently provided by the 403 Internet Society.