[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