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 MAA14484 for ; Wed, 8 May 2002 12:04:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10531 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:04:39 -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 LAA09019; Wed, 8 May 2002 11:59:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09003 for ; Wed, 8 May 2002 11:59:53 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14244 for ; Wed, 8 May 2002 11:59:46 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48Fxql14496 for ; Wed, 8 May 2002 10:59:52 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48FxqE21588 for ; Wed, 8 May 2002 10:59:52 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 08 10:58:58 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 10:58:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Wed, 8 May 2002 10:58:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6A9.3D1AFF90" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F6A9.3D1AFF90 Content-Type: text/plain; charset="iso-8859-1" This issue on the flip-flop of the ManagedFlag is already addressed in RFC 2462: 5.5.3. Router Advertisement Processing On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, i.e., the change in the value of the ManagedFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. So, it shouldn't need to be restated in the DHCP specification? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:00 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC > 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. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6A9.3D1AFF90 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC

This issue on the flip-flop of the ManagedFlag is already addressed in RFC 2462:

5.5.3.  Router Advertisement Processing

   On receipt of a valid Router Advertisement (as defined in
   [DISCOVERY]), a host copies the value of the advertisement's M bit
   into ManagedFlag. If the value of ManagedFlag changes from FALSE to
   TRUE, and the host is not already running the stateful address
   autoconfiguration protocol, the host should invoke the stateful
   address autoconfiguration protocol, requesting both address
   information and other information.  If the value of the ManagedFlag
   changes from TRUE to FALSE, the host should continue running the
   stateful address autoconfiguration, i.e., the change in the value of
   the ManagedFlag has no effect.  If the value of the flag stays
   unchanged, no special action takes place. In particular, a host MUST
   NOT reinvoke stateful address configuration if it is already
   participating in the stateful protocol as a result of an earlier
   advertisement.

So, it shouldn't need to be restated in the DHCP specification?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:00 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC


> 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.

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1F6A9.3D1AFF90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg