Network working group X. Xu Internet Draft D. Guo Category: Standard Track D. Zhang Expires: February 2011 Huawei Technologies August 4, 2010 IPv6 Router Advertisement Option for Stateless DHCP Server draft-xu-ipv6-ra-dhcp-server-option-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 February 4, 2011. 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 February 4, 2011 [Page 1] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 Abstract This document proposes a new Router Advertisement option which allows IPv6 hosts to obtain the addresses of stateless DHCP servers. 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. Terminology..................................................3 2. Motivations..................................................3 3. RA Option for Stateless DHCP Server..........................4 4. DHCPv6 Extensions............................................5 5. Security Considerations......................................5 6. IANA Considerations..........................................5 7. Acknowledgements.............................................6 8. References...................................................6 8.1. Normative References....................................6 8.2. Informative References..................................6 Authors' Addresses..............................................6 Xu, et al. Expires February 4, 2011 [Page 2] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 1. Terminology This document uses the terminology defined in Stateless Address Autoconfiguration [RFC2462], DHCPv6 specification [RFC3315] and Stateless DHCPv6 [RFC3736]. 2. Motivations 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). According to [RFC3736], the DHCP client needs to 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 the 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. With this approach, the latencies imposed by relay agents can be eliminated and the clients do not have to receive redundant responses from multiple DHCP servers. This will also eliminate any potential impacts brought by multicast traffic on the network performance. 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. Moreover, Cryptographically Generated Address (CGA) is proposed to be used by DHCP servers to avoid the Man in the Middle (MiTM) attacks. A precondition of using CGA to avoid DHCP server spoofing is DHCP clients already know their intended DHCP servers in advance. Otherwise, a rogue DHCP server could easily generate a legitimate CGA by using its own public key. 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. 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. From the operational perspective, this approach is analogous to the DNS usage that a DNS Xu, et al. Expires February 4, 2011 [Page 3] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 client obtains the address of a DNS server and uses unicast to perform DNS resolution. 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. 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. Xu, et al. Expires February 4, 2011 [Page 4] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 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. 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. With the approach mentioned above, attackers can bypass DHCP relay agents and send flooding traffic directly to DHCPv6 servers. However, since the stateless DHCP server doesn't need to maintain dynamic states for individual clients, such flooding attack on DHCP Servers will not be worse than the attack on DNS servers. In some special scenarios where DHCP clients are required to access DHCP servers through DHCP relay agents, the proposed RA option can convey the IP addresses of DHCP relay agents rather than the addresses of DHCP 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. Xu, et al. Expires February 4, 2011 [Page 5] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 7. Acknowledgements Thanks to Dujuan Gu for her valuable input about rogue DHCP server problems. Thanks SHOULD also be given to Mohamed Boucadair for his reviews. 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, Xu, et al. Expires February 4, 2011 [Page 6] Internet-Draft IPv6 RA Option for Stateless DHCP Server August 2010 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