Internet Engineering Task Force T. Yang Internet-Draft L. Li Intended status: Standards Track Q. Ma Expires: September 6, 2012 China Mobile March 5, 2012 Mitigating aggregated traffic of DHCP discover messages draft-yang-dhc-ipv4-dis-00 Abstract This document defines a new option DIS_MAX_RT which can mitigate aggregated traffic caused by discover messages the client sends to the server. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yang, et al. Expires September 6, 2012 [Page 1] Internet-Draft IPv4-DIS March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Problems . . . . . . . . . . . . . . . . . . . . . . 3 4. DIS_MAX_RT and DIS_MAX_RT_OPTION . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Refrences . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Yang, et al. Expires September 6, 2012 [Page 2] Internet-Draft IPv4-DIS March 2012 1. Introduction In RFC2131 [RFC2131], there are no specific definitions for client's operation if the server does not respond for the discover message. In some cases, this will lead to an unacceptably high volum of aggregated traffic at a DHCPv4 server. In RFC3315 [RFC3315], SOL_MAX_RT is defined as an option of DHCPv6 message to prevent the frequently requesting of clients, which reduce the aggregated traffic. In DHCPv4, there are no corresponding IPv4 options. But the problem is that the format of DHCPv4 is different with DHCPv6. However, it is also necessary to introduce similar option in DHCPv4 to keep the consistency between DHCPv4 and DHCPv6. This document updates RFC 2131 [RFC2131] by defining a new option DIS_MAX_RT which makes the DHCPv4 server mitigating aggregated traffic of client's discover messages. 2. Requirements Language 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. Potential Problems RFC2131 [RFC2131] defines the interaction between the DHCP server and client. There are no specific discription for client's operation when the client does not receive the DHCPOFFER in response to its DHCPDISCOVER message. Most of the Operating Systems will retransmit DHCPDISCOVER message in their own ways which may cause trouble in some special scenarios. DHCP server needs to mitigate the traffic which is like DDoS attack caused by the clients when many DHCPv4 clients send discovery messages incessantly but the DHCPv4 server is configured no respond to discover messages or the IP address pool emptied. 4. DIS_MAX_RT and DIS_MAX_RT_OPTION If a DHCPv4 client does not receive a satisfactory response for the discover message, it will send discover messages with various frequency according to its OS. In our experiments, some of the most popular OS will send several discover messages every 1 or 5 minutes, and send the message endlessly. So the DHCP server needs a mechanism to mitigate the traffic. Yang, et al. Expires September 6, 2012 [Page 3] Internet-Draft IPv4-DIS March 2012 It is necessary to define uniform identification named DIS_MAX_RT for client to follow when it needs to retransmit its DHCPDISCOVER. Client retransmits its DHCPDISCOVER message in a period refer to the DIS_MAX_RT value. This parameter can be configurated by DHCP server in some circumstance such as DHCPv4 server will be configured not to respond to request messages. The default value of DIS_MAX_RT is suggested to be 3600 seconds so that keeps the consistency with [draft-droms-dhc-dhcpv6-solmaxrt-update-02]. According to the definition of DHCP option in RFC2132 [RFC2132], a new option named DIS_MAX_RT_OPTION is defined. The format of DIS_MAX_RT_OPTION is: +--------+--------+--------+--------+--------+--------+ |Code |Len | T1 | T2 | T3 | T4 | +--------+--------+--------+--------+--------+--------+ Code DIS_MAX_RT_OPTION (TBD). Len 4. T1-T4 4 octets, Overriding value for DIS_MAX_RT in seconds. Figure 1: DIS_MAX_RT_OPTION The DIS_MAX_RT_OPTION option needs IANA to assign a new Code to indicate and its length (Len value) is 4 octets. From T1 to T4, there are 4 octets space to indicate the max retransmition time period. A DHCPv4 client MUST include the DIS_MAX_RT_OPTION in any message it sends. The DHCPv4 server MAY include the DIS_MAX_RT_OPTION code in any response it sends to a client that has included the DIS_MAX_RT option code in a request message. If a DHCPv4 client receives a message containing a DIS_MAX_RT_OPTION, the client MUST set its internal DIS_MAX_RT parameter to the value contained in the DIS_MAX_RT option. As a result of receiving this option, the DHCPv4 client MUST NOT send any request messages more frequently that allowed by the retransmission mechanism defined by their OS. When a DHCPv4 server receive a DIS_MAX_RT_OPTION contained in some messages from clients, it MAY ignore the value of DIS_MAX_RT and assign a new value in the response to make the client refresh its DIS_MAX_RT. Yang, et al. Expires September 6, 2012 [Page 4] Internet-Draft IPv4-DIS March 2012 5. Security Considerations The security problem is as same as the "draft-droms-dhc-dhcpv6- solmaxrt-update-02". 6. IANA Considerations IANA is requested to assign an option code from the "DHCP Option Codes" Registry for OPTION_DIS_MAX_RT. 7. Refrences (1) RFC[2131] Dynamic Host Configuration Protocol (2) RFC[2132] DHCP Options and BOOTP Vendor Extensions (3) RFC[3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (4) "draft-droms-dhc-dhcpv6-solmaxrt-update-02" Modification to Default Value of SOL_MAX_RT 8. Acknowledgement Thanks for the authors of "draft-droms-dhc-dhcpv6-solmaxrt-update-02" and the contributions from Lianyuan Li. Authors' Addresses Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: yangtianle@chinamobile.com Yang, et al. Expires September 6, 2012 [Page 5] Internet-Draft IPv4-DIS March 2012 Li Lianyuan China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: lilianyuan@chinamobile.com Qiongfang Ma China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: maqiongfang@chinamobile.com Yang, et al. Expires September 6, 2012 [Page 6]