One document matched: draft-yang-dhc-ipv4-dis-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:31 |