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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 May 2002 10:58:47 -0500

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:[email-masked]]
Sent: Wednesday, May 08, 2002 11:00 AM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 00:57:36 -0400

Bernie,

It could be reset by RA to FALSE fyi.

/jim

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 9:45 PM
To: 'Ralph Droms'; [email-masked]
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:[email-masked]] 
Sent: Wednesday, May 08, 2002 7:38 PM 
To: [email-masked] 
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).

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 00:57:37 -0400

Exactly.
/jim

> Sent: Thursday, May 09, 2002 8:08 AM
> To: Ralph Droms
> Cc: [email-masked]
> Ralph Droms <[email-masked]> writes:
> 
> > 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?
> 
> My take. When a node reboots, the first thing it *always* does is
> solicit an RA. When it gets the response RA, it has new information
> that overrides the old information. So the old information isn't
> relevant. That information either says invoke DHC or don't.
> 
> If it *doesn't* get an RA, that implies there are no routers. But the
> ND (or addrconf?) spec already says that if there are no routers, then
> you invoke stateful.
> 
> So I think no special words are needed, reasonable behavior is already
> defined elsewhere.
> 
> Thomas
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 00:57:33 -0400

Most implementation always comes up stateless fyi.

/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 12 May 2002 08:48:18 -0500

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:[email-masked]]
Sent: Sunday, May 12, 2002 12:58 AM
To: Bernie Volz (EUD); Ralph Droms; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC

Bernie,

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 22:15:48 -0400

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:[email-masked]]
Sent: Sunday, May 12, 2002 9:48 AM
To: Bound, Jim; Ralph Droms; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC

Jim: 
-----Original Message----- 
From: Bound, Jim [mailto:[email-masked]] 
Sent: Sunday, May 12, 2002 12:58 AM 
To: Bernie Volz (EUD); Ralph Droms; [email-masked] 
Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC 

Bernie,