Mitigating aggregated traffic of DHCP discover messages
draft-yang-dhc-ipv4-dis-00

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]