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

[Ralph Droms <[e-mail]>]

So, in this text from section 5.2 of RFC2462, we should assume "starts out" 
means "every time the system restarts/reboots"; a host does not retain the 
previous state of ManagedFlag across a restart:

       ManagedFlag      Copied from the M flag field (i.e., the
                        "managed address configuration" flag) of the most
                        recently received Router Advertisement message.
                        The flag indicates whether or not addresses are
                        to be configured using the stateful
                        autoconfiguration mechanism. It starts out in a
                        FALSE state.

Given that assumption, this text from section 5.5.3 of RFC2462 implies that 
a client waits for the first RA to change ManagedFlag from FALSE to TRUE:

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.

Going back to Thomas' initial comment about the following sentence:

     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)

I believe that the problem can be fixed be rewriting the sentence in 
question as:

     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 IPv6 Neighbor Discvoery causes the client to
     invoke the stateful address autoconfiguration protocol (see
     section 5.5.3 of RFC2462).

That is, I think RFC2462 defines the times at which the client begins the 
DHCP process by sending a Solicit.  The DHCP spec can then define the 
randomization to be applied to that starting time.

- Ralph

At 08:44 PM 5/8/2002 -0500, Bernie Volz (EUD) wrote:

>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:[e-mail]>mailto:[e-mail]]
>Sent: Wednesday, May 08, 2002 7:38 PM
>To: [e-mail]
>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
> >[e-mail]
> ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailm 
> an/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg