[dhcwg] Edit #2 of DHCP spec
Ralph Droms <rdroms@cisco.com> Tue, 14 May 2002 20:09 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04214 for <dhcwg-archive@odin.ietf.org>; Tue, 14 May 2002 16:09:28 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19570 for dhcwg-archive@odin.ietf.org; Tue, 14 May 2002 16:09:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19084; Tue, 14 May 2002 16:07:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19056 for <dhcwg@ns.ietf.org>; Tue, 14 May 2002 16:07:01 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04040 for <dhcwg@ietf.org>; Tue, 14 May 2002 16:06:47 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EK6THt027140 for <dhcwg@ietf.org>; Tue, 14 May 2002 13:06:30 -0700 (PDT)
Date: Tue, 14 May 2002 16:06:29 -0400
From: Ralph Droms <rdroms@cisco.com>
To: dhcwg@ietf.org
Message-ID: <Pine.GSO.4.44.0205141602330.28862-100000@funnel.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [dhcwg] Edit #2 of DHCP spec
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
Narten: > 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. Response: Changed the second sentence as follows: *************** *** 1923,1932 **** 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 IPv6 Neighbor Discovery causes the client to ! invoke the stateful address autoconfiguration protocol (see section ! 5.5.3 of RFC2462). This random delay desynchronizes clients which ! start at the same time (for example, after a power outage). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Edit #2 of DHCP spec Ralph Droms