Network working group X. Xu Internet Draft D. Guo Category: Standard Track D. Zhang Expires: August 2010 Huawei Technologies February 5, 2010 IPv6 Router Advertisement Option for Stateless DHCP Server draft-xu-ipv6-ra-dhcp-server-option-00 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 Auguest 5, 2010. Copyright 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Xu, et al. Expires August 5, 2010 [Page 1] Internet-Draft IPv6 RA Option for Stateless DHCP Server February 2010 Abstract This document proposes a new Router Advertisement option which allows IPv6 hosts to obtain the addresses of stateless DHCP servers automatically. Thus,IPv6 hosts can directly contact stateless DHCP servers using unicast. 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 [RFC2119]. Table of Contents 1. Terminologies................................................3 2. Introduction.................................................3 3. RA Option for Stateless DHCP Server..........................3 4. DHCPv6 Extensions............................................5 5. Security Considerations......................................5 6. IANA Considerations..........................................5 7. Acknowledgements.............................................5 8. References...................................................6 8.1. Normative References....................................6 8.2. Informative References..................................6 Authors' Addresses..............................................6 Xu, et al. Expires August 5, 2010 [Page 2] Internet-Draft IPv6 RA Option for Stateless DHCP Server February 2010 1. Terminologies This document uses the terminology defined in Stateless Address Autoconfiguration[RFC2460], DHCPv6 specification[RFC3315] and Stateless DHCP[RFC3736]. 2. Introduction After obtaining IPv6 addresses through some other mechanisms such as Stateless Address Autoconfiguration[RFC2462] or manual configuration, IPv6 hosts can attempt to use stateless DHCP[RFC3736] to obtain other configuration information (e.g., DNS recursive name servers). To achieve this, the DHCP client first sends an Information-Request message to the All_DHCP_Relay_Agents_and_Servers multicast address. DHCP servers receiving the Information-Request message then respond with a Reply message containing the desired configuration information. If the DHCP client and DHCP servers are not located in a same broadcast domain, the traffic between the client and the DHCP servers need to be relayed by DHCP Relay Agents. If the client can obtain the address of a stateless DHCP server from someplace in advance, it can directly send Information-Request messages to the DHCP server. This approach can eliminate the latencies imposed by relay agents and prevent the client from receiving redundant responses from multiple DHCP servers. Additionally, unicast messages are more difficult to intercept than multicast messages. Therefore, if a client uses unicast to contact DHCP servers, the security issues caused by rogue DHCP server can be mitigated to some extent. Of course, this benefit is based on the presumption that the rogue IPv6 Router Advertisement problem [I- D.draft-ietf-v6ops-rogue-ra-00] has been solved successfully. The document introduces a new Router Advertisement option called the Stateless DHCP Server option which contains the IP addresses of stateless DHCP servers. After obtaining the address of a stateless DHCP server from this RA option, a client can use unicast to directly communicate with the server. 3. RA Option for Stateless DHCP Server A Stateless DHCP Server option contains at least one stateless DHCP server address. If there are multiple addresses, all of them share a same lifetime value. If different lifetime values are desired, the IP addresses can be encapsulated within different options. Figure 1 shows the format of the Stateless DHCP Server option. Xu, et al. Expires August 5, 2010 [Page 3] Internet-Draft IPv6 RA Option for Stateless DHCP Server February 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Addresses of Stateless DHCP Servers : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Stateless DHCP Server Option Format Fields: Type 8-bit identifier of the Stateless DHCP Server option type to be assigned by the IANA; Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The minimum value is 3 if one IPv6 address is contained in the option. Every additional DHCP Server address increases the length by 2. The Length field is used by the receiver to determine the number of IPv6 addresses in the option. Lifetime 32-bit unsigned integer. The maximum time, in seconds (relative to the time the packet is sent), over which this DHCP Server address MAY be used for obtaining configuration information. Hosts MAY send a Router Solicitation to ensure the DHCP Sever information is fresh before the interval expires. Addresses of Stateless DHCP Servers One or more 128-bit IPv6 addresses of the stateless DHCP servers. The number of the addresses can be derived from the value of the Length field. Specifically, the number of addresses is equal to (Length - 1) / 2. Xu, et al. Expires August 5, 2010 [Page 4] Internet-Draft IPv6 RA Option for Stateless DHCP Server February 2010 4. DHCPv6 Extensions After obtaining the address of a DHCP server from the Stateless DHCP Server option, a client COULD send an information-Request message directly to the DHCP server via unicast. In [RFC3315], we found the following statement: "A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address." We believe that the designers of DHCPv6 assumed that clients have no knowledge about the IP addresses of DHCP servers at the time they send Information- request messages. Therefore, if a DHCP server receives an Information-request message with a unicast destination address, it will regard it as an abnormal message. However, in the scenarios where clients can get the IP addresses of DHCP servers from someplace else, this assumption is invalid anymore. Therefore, we argue that a stateless DHCP server should accept an Information- request messages it receives with a unicast destination address. 5. Security Considerations In practice, DHCP relay agents can be used to slower or damp the frequency of attacks on the DHCP servers. However, when using our solution, attackers can get the IP addresses of DHCPv6 servers in advance, and so they can bypass replay agents and send flooding traffic to DHCPv6 servers directly. Regarding this issue, we argue that since the stateless DHCP server doesn't need to maintain any dynamic state for individual clients, this kind of flooding attack on the DHCP Servers will not be worse than the attacks on DNS servers. 6. IANA Considerations The IANA should assign an IPV6 Neighbor Discovery option for the Option defined in this document in the "IPv6 Neighbor Discovery Option Formats" registry. 7. Acknowledgements Thanks to Dujuan Gu for her valuable input about rogue DHCP server problems. Xu, et al. Expires August 5, 2010 [Page 5] Internet-Draft IPv6 RA Option for Stateless DHCP Server February 2010 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC3115] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC2462] Thomson, S. and T. Narten., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [I-D.draft-ietf-v6ops-rogue-ra-00] T. Chown and S. Venaas., "Rogue IPv6 Router Advertisement Problem Statement", draft-ietf- v6ops-rogue-ra-00 (work in progress),May 2009. Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82836073 Email: xuxh@huawei.com Dayong Guo Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: 86-10-82836077 Email: guoseu@huawei.com Dacheng Zhang Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: 86-10-82836072 Email: zhangdacheng@huawei.com