[dhcwg] dhcpv6-24: randomization delay before invoking DHC

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:08 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11085 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:08:26 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04215 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:08:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03150; Wed, 8 May 2002 11:00:08 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03116 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:00:06 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10670 for <dhcwg@ietf.org>; Wed, 8 May 2002 10:59:57 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com []) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F0364067254 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:00:05 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F02Q210200 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:00:02 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F0Qw19144 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:00:26 -0400
Message-Id: <200205081500.g48F0Qw19144@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:00:26 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> 17.1.2. Transmission of Solicit Messages
>    The first Solicit message from the client on the interface MUST
>    be delayed by a random amount of time between MIN_SOL_DELAY and
>    MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP
>    is initiated by IPv6 Neighbor Discovery, the delay gives the amount
>    of time to wait after the ManagedFlag changes from FALSE to TRUE (see
>    section 5.5.3 of RFC2462).  This random delay desynchronizes clients
>    which start at the same time (for example, after a power outage).

Hmm. I see a couple of potential problems here. First, we have to be
careful about tying this to the change of the value from FALSE to
TRUE. Consider a misconfiguration, where there are two routers, and
one sends out RAs with the bit set to 0, the other router sets it to
1. This will result in a flip-flop with every RA. Do we really want to
restart DHC everytime that happens?

A better approach might be to say, if the managed bit changes from
FALSE to TRUE, *and* the client isn't currently already using DHC on
that interface, then start the process. note: if the flag changes from
true to false, does the client drop all its DHC-learned stuff and
issue a release?  There is no text that suggests this be done, and I
don't think we want to do this. 

Also, the delay should be tied to receipt of the first RA that says
use DHC. On a power outage, all the clients will get the first RA at
the same time. This is the issue where having a random delay would
seem to be most important.


dhcwg mailing list