15. Reliability of Client-Initiated Message Exchanges

This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.

Original RFC Text

15.  Reliability of Client-Initiated Message Exchanges

   DHCP clients are responsible for reliable delivery of messages in the
   client-initiated message exchanges described in Section 18.  If a
   DHCP client fails to receive an expected response from a server, the
   client must retransmit its message according to the retransmission
   strategy described below.

   Note that the procedure described in this section is slightly
   modified when used with the Solicit message.  The modified procedure
   is described in Section 18.2.1.

   The client begins the message exchange by transmitting a message to
   the server.  The message exchange terminates when either (1) the
   client successfully receives the appropriate response or responses
   from a server or servers or (2) the message exchange is considered to
   have failed according to the retransmission mechanism described
   below.

   The client MUST update an "elapsed-time" value within an Elapsed Time
   option (see Section 21.9) in the retransmitted message.  In some
   cases, the client may also need to modify values in IA Address
   options (see Section 21.6) or IA Prefix options (see Section 21.22)
   if a valid lifetime for any of the client's leases expires before
   retransmission.  Thus, whenever this document refers to a
   "retransmission" of a client's message, it refers to both modifying
   the original message and sending this new message instance to the
   server.

   The client retransmission behavior is controlled and described by the
   following variables:

   RT:    Retransmission timeout

   IRT:   Initial retransmission time

   MRC:   Maximum retransmission count

   MRT:   Maximum retransmission time

   MRD:   Maximum retransmission duration

   RAND:  Randomization factor

   Specific values for each of these parameters relevant to the various
   messages are given in the subsections of Section 18.2, using values
   defined in Table 1 in Section 7.6.  The algorithm for RAND is common
   across all message transmissions.

   With each message transmission or retransmission, the client sets RT
   according to the rules given below.  If RT expires before the message
   exchange terminates, the client recomputes RT and retransmits the
   message.

   Each of the computations of a new RT includes a randomization factor
   (RAND), which is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is included to
   minimize synchronization of messages transmitted by DHCP clients.

   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation of the DHCP client.

   RT for the first message transmission is based on IRT:

      RT = IRT + RAND*IRT

   RT for each subsequent message transmission is based on the previous
   value of RT:

      RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

      if (RT > MRT)
         RT = MRT + RAND*MRT

   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.

   MRD specifies an upper bound on the length of time a client may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.

   If both MRC and MRD are non-zero, the message exchange fails whenever
   either of the conditions specified in the previous two paragraphs is
   met.

   If both MRC and MRD are zero, the client continues to transmit the
   message until it receives a response.

   A client is not expected to listen for a response during the entire
   RT period and may turn off listening capabilities after waiting at
   least the shorter of RT and MAX_WAIT_TIME due to power consumption
   saving or other reasons.  Of course, a client MUST listen for a
   Reconfigure if it has negotiated for its use with the server.