Internet Engineering Task force Subir Das Internet Draft Telcordia Technologies Intended Status: Proposed Standard Gabor Bajko Expires: Jan 11, 2010 Nokia July 12, 2009 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Access Network Discovery and Selection Function(ANDSF) Discovery draft-das-mipshop-andsf-dhcp-options-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 11, 2010. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list IP addresses and a list of domain names that can be mapped to ANDSF (Access Network S Das & G. Bajko Expires 01/11/10 [Page 1] ANDSF DHCP Options July 2009 Discovery and Selection Function) entities in an IP network. ANDSF is being developed in 3GPP (Release-8) and provides inter-system mobility policies and access network specific information to the mobile nodes(MNs) [3GPPTS23.402]. Table of Contents 1. Introduction .................................................2 2. ANDSF IPv4 address option for DHCPv4..........................3 3. ANDSF Domain Name List option for DHCPv4......................4 4. ANDSF IPv6 address option for DHCPv6..........................5 5. ANDSF Domain Name List option for DHCPv6......................6 6. Option Usage..................................................7 6.1 Usage of ANDSF Options for DHCPv4.......................7 6.2 Usage of ANDSF Options for DHCPv6.......................7 7. Security Considerations ......................................8 8. IANA Considerations ..........................................8 9. Acknowledgements .............................................9 10. References ..................................................9 10.1 Normative References ...................................9 10.2 Informative References ................................10 Author's Addresses .............................................10 (1) Conventions used in this document 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 RFC-2119. (2) Terminology and abbreviations used in this document ANDSF (Access Network Discovery and Selection Function): An entity that contains data management and control functionality and provides necessary network discovery and selection assistance data to the user entity (UE) as per operator policy [3GPP TS 23.402]. Access Network: A network that is accessed by the user entity(UE) 3GPP Network : Third Generation Partnership Project specified network Non-3GPP Network: Network that is not specified by 3GPP network (e.g., CDMA network) 1. Introduction Access Network Discovery and Selection Function (ANDSF) is being defined in 3GPP (Release-8) to provide necessary network discovery and selection assistance data to the mobile nodes for multi-access S. Das & G. Bajko Expires 01/11/10 [Page 2] ANDSF DHCP Options July 2009 network scenarios where 3GPP access-network level solutions are not sufficient for the mobile nodes to perform network discovery and selection of non-3GPP networks[3GPPTS23.402]. The information provided by ANDSF contains inter-system mobility policies and access network specific data to assist the mobile node with performing the inter-system handover. This set of information can either be provisioned in the mobile node by the home operator, or provided to the mobile node (MN) by the ANDSF over the S14 reference point as defined in [3GPPTS23.402]. In 3GPP release-8, the ANDSF is located in the subscriber's home operator network and needs to be known to the MN or discovered by the MN. According to [3GPPTS23.402] the ANDSF is discovered through interaction with the Domain Name Service function or the DHCP Server function. This document defines new DHCPv4 and DHCPv6 options called the ANDSF IP Address Option and ANDSF Domain List Option, which allow the MN to locate an ANDSF Server that hosts the desired service as required by 3GPP. 2. ANDSF IPv4 Address Option for DHCPv4 This section describes the ANDSF IPv4 Address Option for DHCPv4. The Option begins with an option code followed by a length and one or more IP addresses. The value of the length octet does not include itself or the option code. The option layout is depicted below: 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 Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv4_Address-ANDSF(To Be Assigned) - 1 byte Length An 8-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields S. Das & G. Bajko Expires 01/11/10 [Page 3] ANDSF DHCP Options July 2009 IP Address IPv4 address(es) of ANDSF Server(s) When the total length of an ANDSF IPv4 Address Option exceeds 254 octets, the procedure outlined in [RFC3396] MUST be employed to split the option into multiple, smaller options. If the length is followed by a list of IPv4 addresses indicating appropriate ANDSF servers available to the MN, servers MUST be listed in order of preference and the client should process them in decreasing order of preference. In case there is no ANDSF server available, the length is set to 0, otherwise it is a multiple of 4. The Option has the following format: Code Len IPv4 Address 1 IPv4 Address 2 +-----+----+----+----+----+----+----+----+---- | XX | n |a1 | a2 | a3 | a4 | a1 | ... +-----+----+----+----+----+----+----+----+---- 3. ANDSF Domain Name List Option for DHCPv4 This section describes the ANDSF Domain Name List Option for DHCPv4. The general format of this option is depicted below: 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 Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name List | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv4_FQDN-ANDSF (To Be Assigned) - 1 byte Length An 8-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields Domain Name List FQDN(s) of ANDSF Server When the total length of an ANDSF Domain Name List Option exceeds 254 octets, the procedure outlined in [RFC3396] MUST be employed to split the option into multiple, smaller options. S. Das & G. Bajko Expires 01/11/10 [Page 4] ANDSF DHCP Options July 2009 The encoding for this option has the following format: Code Len DNS name of ANDSF server +-----+----+----+----+----+----+----+---- | XX | n | s1 | s2 | s3 | s4 | s5 | ... +-----+----+----+----+----+----+----+---- The Option begins with a code followed by a length and a sequence of labels that are encoded according to Section 8 of [RFC3315]. When the MN discovers one or more FQDNs, it SHALL resolve those according to the procedures as specified in [RFC1035]. The list of domains MAY contain the domain name of the ANDSF servers of the network provider and its partner networks that also offer ANDSF capabilities. As an example, consider the case where the server wants to offer two ANDSF servers, "example.com" and "example.net". These would be encoded as follows: +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | XX |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+ 4. ANDSF IPv6 Address option for DHCPv6 This section describes the ANDSF IPv6 Address Option for DHCPv6. The Option begins with an option code followed by a length and one or more IP addresses. The value of the length octet does not include itself or the option code. The option layout is depicted below: 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 Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv6_Address-ANDSF (To Be Assigned) - 2 bytes S. Das & G. Bajko Expires 01/11/10 [Page 5] ANDSF DHCP Options July 2009 Length A 16-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields. IP Address IPv6 address(es) of ANDSF Server(s) The Option follows the same format (except the Option Code and Length value) as described in Section 2. The value of the Option Code and Length are 2-octets and the Length does not include itself or the Option Code field. If the length is followed by a list of IPv6 addresses indicating appropriate ANDSF servers available to the MN, servers MUST be listed in order of preference and the client should process them in decreasing order of preference. In case there is no ANDSF server available, the length is set to 0, otherwise it is a multiple of 16. 5. ANDSF Domain Name List option for DHCPv6 This section describes the ANDSF Domain List Option for DHCPv6. The general format of this option is depicted below: 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 Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name List | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv6_FQDN-ANDSF(To Be Assigned) - 2 bytes Length A 16-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields. Domain Name List FQDN(s) of ANDSF Server S. Das & G. Bajko Expires 01/11/10 [Page 6] ANDSF DHCP Options July 2009 The Option follows the same format (except the Option Code and Length value) as described in Section 3. The value of the Option Code and Length are 2-octets and the Length does not include itself or the Option Code field. The semantics and content of the DHCPv6 encoding of this option are exactly the same as the encoding described in Section 3, except the Option Code and Length value. 6. Option Usage 6.1 Usage of ANDSF Options for DHCPv4 The requesting and sending of the proposed DHCPv4 options follow the rules for DHCP options in [RFC2131]. 6.1.1 Mobile Node behavior The mobile node may perform an ANDSF discovery procedure either during initial association with a network or when the policy and access network information is required from ANDSF. It may also try to perform the ANDSF discovery when the network information is outdated or mobile does not have any ANDSF information. MN SHOULD always query for the IP address, unless the operator policy requires to discover the FQDN, in which case the MN will need to request for the domain name. In order to request an address or domain name of a ANDSF Server, the mobile node(DHCP client) MUST include either an ANDSF IPv4 Address Option or ANDSF Domain Name List Option for DHCPv4 in the respective DHCP messages as defined in [RFC2131]. 6.1.2 DHCP Server behavior When the DHCP server receives either an ANDSF IPv4 Address Option or ANDSF Domain Name List Option for DHCPv4, the DHCP server MUST always construct the response messages (as defined in [RFC2131]) that may contain a list of one or more IP addresses or a list of one or more FQDNs of the ANDSF server hosting the service. In case that the server cannot find any ANDSF Server satisfying the requested Option Code, the server MUST return the ANDSF Option by setting the Option Code to the requested Option Code and the length of the Option to 0. . S. Das & G. Bajko Expires 01/11/10 [Page 7] ANDSF DHCP Options July 2009 6.2 Usage of ANDSF Options for DHCPv6 The requesting and sending of the proposed DHCPv6 options follow the rules for DHCP options in [RFC3315]. 6.2.1 Mobile node behavior The mobile node may perform an ANDSF discovery procedure either during initial association with a network or when the policy and access network information is required from ANDSF. It may also try to perform the ANDSF discovery when the network information is outdated or mobile does not have any ANDSF information. MN SHOULD always query for the IP address, unless the operator policy requires to discover the FQDN, in which case the MN will need to request for the domain name. In order to discover the address or domain name of an ANDSF Server, the mobile node(DHCP client) MUST include either an ANDSF IPv6 Address Option or ANDSF Domain Name List Option for DHCPv6 in the respective DHCP messages as defined in [RFC3315]. 6.2.2 DHCP Server behavior When the DHCP Server receives either an ANDSF IPv6 Address Option or ANDSF Domain Name List Option, the DHCP server MUST always construct the response (as defined in [RFC3315])that may contain a list of one or more IP addresses or a list of one or more FQDNs of the ANDSF server hosting the service. In case that the server cannot find any ANDSF Server satisfying the requested Option Code, the server MUST return the ANDSF Option by setting the Option Code to the requested Option Code and the length of the Option to 0. 7. Security Considerations The security considerations in [RFC2131] apply. If an adversary manages to modify the response from a DHCP server or insert its own response, an MN could be led to contact a rogue ANDSF Server. It is recommended to use DHCP authentication option described in [RFC3118] where available. This will also protect the denial of service attacks to DHCP servers. [RFC3118] provides mechanisms for both entity authentication and message authentication. S. Das & G. Bajko Expires 01/11/10 [Page 8] ANDSF DHCP Options July 2009 In deployments where DHCP authentication is not available, 3GPP specific lower layer security services may be sufficient to protect DHCP messages. Regarding domain name resolution, it is recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641]. 8. IANA Considerations This document defines two new DHCPv4 options as described in Sections 2 and 3. ANDSF IPv4 Address Option for DHCPv4(OPTION-IPv4_Address-ANDSF) TBA ANDSF Domain Name List option for DHCPv4(OPTION-IPv4_FQDN-ANDSF) TBA This document also defines two DHCPv6 options as described in Sections 4 and 5. ANDSF IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-ANDSF) TBA ANDSF Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-ANDSF) TBA 9. Acknowledgements Authors would like to acknowledge the following individuals for their valuable comments. Patrick Stuper, Vijay Devarapalli, Jari Arkko, 10. References 10.1 Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Droms et al, July 2003 S. Das & G. Bajko Expires 01/11/10 [Page 9] ANDSF DHCP Options July 2009 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", RFC3396, November 2002. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. 10.2 Informative References [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. [3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm 3GPP TS 23.402 V8.6.0 (2009-06): Architecture enhancements for non-3GPP accesses (Release 8) [3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm 3GPP TS 24.302 V8.2.0 (2009-06): Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3;(Release 8) Authors' Addresses Subir Das Telcordia Technologies Inc. e-mail: subir(at)research(dot)Telcordia(dot)com Gabor Bajko Nokia e-mail: gabor(dot)bajko(at)nokia(dot)com S. Das & G. Bajko Expires 01/11/10 [Page 10]