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

"Bound, Jim" <Jim.Bound@hp.com> Mon, 13 May 2002 02:18 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 WAA10787 for <dhcwg-archive@odin.ietf.org>; Sun, 12 May 2002 22:18:00 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22289 for dhcwg-archive@odin.ietf.org; Sun, 12 May 2002 22:18:12 -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 WAA22153; Sun, 12 May 2002 22:15:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22128 for <dhcwg@optimus.ietf.org>; Sun, 12 May 2002 22:15:51 -0400 (EDT)
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10722 for <dhcwg@ietf.org>; Sun, 12 May 2002 22:15:38 -0400 (EDT)
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 580F18BE0; Sun, 12 May 2002 22:15:49 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:15:49 -0400
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC
Date: Sun, 12 May 2002 22:15:48 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B2@tayexc13.americas.cpqcorp.net>
Thread-Topic: [dhcwg] dhcpv6-24: randomization delay before invoking DHC
Thread-Index: AcH5u/bNGSexKgScT6WGgT+pnVJTOgAZ+7fg
From: "Bound, Jim" <Jim.Bound@hp.com>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Ralph Droms <rdroms@cisco.com>, dhcwg@ietf.org
X-OriginalArrivalTime: 13 May 2002 02:15:49.0481 (UTC) FILETIME=[19639D90:01C1FA24]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22129
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
Content-Transfer-Encoding: 8bit

Bernie,

Thomas sent the ND paragraph.  When reboot set to default and default is stateless ND.

Please use ascii text.

thanks
/jim

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Sunday, May 12, 2002 9:48 AM
To: Bound, Jim; Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC


Jim: 
Yes, the flag can change from TRUE to FALSE, but the issue is when does stateful configuration stop (sorry I didn't state that more clearly last time):
   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. 
So, once DHCP starts, this kind of implies that it never stops until a reboot of the system occurs. 
In -24 (17.1.2) we also have: 
   A DHCP client SHOULD choose MRC and MRD to be 0.  If the DHCP client 
   is configured with either MRC or MRD set to a value other than 
   0, it MUST stop trying to configure the interface if the message 
   exchange fails.  After the DHCP client stops trying to configure the 
   interface, it SHOULD choose to restart the reconfiguration process 
   after some external event, such as user input, system restart, or 
   when the client is attached to a new link. 
So, if a client follows the SHOULD it would keep running the process. 
I guess one could assume that the client should stop transmitting Solicits if the ManagedFlag is false. 
- Bernie 
-----Original Message----- 
From: Bound, Jim [mailto:Jim.Bound@hp.com] 
Sent: Sunday, May 12, 2002 12:58 AM 
To: Bernie Volz (EUD); Ralph Droms; dhcwg@ietf.org 
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC 


Bernie, 
It could be reset by RA to FALSE fyi. 
/jim 
-----Original Message----- 
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] 
Sent: Wednesday, May 08, 2002 9:45 PM 
To: 'Ralph Droms'; dhcwg@ietf.org 
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC 


Yes, that is my assumption - that the host has to wait for an RA. The Stateless Autoconfiguration RFC doesn't state this explicitly and also doesn't cover the case of a moving client (at least that I could find). It seems to me that if a host follows that specification, once the ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via a reboot of the host.
There always is the possibility that a host's policy could force the ManagedFlag to be TRUE always? Though why you'd want to do this is not clear to me.
-----Original Message----- 
From: Ralph Droms [mailto:rdroms@cisco.com] 
Sent: Wednesday, May 08, 2002 7:38 PM 
To: dhcwg@ietf.org 
Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC 


Thomas comment (below) raised a question in my mind.  Is the state of the 
managedFlag always go to FALSE or is it maintained across systems 
restarts?  That is, does a host always come up in stateless mode and then 
switch to stateful upon receipt of the first RA.  If the client does always 
come up in stateless mode, does the following text cause the first Solicit 
to be delayed until at least the receipt of the first RA? 
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). 


At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: 
>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 


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

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