[dhcwg] Edit #2 of DHCP spec

Narten:

  > 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.

Response: Changed the second sentence as follows:

***************
*** 1923,1932 ****
     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 IPv6 Neighbor Discovery causes the client to
!    invoke the stateful address autoconfiguration protocol (see section
!    5.5.3 of RFC2462).  This random delay desynchronizes clients which
!    start at the same time (for example, after a power outage).

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg