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