Network Working Group S. Daniel Park Internet-Draft SAMSUNG Electronics Expires: August 7, 2006 Y. Ohba Toshiba J. Jee ETRI February 6, 2006 DHCPv4 Option for Discovering IEEE 802.21 Information Service Location draft-daniel-dhc-mihis-opt-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 August 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract In IEEE 802 Standard, the Media Independent Handover (MIH) Services are under work through IEEE 802.21 Working Group. It is consist of three services, Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). This document provides a mechanism by which the DHCP Park, et al. Expires August 7, 2006 [Page 1] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 can provide information about the MIIS Location. 1. Introduction In IEEE 802 Standard, the Media Independent Handover Services are under work through IEEE 802.21 Working Group. It is consist of three services, Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). MIIS provides a framework by which a MIH function both in the mobile node and in the network can discover and obtain homogeneous and heterogeneous network information within a geographical area to facilitate handovers. In the larger scope, the macro objective is to acquire a global view of the heterogeneous networks to facilitate seamless handovers when roaming across these networks. MIIS includes support for various Information Elements (IEs). IEs provide information that is essential for a handover module to make intelligent handover decision. Figure 1 gives a high level description of scenario that distinguish between two different types of mobility as Horizontal Handovers and Vertical Handovers. Media Specific Media Independent Information Service Technology +------------+ +----------------------------------+ | | ^ | | | +--------+ | | | +-------+ +--------+ | | | GSM | | | | | BSTN 1| . . . . | BSTN x | | | +--------+ | V | +-------+ +--------+ | | . | e | . | | . | r | . | | . | t | +-------+ +-------+ | | +--------+ | i | | BS 1 | . . . . | BS y | | | | 802.16 | | c | +-------+ +-------+ | | +--------+ | a | | | | l | ------------+-----+ | | | / /-----| GNI | | +--------+ | H | +------+ +------+ +------+ | +-----+ | | 802.11 | | O | | AP 1 | | AP 2 | . . | AP z | | | LLI | | +--------+ | s | +------+ +------+ +------+ | +-----+ | | | | | | HLSI| +------------+ +----------------------------------+ +-----+ ---Horizontal HOs----------------> Park, et al. Expires August 7, 2006 [Page 2] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 Depending on the type of mobility support for different types of information elements may be necessary for performing handovers. MIIS provides the capability for obtaining the necessary information for handovers. This includes information about lower layers such as neighbor maps and other link layer parameters as well as information about available higher layer services such as access to internet connectivity, availability of VPN services, etc. The set of different higher services privided by the MIIS may constantly evolve. At the same time, the list of access networks that are supported by MIIS may also evolve. During the IEEE 802.21 meeting, DHCP was considered as a candidate mechanism to discover an MIIS location that can help mobile terminals and network entities in selection of appropriate networks during handovers. A schema defines structure of information. A schema is used in the 802.21 information service to define the structure of each information element as well as the relationship among different information elements supported. The MIIS schema is classified into two major categories. - Basic schema that is essential for every MIH to support and - Extended schema that is optional and can be vendor specific This document defines a new DHCPv4 option as MIIS Location Discovery Option for discovering MIIS information. Similar options will be defined for DHCPv6 in either this document or a seperated one. 2. Requirements 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]. 3. MIIS Location Discovery Option This option specifies the MIIS Location Discovery that client should use when discovering the handover information of MIIS somehow via the Dynamic Host Configuration Protocol [RFC2131]. The new option is organized as a single DHCPv4 option that contains Park, et al. Expires August 7, 2006 [Page 3] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 one or more "sub-options". So far, three sub-options are newly defined for MIIS Location Discovery such as IS Server IPv4 Address sub-option, IS Server FQDN sub-option and IS Server Schema URI suboption. IS Server IPv4 Address sub-option is the most preferable for discovering MIIS location. The usage of others sub-options are up to network administrator. The following different types of options related to IS can be configured using DHCP. - An FQDN of an IS server (IS Server FQDN sub-option) - An URI of a schema (IS Server Schema URI sub-option) Also, there can be multiple IP addresses or FQDNs to be configurable using DHCP. So each type of options can carry a list instead of just one element. In URI cases, the Basic Schema is pre-configured on the client, and one URI of the Extended Schema is used for MIIS location discovery whenever necessary. So multiple URIs are not needed. This document is only defining new DHCPv4 options at this stage. New DHCPv6 options will be defined in either this document or a separated one. 3.1 Overall format for DHCPv4 Option The DHCPv4 format of the MIIS Location Discovery Option is shown as follows; Code Len MIIS Location Discovery Field +------+------+------+------+------+------+--...-+------+ | TBD | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The code for this option is TBD. The length of this option depends on which type of information is used for discovering the IS server. The MIIS Location Discovery Field consists of a sequence of SubOpt- Length-Value tuples for each sub-option. The code of sub-options are as follows; Sub-option = 1 IS Server IPv4 Address Option Sub-option = 2 IS Server FQDN Option Park, et al. Expires August 7, 2006 [Page 4] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 Sub-option = 3 IS Server Schema URI Option 3.1.1 IS Server IPv4 Address Sub-Option SubOpt Len IS Server IPv4 Address List +------+------+------+------+------+------+----- | 1 | N | a1 | a2 | a3 | a4 |. . . +------+------+------+------+------+------+----- The IS Server IPv4 Address Option contains an IPv4 address of a IS server. In a single IS Server IPv4 Address case, the length is 4. if multiple addresses are in use, the IS servers are listed in the order of preference. 3.1.2 IS Server FQDN Sub-Option SubOpt Len IS Server FQDN List +------+------+------+------+------+------+----- | 1 | N | b1 | b2 | b3 | b4 |. . . +------+------+------+------+------+------+----- The IS Server FQDN Option contains a FQDN of a IS server. This option contatins one or more FQDNs of IS servers. Each FQDN is encoded according to Section 3.2 of [RFC1035]. The option-length field includes the encoding byte in octets, variable. 3.1.3 IS Server Schema URI Sub-Option SubOpt Len IS Server Schema URI +------+------+------------------------------+ | 1 | N | IS Server Schema URI | +------+------+------------------------------+ The IS Server Schema URI Option contains one URI of IEEE 802.21 Information Service Schema where the resource represented by the URI is an Extended Schema [ieee80221]. In general, the Basic Schema is Park, et al. Expires August 7, 2006 [Page 5] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 pre-configured on the client. The length of option is variables. 4. Security Considerations A rouge DHCP server can issue invalid or incorrect MIIS location. This may cause denial of service due to unreachability or makes the client to reach incorrect destination. In case of DHCPv4, the authenticated DHCP [RFC3118] can be also used for secure exchange between clients and MIIS locations. In case of DHCPv6, the security considerations are described in Section 23 of [RFC3315]. 5. IANA Considerations IANA is requested to an assign value for the MIIS Location Discovery Option code in accordance with [RFC2939]. 6. DHCPv6 Considerations DHCPv6 options should be newly defined to discover MIIS location [RFC3315]. 7. Acknowledgements Thanks to IEEE 802.21 folks for their effort on this issue. Specially thanks to David Hankins of ISC for sub-option suggestion. 8. No I-D References All references cited in this section MUST be added into the Informative References before publishing it officially. [ieee80221] IEEE P802.21/D00/04, Draft IEEE standard for Local and Metropolitan Area Networks: Media Independent Handover Services. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. Park, et al. Expires August 7, 2006 [Page 6] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 9.2 Informative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Authors' Addresses Soohong Daniel Park Mobile Convergence Laboratory, SAMSUNG Electronics Phone: EMail: soohong.park@samsung.com Yoshihiro Ohba Toshiba Phone: EMail: yohba@tari.toshiba.com Junghoon Jee ETRI Phone: EMail: jhjee@etri.re.kr Park, et al. Expires August 7, 2006 [Page 7] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 IS February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Park, et al. Expires August 7, 2006 [Page 8]