Network Working Group S. Daniel Park Internet-Draft SAMSUNG Electronics Expires: July 28, 2006 Y. Ohba Toshiba J. Jee ETRI January 27, 2006 DHCPv4 Option for Discovering IEEE 802.21 Information Service Location draft-daniel-dhc-mihis-opt-00.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 July 28, 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 July 28, 2006 [Page 1] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 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 July 28, 2006 [Page 2] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 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 current proposal is focusing on an IP address of an Information Park, et al. Expires July 28, 2006 [Page 3] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 2006 Service (IS) server. However, the following different types of options related to IS can be configured using DHCP. - An FQDN of an IS server - An URI of a schema. Also, there can be multiple IP addresses, FQDNs or URLs to be configurable using DHCP. So each type of options can carry a list instead of just one element. 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 below; 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 (in case of single IS server). The option has three encodings, specified by the encoding byte ('enc') that follows the code byte. if the encoding byte has the value 0, it is followed by a list of IP address of IS server. if the encoding byte has the value 1, it is followed by a list of FQDN of IS server. if the encoding byte has the value 2, it is followed by a list of URI of schema. Implementor can choose any specific option for discovering MIIS location based on its environment. 3.1.1 IS Server IPv4 Address List 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_IS | Len | enc | IS Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address List . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IS (TBD) Park, et al. Expires July 28, 2006 [Page 4] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 2006 option-length: Number of octets following the 'option-length' field, including the encoding byte in octets enc: Encoding byte set to 0. IS Server IPv4 Address List: IPv4 address of a IS server. The IS servers are listed in the order of preference. This option contains one or more IPv4 addresses of IS servers. Each IPv4 address is 4 octets in length. 3.1.2 IS Server FQDN List 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_IS | Len | enc | IS Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FQDN List . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IS (TBD) option-length: Number of octets following the 'option-length' field, including the encoding byte in octets, variable. enc: Encoding byte set to 1. IS Server FQDN List: FQDN of a IS server. This option contains one or more FQDNs of IS servers. Each FQDN is encoded according to Section 3.1 of [RFC1035]. 3.1.3 IS Server Schema URI List 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_IS | Len | enc | IS Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Schema URI List . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Park, et al. Expires July 28, 2006 [Page 5] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 2006 option-code: OPTION_IS (TBD) option-length: Number of octets following the 'option-length' field, including the encoding byte in octets, variable. enc: Encoding byte set to 2. IS Server Schema URI List: URI a IS server. This option contains one or more URIs of 802.21 Information Service Schemas where the resource represented by each URI is the Basic Schema or an Extended Schema [ieee80221]. Each URI is encoded as a one octet length field followed by that number of octets. To simplify implementations, the total length of a URI is restricted to 255 octets or less. 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. 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. Park, et al. Expires July 28, 2006 [Page 6] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 2006 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. 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 July 28, 2006 [Page 7] Internet-Draft DHCPv4 Option for Accessing IEEE 802.21 ISJanuary 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 July 28, 2006 [Page 8]