Subject: [dhcwg] Proposed change to MAX_SOL_RT

From: Ralph Droms <[email-masked]>
Date: Fri, 4 Nov 2011 07:33:44 -0400

I've asked the chairs for a short slot in the Taipei WG meeting to discuss draft-droms-dhc-dhcpv6-maxsolrt-update-00.  While the doc won't officially be published until I-D publication quiet period ends, the important text of the draft is only 2 paragraphs, so I'm posting it now to encourage discussion prior to the WG meeting.

Here is text of the doc:

Abstract

  This document updates RFC 3315 by defining a new default value for
  SOL_MAX_RT.

1.  Introduction

  Section 5.5 of the DHCP specification [RFC3315] defines the default
  value of MAX_SOL_RT to be 120 seconds.  In some circumstances, this
  default will lead to an unacceptably high volume of aggregated
  traffic at a DHCPv6 server.

2.  Update to RC 3315

  This document changes section 5.5 of RFC 3315 as follows:

  OLD:
     SOL_MAX_RT      120 secs  Max Solicit timeout value

  NEW:
     SOL_MAX_RT     3600 secs  Max Solicit timeout value

  With this change, a DHCPv6 client that does not receive a
  satisfactory response will send Solicit messages with the same
  initial frequency and exponential backoff as specified in RFC 3315.
  However, the long term behavior of these DHCPv6 clients will be to
  send a Solicit message every 3600 seconds rather than every 120
  seconds, significantly reducing the aggregated traffic at the DHCPv6
  server.

  The change to MAX_SOL_RT is in response to DHCPv6 message rates
  observed at a DHCPv6 server in a deployment in which many DHCPv6
  clients are sending Solicit messages but the DHCPv6 server has been
  configured not to respond to those Solicit messages.  RFC 3315 was
  written with the expectation that the 'M' and 'O' flags in NDP
  [RFC2461] would control the use of DHCPv6 by hosts.  However, the
  current definition of the 'M' and 'O' flags in RFC 4861 [RFC4861]
  does not explicitly preclude the use of DHCPv6 by a host.  Some
  devices will initiate DHCPv6 even if RAs are received with the 'M'
  and 'O' bits set to 0.  In some circumstances, it is desirable to
  enable the assignment of IPv6 addresses through DHCPv6 to some
  nodes on a link but not to others, which cannot be implemented
  through the 'M' and 'O' bits.

Two issues to consider:

1. Is 3600 seconds the right number?  How about 7200 seconds?

2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complete the DHCPv6 message exchange after the DHCPv6 service comes back up will be MAX_SOL_RT/2.  Is that situation acceptable or should we define some other trigger through which the DHCPv6 clients can be signaled explicitly to restart the Solicit transmission algorithm in section 17.1.2 of RFC 3315.  My personal opinion is that an additional trigger is unnecessary.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 8 Nov 2011 15:22:02 -0500

Followup to previous message about changing MAX_SOL_RT...

> 2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complet…

In support of my opinion, I came up with the following analysis of the likelihood of a client getting to the long-term MAX_SOL_RT interval state. 

If the CM and CE router have been up and running, with the CE configured through DHCPv6, a WAN link flap will have no effect on DHCPv6 unless the link is down past the address/PD lease expiration...and in this case, the CE router will lose connectivity regardless.

If the CE router comes up without a valid address/PD lease before the DHCPv6 service is running, the CE router will get to the long-term state of waiting on average MAX_SOL_RT/2 only if the DHCPv6 service is down longer than MAX_SOL_RT/2.  Note that this situation will only occur if the CE router is coming up for the first time or coming up after its address/PD lease has expired.

So, a DHCPv6 client can get to that long-term state sending a Solicit every MAX_SOL_RT interval, but I don't think it's very likely.

Discussion welcome and encouraged.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Nov 2011 21:39:58 +0100

Ralph,

before we jump to conclusions and change the spec, I would very much like to understand this better.
the issue here is a DHCP server receiving SOLICITS from clients that it is unwilling to serve, right?
and that all solicits are going to be discarded, not replied to and created a binding for.

assuming a million DHCPv6 clients with a 120 second timeout that's ~8333 solicits/s.
can't a vanilla DHCP server implementation handle that? 

if a solicit packet is 150 bytes, that's only a ~12Mbps datastream...

cheers,
Ole

On Nov 4, 2011, at 12:33 , Ralph Droms wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Tue, 8 Nov 2011 15:54:02 -0500

> and that all solicits are going to be discarded, not replied to and created a binding for.

Right.

> can't a vanilla DHCP server implementation handle that? 

On the other hand, that stream of Solicits may represent a 100x increase over the level of traffic in the steady state.

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 10 Nov 2011 16:05:14 -0600

Perhaps it has been discussed (sorry if it was) ...

But another option (no pun intended) is to the have the server send back
a "SOL_MAX_RT" option to provide a client this information -- this could
be in the Advertise that says no addresses available. This does require
the server to be there and does offer a potential denial of service
attach -- but not really since it is just SOL_MAX_RT the client will
retry a number of times before using any 'bad' value.

It has the added benefit that the network operator can set the value to
what they feel is reasonable. If they aren't planning to turn things on
for 6 months, they could set it much higher than 3600.

This won't solve the issue when no DHCPv6 service is there -- then the M
& O bits are set incorrectly or the device is always doing DHCPv6.

Personally, I think both ways would be best. Though this might argue for
a lower SOL_MAX_RT than 3600 (perhaps to 600 seconds - that is 1/5th the
traffic of the 120 seconds value) and a lot less time to wait in a case
where the server(s) are down or unreachable for a bit.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms
Sent: Tuesday, November 08, 2011 3:22 PM
To: [email-masked] WG
Subject: Re: [dhcwg] Proposed change to MAX_SOL_RT

On Nov 4, 2011, at 7:33 AM 11/4/11, Ralph Droms wrote:
> 
> 2. In a scenario in which the DHCPv6 service is unresponsive for
SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every
SOL_MAX_RT, the average wait time for those clients to complete the
DHCPv6 message exchange after the DHCPv6 service comes back up will be
MAX_SOL_RT/2.  Is that situation acceptable or should we define some
other trigger through which the DHCPv6 clients can be signaled
explicitly to restart the Solicit transmission algorithm in section
17.1.2 of RFC 3315.  My personal opinion is that an additional trigger
is unnecessary.

In support of my opinion, I came up with the following analysis of the
likelihood of a client getting to the long-term MAX_SOL_RT interval
state. 

If the CM and CE router have been up and running, with the CE configured
through DHCPv6, a WAN link flap will have no effect on DHCPv6 unless the
link is down past the address/PD lease expiration...and in this case,
the CE router will lose connectivity regardless.

If the CE router comes up without a valid address/PD lease before the
DHCPv6 service is running, the CE router will get to the long-term state
of waiting on average MAX_SOL_RT/2 only if the DHCPv6 service is down
longer than MAX_SOL_RT/2.  Note that this situation will only occur if
the CE router is coming up for the first time or coming up after its
address/PD lease has expired.

So, a DHCPv6 client can get to that long-term state sending a Solicit
every MAX_SOL_RT interval, but I don't think it's very likely.

- Ralph