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

From: Thomas Narten <[email-masked]>
Date: Wed, 08 May 2002 11:00:26 -0400

> 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: Ralph Droms <[email-masked]>
Date: Wed, 08 May 2002 19:38:17 -0400

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?

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 08:08:08 -0400

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