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 JAA16998 for ; Sun, 12 May 2002 09:55:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21172 for dhcwg-archive@odin.ietf.org; Sun, 12 May 2002 09:55:18 -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 JAA20819; Sun, 12 May 2002 09:50:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20793 for ; Sun, 12 May 2002 09:50:13 -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 JAA16698 for ; Sun, 12 May 2002 09:50:02 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4CDoBl19564 for ; Sun, 12 May 2002 08:50:11 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g4CDo1r06651 for ; Sun, 12 May 2002 08:50:11 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun May 12 08:49:35 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 08:49:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3ED@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 08:48:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F9BB.AC43CE50" 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_01C1F9BB.AC43CE50 Content-Type: text/plain; charset="iso-8859-1" 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 ------_=_NextPart_001_01C1F9BB.AC43CE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.erics= son.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 =

------_=_NextPart_001_01C1F9BB.AC43CE50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg