Subject: Re: [Dhcpv6bis] [dhcpv6bis] #119 (XML 3315): Client Rate limiting in DHCPv6?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 09 Dec 2014 07:41:44 -0000

#119: Client Rate limiting in DHCPv6?

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Add a "Rate Limiting" sub-Section with "Transmission of Messages by a
 Client" Section (Section 14).

 14.1.  Rate Limiting

    In order to avoid prolonged message bursts that may be caused by
    possible logic loops, a DHCPv6 client MUST limit the rate of DHCPv6
    messages it transmits.  One example is that a client obtains an
    address, but does not like the response; it reverts back to Solicit
    procedure, discovers the same (sole) server, requests an address and
    gets the same address as before (the server still has the lease that
    was requested just now).  This loops can repeat infinitely if there
    is not a quit/stop mechanism.  Therefore, a client must not initiate
    transmissions too frequently.

    A recommended method for implementing the rate limiting function is a
    token bucket, limiting the average rate of transmission to a certain
    number in a certain time.  It allows the long-term average is not
    exceeded.

       TRT     Transmission Rate Limit

    The Transmission Rate Limit parameter (TRT) SHOULD be configurable.
    A possible default could be 60 packets in 10 seconds.

    For a device that has multiple interfaces, the limit MUST be enforced
    on a per interface basis.

    Rate limiting of forwarded DHCPv6 messages and server-slide messages
    are out of scope of this specification.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  [email-masked]
  [email-masked]         |      Status:  closed
     Type:  task                     |   Milestone:  B moderate, apply
 Priority:  P1 blocker               |  after merge
Component:  XML 3315                 |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/119#comment:4>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 20:21:17 -0000

Comment (by [email-masked]):

 During WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09, Ted raised a
 concern there for text we copied from RFC 3315 Section 18.1.8.

 I updated the text Sheng added to the bis document a bit and also added a
 cross reference where the 'rate limiting' issue comes up in the existing
 bis document.

 Keywords:                           |    Due Date:

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/119#comment:5>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Dec 2014 22:09:50 -0500

>    A possible default could be 60 packets in 10 seconds.

This seems like a really high limit.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 24 Dec 2014 03:14:51 +0000

>-----Original Message-----
>From: Ted Lemon [mailto:[email-masked]]
>Sent: Wednesday, December 24, 2014 11:10 AM
>To: dhcpv6bis issue tracker
>

Could you give a suggestion? This was suggested by Bernie.

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Dec 2014 22:44:46 -0500

> Could you give a suggestion? This was suggested by Bernie.

That's six packets per second over ten seconds.   The highest rate a client should ever emit is something like two packets per second, at the beginning of the exponential backoff process.   I would suggest just computing the maximum number of packets that could be sent in the first ten seconds of a client configured with the default settings, and make that be the limit.  I'm pretty sure it's a lot less than sixty in the first ten seconds.

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 24 Dec 2014 04:04:52 -0000

Ted did comment that he feels the default of 60 packets in 10 seconds is
 rather high (Sheng attributed that number to me - Bernie). It was a while
 ago and I'm not sure what number I suggested back then, but 60 in 60
 (i.e., 1/second on average, with short bursts possible) is probably much
 more realistic. We could also analyze various situations to derive a more
 meaningful number (sequences such as release, solicit, (advertise with
 server pref 255) request which can happen quickly - so a burst of 3
 packets in ~ 1 second is not unreasonable -- but of course this should not
 continue for long :).

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/119#comment:6>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 24 Dec 2014 04:05:46 +0000

Ted ... helps if you can comment in the tickets directly as then your comments are tracked. I've added them.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Dec 2014 07:58:59 -0500

> Ted ... helps if you can comment in the tickets directly as then your comments are tracked. I've added them.

Yeah, saw that.   Sorry about that.   I assumed my replies would be captured, or I would have taken additional action.  :}