18.2.5.  Creation and Transmission of Rebind Messages

   At time T2 (which will only be reached if the server to which the
   Renew message was sent starting at time T1 has not responded), the
   client initiates a Rebind/Reply message exchange with any available
   server.

   A Rebind is also used to verify delegated prefix bindings but with
   different retransmission parameters as described in Section 18.2.3.

   The client constructs the Rebind message as described in
   Section 18.2.4, with the following differences:

   -  The client sets the "msg-type" field to REBIND.

   -  The client does not include the Server Identifier option (see
      Section 21.3) in the Rebind message.

   The client transmits the message according to Section 15, using the
   following parameters:

      IRT     REB_TIMEOUT

      MRT     REB_MAX_RT

      MRC     0

      MRD     Remaining time until valid lifetimes of all leases in all
              IAs have expired

   If all leases for an IA have expired, the client may choose to
   include this IA in subsequent Rebind messages to indicate that the
   client is interested in assignment of the leases to this IA.

   The message exchange is terminated when the valid lifetimes of all
   leases across all IAs have expired, at which time the client uses the
   Solicit message to locate a new DHCP server and sends a Request for
   the expired IAs to the new server.  If the terminated Rebind exchange
   was initiated as a result of receiving a Reconfigure message, the
   client ignores and discards the Reconfigure message.

18.2.6.  Creation and Transmission of Information-request Messages

   The client uses an Information-request message to obtain
   configuration information without having addresses and/or delegated
   prefixes assigned to it.

   The client sets the "msg-type" field to INFORMATION-REQUEST.  The
   client generates a transaction ID and inserts this value in the
   "transaction-id" field.

   The client SHOULD include a Client Identifier option (see
   Section 21.2) to identify itself to the server (however, see
   Section 4.3.1 of [RFC7844] for reasons why a client may not want to
   include this option).  If the client does not include a Client
   Identifier option, the server will not be able to return any
   client-specific options to the client, or the server may choose not
   to respond to the message at all.

   The client MUST include an Elapsed Time option (see Section 21.9) to
   indicate how long the client has been trying to complete the current
   DHCP message exchange.

   The client MUST include an Option Request option (see Section 21.7)
   to request the INF_MAX_RT option (see Section 21.25), the Information
   Refresh Time option (see Section 21.23), and any other options the
   client is interested in receiving.  The client MAY include options
   with data values as hints to the server about parameter values the
   client would like to have returned.

   When responding to a Reconfigure, the client includes a Server
   Identifier option (see Section 21.3) with the identifier from the
   Reconfigure message to which the client is responding.

   The first Information-request message from the client on the
   interface MUST be delayed by a random amount of time between 0 and
   INF_MAX_DELAY.  The client transmits the message according to
   Section 15, using the following parameters:

      IRT     INF_TIMEOUT

      MRT     INF_MAX_RT

      MRC     0

      MRD     0

18.2.7.  Creation and Transmission of Release Messages

   To release one or more leases, a client sends a Release message to
   the server.

   The client sets the "msg-type" field to RELEASE.  The client
   generates a transaction ID and places this value in the
   "transaction-id" field.

   The client places the identifier of the server that allocated the
   lease(s) in a Server Identifier option (see Section 21.3).

   The client MUST include a Client Identifier option (see Section 21.2)
   to identify itself to the server.

   The client MUST include an Elapsed Time option (see Section 21.9) to
   indicate how long the client has been trying to complete the current
   DHCP message exchange.

   The client includes options containing the IAs for the leases it is
   releasing in the "options" field.  The leases to be released MUST be
   included in the IAs.  Any leases for the IAs the client wishes to
   continue to use MUST NOT be added to the IAs.

   The client MUST stop using all of the leases being released before
   the client begins the Release message exchange process.  For an
   address, this means the address MUST have been removed from the
   interface.  For a delegated prefix, this means the prefix MUST have
   been advertised with a Preferred Lifetime and a Valid Lifetime of 0
   in a Router Advertisement message as described in part (e) of
   Section 5.5.3 of [RFC4862]; also see requirement L-13 in Section 4.3
   of [RFC7084].

   The client MUST NOT use any of the addresses it is releasing as the
   source address in the Release message or in any subsequently
   transmitted message.

   Because Release messages may be lost, the client should retransmit
   the Release if no Reply is received.  However, there are scenarios
   where the client may not wish to wait for the normal retransmission
   timeout before giving up (e.g., on power down).  Implementations
   SHOULD retransmit one or more times but MAY choose to terminate the
   retransmission procedure early.

   The client transmits the message according to Section 15, using the
   following parameters:

      IRT     REL_TIMEOUT

      MRT     0

      MRC     REL_MAX_RC

      MRD     0

   If leases are released but the Reply from a DHCP server is lost, the
   client will retransmit the Release message, and the server may
   respond with a Reply indicating a status of NoBinding.  Therefore,
   the client does not treat a Reply message with a status of NoBinding
   in a Release message exchange as if it indicates an error.

   Note that if the client fails to release the lease, each lease
   assigned to the IA will be reclaimed by the server when the valid
   lifetime of that lease expires.

18.2.8.  Creation and Transmission of Decline Messages

   If a client detects that one or more addresses assigned to it by a
   server are already in use by another node, the client sends a Decline
   message to the server to inform it that the address is suspect.

   The Decline message is not used in prefix delegation; thus, the
   client MUST NOT include IA_PD options (see Section 21.21) in the
   Decline message.

   The client sets the "msg-type" field to DECLINE.  The client
   generates a transaction ID and places this value in the
   "transaction-id" field.

   The client places the identifier of the server that allocated the
   address(es) in a Server Identifier option (see Section 21.3).

   The client MUST include a Client Identifier option (see Section 21.2)
   to identify itself to the server.

   The client MUST include an Elapsed Time option (see Section 21.9) to
   indicate how long the client has been trying to complete the current
   DHCP message exchange.

   The client includes options containing the IAs for the addresses it
   is declining in the "options" field.  The addresses to be declined
   MUST be included in the IAs.  Any addresses for the IAs the client
   wishes to continue to use should not be added to the IAs.

   The client MUST NOT use any of the addresses it is declining as the
   source address in the Decline message or in any subsequently
   transmitted message.

   The client transmits the message according to Section 15, using the
   following parameters:

      IRT     DEC_TIMEOUT

      MRT     0

      MRC     DEC_MAX_RC

      MRD     0

   If addresses are declined but the Reply from a DHCP server is lost,
   the client will retransmit the Decline message, and the server may
   respond with a Reply indicating a status of NoBinding.  Therefore,
   the client does not treat a Reply message with a status of NoBinding
   in a Decline message exchange as if it indicates an error.

   The client SHOULD NOT send a Release message for other bindings it
   may have received just because it sent a Decline message.  The client
   SHOULD retain the non-conflicting bindings.  The client SHOULD treat
   the failure to acquire a binding (due to the conflict) as equivalent
   to not having received the binding, insofar as how it behaves when
   sending Renew and Rebind messages.

18.2.9.  Receipt of Advertise Messages

   Upon receipt of one or more valid Advertise messages, the client
   selects one or more Advertise messages based upon the following
   criteria.

   -  Those Advertise messages with the highest server preference value
      SHOULD be preferred over all other Advertise messages.  The client
      MAY choose a less preferred server if that server has a better set
      of advertised parameters, such as the available set of IAs, as
      well as the set of other configuration options advertised.

   -  Within a group of Advertise messages with the same server
      preference value, a client MAY select those servers whose
      Advertise messages advertise information of interest to the
      client.

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as the server
   preference value, addresses advertised, when the advertisement was
   received, and so on.

   In practice, this means that the client will maintain independent
   per-IA state machines for each selected server.

   If the client needs to select an alternate server in the case that a
   chosen server does not respond, the client chooses the next server
   according to the criteria given above.

   The client MUST process any SOL_MAX_RT option (see Section 21.24) and
   INF_MAX_RT option (see Section 21.25) present in an Advertise
   message, even if the message contains a Status Code option (see
   Section 21.13) indicating a failure, and the Advertise message will
   be discarded by the client.  A client SHOULD only update its
   SOL_MAX_RT and INF_MAX_RT values if all received Advertise messages
   that contained the corresponding option specified the same value;
   otherwise, it should use the default value (see Section 7.6).

   The client MUST ignore any Advertise message that contains no
   addresses (IA Address options (see Section 21.6) encapsulated in
   IA_NA options (see Section 21.4) or IA_TA options (see Section 21.5))
   and no delegated prefixes (IA Prefix options (see Section 21.22)
   encapsulated in IA_PD options (see Section 21.21)), with the
   exception that the client:

   -  MUST process an included SOL_MAX_RT option and

   -  MUST process an included INF_MAX_RT option.

   A client can record in an activity log or display to the user any
   associated status message(s).

   The client ignoring an Advertise message MUST NOT restart the Solicit
   retransmission timer.

18.2.10.  Receipt of Reply Messages

   Upon the receipt of a valid Reply message in response to a Solicit
   with a Rapid Commit option (see Section 21.14), Request, Confirm,
   Renew, Rebind, or Information-request message, the client extracts
   the top-level Status Code option (see Section 21.13) if present.

   The client MUST process any SOL_MAX_RT option (see Section 21.24) and
   INF_MAX_RT option (see Section 21.25) present in a Reply message,
   even if the message contains a Status Code option indicating a
   failure.

   If the client receives a Reply message with a status code of
   UnspecFail, the server is indicating that it was unable to process
   the client's message due to an unspecified failure condition.  If the
   client retransmits the original message to the same server to retry
   the desired operation, the client MUST limit the rate at which it
   retransmits the message and limit the duration of the time during
   which it retransmits the message (see Section 14.1).

   If the client receives a Reply message with a status code of
   UseMulticast, the client records the receipt of the message and sends
   subsequent messages to the server through the interface on which the
   message was received using multicast.  The client resends the
   original message using multicast.

   Otherwise (no status code or another status code), the client
   processes the Reply as described below based on the original message
   for which the Reply was received.

   The client MAY choose to report any status code or message from the
   Status Code option in the Reply message.

   When a client received a configuration option in an earlier Reply and
   then sends a Renew, Rebind, or Information-request and the requested
   option is not present in the Reply, the client SHOULD stop using the
   previously received configuration information.  In other words, the
   client should behave as if it never received this configuration
   option and return to the relevant default state.  If there is no
   viable way to stop using the received configuration information, the
   values received/configured from the option MAY persist if there are
   no other sources for that data and they have no external impact.  For

   example, a client that previously received a Client FQDN option (see
   [RFC4704]) and used it to set up its hostname is allowed to continue
   using it if there is no reasonable way for a node to unset its
   hostname and it has no external impact.  As a counter-example, a
   client that previously received an NTP server address from the DHCP
   server and does not receive it anymore MUST stop using the configured
   NTP server address.  The client SHOULD be open to other sources of
   the same configuration information.  This behavior does not apply to
   any IA options, as their processing is described in detail in the
   next section.

   When a client receives a requested option that has an updated value
   from what was previously received, the client SHOULD make use of that
   updated value as soon as possible for its configuration information.

18.2.10.1.  Reply for Solicit (with Rapid Commit), Request, Renew, or
            Rebind

   If the client receives a NotOnLink status from the server in response
   to a Solicit (with a Rapid Commit option; see Section 21.14) or a
   Request, the client can either reissue the message without specifying
   any addresses or restart the DHCP server discovery process (see
   Section 18).

   If the Reply was received in response to a Solicit (with a Rapid
   Commit option), Request, Renew, or Rebind message, the client updates
   the information it has recorded about IAs from the IA options
   contained in the Reply message:

   -  Calculate T1 and T2 times (based on T1 and T2 values sent in the
      packet and the packet reception time), if appropriate for the
      IA type.

   -  Add any new leases in the IA option to the IA as recorded by the
      client.

   -  Update lifetimes for any leases in the IA option that the client
      already has recorded in the IA.

   -  Discard any leases from the IA, as recorded by the client, that
      have a valid lifetime of 0 in the IA Address or IA Prefix option.

   -  Leave unchanged any information about leases the client has
      recorded in the IA but that were not included in the IA from the
      server.

   If the client can operate with the addresses and/or prefixes obtained
   from the server:

   -  The client uses the addresses, delegated prefixes, and other
      information from any IAs that do not contain a Status Code option
      with the NoAddrsAvail or NoPrefixAvail status code.  The client
      MAY include the IAs for which it received the NoAddrsAvail or
      NoPrefixAvail status code, with no addresses or prefixes, in
      subsequent Renew and Rebind messages sent to the server, to retry
      obtaining the addresses or prefixes for these IAs.

   -  The client MUST perform duplicate address detection as per
      Section 5.4 of [RFC4862], which does list some exceptions, on each
      of the received addresses in any IAs on which it has not performed
      duplicate address detection during processing of any of the
      previous Reply messages from the server.  The client performs the
      duplicate address detection before using the received addresses
      for any traffic.  If any of the addresses are found to be in use
      on the link, the client sends a Decline message to the server for
      those addresses as described in Section 18.2.8.

   -  For each assigned address that does not have any associated
      reachability information (see the definition of "on-link" in
      Section 2.1 of [RFC4861]), in order to avoid the problems
      described in [RFC4943], the client MUST NOT assume that any
      addresses are reachable on-link as a result of receiving an IA_NA
      or IA_TA.  Addresses obtained from an IA_NA or IA_TA MUST NOT be
      used to form an implicit prefix with a length other than 128.

   -  For each delegated prefix, the client assigns a subnet to each of
      the links to which the associated interfaces are attached.

      When a client subnets a delegated prefix, it must assign
      additional bits to the prefix to generate unique, longer prefixes.
      For example, if the client in Figure 1 were delegated
      2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and
      2001:db8:0:2::/64 for assignment to the two links in the
      subscriber network.  If the client were delegated 2001:db8:0::/48
      and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and
      2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and
      2001:db8:5:2::/64 for assignment to the other link.

      If the client uses a delegated prefix to configure addresses on
      interfaces on itself or other nodes behind it, the preferred and
      valid lifetimes of those addresses MUST be no longer than the
      remaining preferred and valid lifetimes, respectively, for the
      delegated prefix at any time.  In particular, if the delegated

      prefix or a prefix derived from it is advertised for stateless
      address autoconfiguration [RFC4862], the advertised preferred and
      valid lifetimes MUST NOT exceed the corresponding remaining
      lifetimes of the delegated prefix.

   Management of the specific configuration information is detailed in
   the definition of each option in Section 21.

   If the Reply message contains any IAs but the client finds no usable
   addresses and/or delegated prefixes in any of these IAs, the client
   may either try another server (perhaps restarting the DHCP server
   discovery process) or use the Information-request message to obtain
   other configuration information only.

   When the client receives a Reply message in response to a Renew or
   Rebind message, the client:

   -  Sends a Request message to the server that responded if any of the
      IAs in the Reply message contain the NoBinding status code.  The
      client places IA options in this message for all IAs.  The client
      continues to use other bindings for which the server did not
      return an error.

   -  Sends a Renew/Rebind if any of the IAs are not in the Reply
      message, but as this likely indicates that the server that
      responded does not support that IA type, sending immediately is
      unlikely to produce a different result.  Therefore, the client
      MUST rate-limit its transmissions (see Section 14.1) and MAY just
      wait for the normal retransmission time (as if the Reply message
      had not been received).  The client continues to use other
      bindings for which the server did return information.

   -  Otherwise accepts the information in the IA.

   Whenever a client restarts the DHCP server discovery process or
   selects an alternate server as described in Section 18.2.9, the
   client SHOULD stop using all the addresses and delegated prefixes for
   which it has bindings and try to obtain all required leases from the
   new server.  This facilitates the client using a single state machine
   for all bindings.

18.2.10.2.  Reply for Release and Decline

   When the client receives a valid Reply message in response to a
   Release message, the client considers the Release event completed,
   regardless of the Status Code option (see Section 21.13) returned by
   the server.

   When the client receives a valid Reply message in response to a
   Decline message, the client considers the Decline event completed,
   regardless of the Status Code option(s) returned by the server.

18.2.10.3.  Reply for Confirm

   If the client receives any Reply messages that indicate a status of
   Success (explicit or implicit), the client can use the addresses in
   the IA and ignore any messages that indicate a NotOnLink status.
   When the client only receives one or more Reply messages with the
   NotOnLink status in response to a Confirm message, the client
   performs DHCP server discovery as described in Section 18.

18.2.10.4.  Reply for Information-request

   Refer to Section 21.23 for details on how the Information Refresh
   Time option (whether or not present in the Reply) should be handled
   by the client.

18.2.11.  Receipt of Reconfigure Messages

   A client receives Reconfigure messages sent to UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.  Since the
   results of a reconfiguration event may affect application-layer
   programs, the client SHOULD log these events and MAY notify these
   programs of the change through an implementation-specific interface.

   Upon receipt of a valid Reconfigure message, the client responds with
   a Renew message, a Rebind message, or an Information-request message
   as indicated by the Reconfigure Message option (see Section 21.19).
   The client ignores the "transaction-id" field in the received
   Reconfigure message.  While the transaction is in progress, the
   client discards any Reconfigure messages it receives.

   The Reconfigure message acts as a trigger that signals the client to
   complete a successful message exchange.  Once the client has received
   a Reconfigure, the client proceeds with the message exchange
   (retransmitting the Renew, Rebind, or Information-request message if
   necessary); the client MUST ignore any additional Reconfigure
   messages until the exchange is complete.

   Duplicate messages will be ignored because the client will begin the
   exchange after the receipt of the first Reconfigure.  Retransmitted
   messages will either (1) trigger the exchange (if the first
   Reconfigure was not received by the client) or (2) be ignored.  The
   server MAY discontinue retransmission of Reconfigure messages to the
   client once the server receives the Renew, Rebind, or
   Information-request message from the client.

   It might be possible for a duplicate or retransmitted Reconfigure to
   be sufficiently delayed (and delivered out of order) that it arrives
   at the client after the exchange (initiated by the original
   Reconfigure) has been completed.  In this case, the client would
   initiate a redundant exchange.  The likelihood of delayed and
   out-of-order delivery is small enough to be ignored.  The consequence
   of the redundant exchange is inefficiency rather than incorrect
   operation.

18.2.12.  Refreshing Configuration Information

   Whenever a client may have moved to a new link, the
   prefixes/addresses assigned to the interfaces on that link may no
   longer be appropriate for the link to which the client is attached.
   Examples of times when a client may have moved to a new link include
   the following:

   -  The client reboots (and has stable storage and persistent DHCP
      state).

   -  The client is reconnected to a link on which it has obtained
      leases.

   -  The client returns from sleep mode.

   -  The client changes access points (e.g., if using Wi-Fi
      technology).

   When the client detects that it may have moved to a new link and it
   has obtained addresses and no delegated prefixes from a server, the
   client SHOULD initiate a Confirm/Reply message exchange.  The client
   includes any IAs assigned to the interface that may have moved to a
   new link, along with the addresses associated with those IAs, in its
   Confirm message.  Any responding servers will indicate whether those
   addresses are appropriate for the link to which the client is
   attached with the status in the Reply message it returns to the
   client.

   If the client has any valid delegated prefixes obtained from the DHCP
   server, the client MUST initiate a Rebind/Reply message exchange as
   described in Section 18.2.5, with the exception that the
   retransmission parameters should be set as for the Confirm message
   (see Section 18.2.3).  The client includes IA_NAs, IA_TAs, and
   IA_PDs, along with the associated leases, in its Rebind message.

   If the client has only obtained network information using
   Information-request/Reply message exchanges, the client MUST initiate
   an Information-request/Reply message exchange as described in
   Section 18.2.6.

   If not associated with one of the above-mentioned conditions, a
   client SHOULD initiate a Renew/Reply exchange (as if the T1 time
   expired) as described in Section 18.2.4 or an Information-request/
   Reply exchange as described in Section 18.2.6 if the client detects a
   significant change regarding the prefixes available on the link (when
   new prefixes are added or existing prefixes are deprecated), as this
   may indicate a configuration change.  However, a client MUST
   rate-limit such attempts to avoid flooding a server with requests
   when there are link issues (for example, only doing one of these at
   most every 30 seconds).