MIP6 Working Group Hee Jin Jang Internet-Draft Alper Yegin Expires: June 22, 2007 JinHyeock Choi SAMSUNG AIT Kuntal Chowdhury Starent Networks December 19, 2006 DHCP Option for Home Information Discovery in MIPv6 draft-ietf-mip6-hiopt-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Jang, et al. Expires June 22, 2007 [Page 1] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 Abstract This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DHCP options for HA Dynamic Discovery . . . . . . . . . . . . 5 3.1. Home Network Identifier Option . . . . . . . . . . . . . . 5 3.2. Home Network Information Option . . . . . . . . . . . . . 7 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. DHCP Server - Home Agent Relation . . . . . . . . . . . . 10 4.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 10 4.3. DHCP Server Considerations . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Jang, et al. Expires June 22, 2007 [Page 2] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 1. Introduction Before a mobile node can engage in Mobile IPv6 signaling with a home agent, it should either know the IP address of the home agent via preconfiguration, or dynamically discover it. Mobile IPv6 specification [2] describes how home agents can be dynamically discovered by mobile nodes that know the home subnet prefix. This scheme does not work when prefix information is not already available to the mobile node. This problem can be solved by delivering one or more home subnet prefix information to the mobile node by means of DHCP. Subsequently, the mobile node can engage in dynamic home agent discovery using the prefix information. In addition to delivering the prefix information, DHCP can also be used to provide the IP addresses or FQDNs of the home agents that are available to the mobile node and the home address that the mobile node can use to register with the home agent. The solution involves defining new DHCP options to carry home subnet prefix, home agent IP address, home agent's FQDN information, and home address of the mobile node. A similar solution has already been defined for Mobile IPv4 home agents [3]. As part of configuring the initial TCP/IP parameters, a mobile node can obtain home network information for the subnet it is directly attached to, other subnets in the visited domain, or a subnet from its home domain. A mobile node can convey the target home subnet's identity in order to receive corresponding information. For example the mobile node can provide realm portion of its user NAI (Network Access Identifier) and expect that a home network information from its home domain is returned. The availability of the requested information depends on the DHCP server having prior knowledge or dynamically discovering it. While the specific details are outside the scope of this document, use of static tables and AAA-assisted discovery are possible options [8]. The mobile node may or may not be connected to the "home" subnet when it attempts to learn Mobile IPv6 home network information. This allows operators to centrally deploy home agents while being able to bootstrap mobile nodes that are already roaming. This scenario also occurs when HMIP [7] is used, where the mobile node is required to discover the MAP (a special home agent) that is located multiple hops away from the mobile node's attachment point. Jang, et al. Expires June 22, 2007 [Page 3] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Most of terms used in this draft are defined in Mobile IPv6 [2] and RFC3315 [4]. Jang, et al. Expires June 22, 2007 [Page 4] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 3. DHCP options for HA Dynamic Discovery This section introduces two DHCP options used for dynamic home agent discovery in Mobile IPv6. 3.1. Home Network Identifier Option This option is used to carry the identifier of the target home network. This identification allows mobile node to request information for a home subnet within the visited domain, or from a specific domain. It is assumed that the DHCP server has some mechanism to know or retrieve the requested Mobile IPv6 information such as [9]. The specifics of these mechanisms are outside the scope of this draft. The mobile node MUST include this option along with its Option Request option in its request. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_HNId | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id-type |A| reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Home Network Identifier . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Network Identifier Option Format option-code OPTION_HNId (TBD) option-len Total length of the option id-type The type of Home Network Identifier: Jang, et al. Expires June 22, 2007 [Page 5] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 0 Visited (local) domain 1 Home domain 2 No preference A flag A flag to specify whether the client requests a home address or not. reserved 7-bit field reserved for future use. The value MUST be initialized to 0 by the sender, and MUST be ignored by the receiver. Home Network Identifier The identifier to specify the requested home network of the mobile node Id-type 0 indicates the mobile node is interested in learning the home network information that pertains to the immediately connected (visited) network. In that case, Home Network Identifier field is not used. This type can be used to discover local home agents in a visited network. Id-type 1 indicates the format of Home Network Identifier field is a network realm as defined in [5]. In this case, the mobile node is interested in learning home network information that pertains to the given realm. This type can be used to discover home agents that are hosted by a user's home domain (as indicated by his/her NAI-based username -- user@HomeRealm). If the mobile node has no preference, the id-type is set to 2. In this case, the assignment of the home network information is within the server's own discretion. If 'A' flag is set in this option, the server should assign a home address to the client in the returned Home Network Information option. Otherwise, the server should not assign a home address option. Jang, et al. Expires June 22, 2007 [Page 6] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 3.2. Home Network Information Option This option is used to carry home network information to a mobile node in the form of one or more of home subnet prefix(es), home agent address(es), home agent FQDN(s), and mobile node's home address. The server MUST provide all of the matching home subnet prefix(es), home agent address(es) or FQDN(s) in a Home Network Information option. If the server has no information to provide, it MUST set the option-len field to zero in this option. If the client set the 'A' flag in Home Network Identifier option, it MUST provide an available home address to a client. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_HNInf | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hninfo-type | hninfo-len |V| reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Home Network Information . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Network Information Option Format option-code OPTION_HNInf (TBD) option-len Total length of the option hninfo-type The type of the following Home Network Information field. Possible values are: 0 Home subnet prefix 1 Complete IPv6 address of the home agent Jang, et al. Expires June 22, 2007 [Page 7] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 2 FQDN of the home agent 3 IPv6 Home address hninfo-len 8-bit unsigned integer. Total length of the following Home Network Information field. V flag This flag specifies whether the home network information is assigned from the visited network or not. reserved 7-bit field reserved for future use. The value MUST be initialized to 0 by the sender, and MUST be ignored by the receiver. Home Network Information A home subnet prefix, home agent IP address, FQDN and home address to be assigned to a mobile node. When the hninfo-type is set to 0, the data field MUST contain the 8-bit prefix length information followed by the 128-bit IPv6 address beginning with the available network prefix. When the hninfo-type is set to 1, the data field MUST contain the 128-bit IPv6 address of the home agent. When the hninfo-type is set to 2, the data field MUST contain the FQDN as described in RFC1035 [6]. When the hninfo-type is set to 3, the data field MUST contain the 8-bit reserved field, the 8-bit prefix length field of the following home address, the 32-bit lifetime of the following home address and the 128-bit home address to be assigned to a client. The lifetime is expressed in units of seconds. The home address, or hninfo-type = 3, should be included if and only if the client sets A flag in Home Network Identifier option. Setting the lifetime to 0xffffffff ("infinity") means a permanent assignment of an address to the client. The lifetime of the assigned home Jang, et al. Expires June 22, 2007 [Page 8] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 address should not be longer than the lifetime of its prefix since the home address cannot survive the prefix lifetime. If the id-type is set to 0 in the Home Network Identifier option, the server should reply with the available home agent(es) or home address information in the visited network and set the 'V' flag in the Home Network Information option. If the id-type is set to 1, the server should return that information in the specified home network in Home Network Identifier field in the request option. In this case, the 'V' flag in Home Network Information option is set to 0. If the id-type is set to 2, the DHCP server replies with the home network information either from the home or from the visited network according to its policy or the home agent availability. The 'V' flag in the Home Network Information option is set to 0 or 1 accordingly. Single option can carry multiple information preceded by hninfo-type and hninfo-len fields. The length fields help identify the information boundaries. Jang, et al. Expires June 22, 2007 [Page 9] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 4. Option Usage The requesting and sending of this option follows the rules for DHCP options in [4]. 4.1. DHCP Server - Home Agent Relation The DHCP server does not have to be co-located with a home agent, or even be on the home subnet of the mobile node. Its location with respect to home network does not matter as long as it possesses the requested information. 4.2. Mobile Node Considerations When a Mobile IPv6 mobile node finds itself with neither a home subnet prefix/home address nor a home agent address, it may request the needed information with Option Request option. For instance, a mobile node connecting to a network for the first time may acquire a DHCP address and solicit for home network information at the same time. When a mobile node requests home network information form the DHCP server, it MUST clarify the preference of the requested home network with id-type in the request option. If it has interest only in the currently visited network, it MUST set the id-type to 0. If the mobile node has interest in the other specific network, it MUST identify the target network with Home Network Identifier option. For example, a DHCP server may have information about home agents from several domains (and subnets). Even when the mobile node does not care about the location of the home network where the home agent to be assigned, it MUST clarify the fact by setting the id-type to 3. In this case, the assignment of the home network information is based on the server's local policy. When the mobile node gets more than one home agent address, it MUST have a selection mechanism to determine which one to use for establishing a Mobile IPv6 session. In case it retrieves only home subnet prefix(es), it needs to perform dynamic home agent discovery to learn the IP addresses of the home agents. Similarly, if FQDN of a home agent is retrieved, the mobile node can use DNS to resolve it to IPv6 address(es) of the home agents. If the mobile node receives both IPv6 address(es) and FQDN(s) of the home agents, it SHALL use the IPv6 information of the home agents. When the mobile node requests and receives the home address information from the DHCP server, it SHALL use it to perform Mobile IPv6 home registration. For detailed mobile node behavior, refer to section 3.6 of [9]. When the mobile node sends a Binding Update message to home agent by Jang, et al. Expires June 22, 2007 [Page 10] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 using the home address which is assigned in Home Network Information option, the requested lifetime in Binding Update message MUST not be shorter than the lifetime of the home address. Since the home address 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 the home address specified with the Binding Update. 4.3. DHCP Server Considerations It is assumed that the DHCP server has access to home network information for its clients for this option to be useful. The DHCP server can rely on pre-configuration, or some dynamic discovery mechanisms for obtaining this information. In case it does not have any information, or it cannot locate matching information based on Home Network Identifier, it returns a Home Network Information option with 0-length data. The DHCP server can either return the IPv6 address(es) of home agent or the FQDN(s) of home agents. It is not required for the DHCP server to return both. The DHCP server SHOULD have its own policy so that it can reply with the proper information in case a mobile node indicates no preference of the home network. The policy can be determined based on several factors such as the home agent availability and the authorization information of the mobile node. However, the specific policy setting is not in the scope of this document. When a DHCP server assigns a home address to an mobile node, it should guarantee that the lifetime of assigned home address MUST NOT be greater than that of the subnet prefix in the mobile node's home address. The lifetimes of the home addresses for assignments are can be negotiated when the home prefix is delivered from the home agent, or configured by DHCP administrator's policy. The details are outside the scope of this document. Jang, et al. Expires June 22, 2007 [Page 11] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 5. Security Considerations Secure delivery of home agent, home address, and home link information from a DHCP server to the mobile node (DHCP client) relies on the overall DHCP security. The particular option defined in this draft does not have additional impact on the DHCP security. Aside from the DHCP client to server interaction, an operator must also ensure secure delivery of mobile IP information to the DHCP server. This is outside the scope of DHCP and the newly defined option. Jang, et al. Expires June 22, 2007 [Page 12] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 6. IANA Consideration This document introduces two new DHCPv6 options, Home Agent Request option and Home Agent Reply option. The type numbers for new DHCP options are currently TBD. An appropriate request will be made to IANA if this Internet draft gets accepted as an RFC. Jang, et al. Expires June 22, 2007 [Page 13] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 7. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents", draft-ietf-dhc-mipadvert-opt-02 (work in progress), February 2004. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [6] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [7] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. [8] Chowdhury, K., "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-01 (work in progress), October 2006. [9] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in progress), June 2006. Jang, et al. Expires June 22, 2007 [Page 14] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 Authors' Addresses Hee Jin Jang Samsung Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea Email: heejin.jang@samsung.com Alper E. Yegin Samsung Advanced Institute of Technology Istanbul Turkey Email: alper01.yegin@partner.samsung.com JinHyeok Choi Samsung Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea Email: athene@sait.samsung.co.kr Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Email: kchowdhury@starentnetworks.com Jang, et al. Expires June 22, 2007 [Page 15] Internet-Draft DHCP Opt for Home Info Discovery in MIPv6 December 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jang, et al. Expires June 22, 2007 [Page 16]