[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