18.3.  Server Behavior

   For this discussion, the server is assumed to have been configured in
   an implementation-specific manner with configurations of interest to
   clients.

   A server sends an Advertise message in response to each valid Solicit
   message it receives to announce the availability of the server to the
   client.

   In most cases, the server will send a Reply in response to Request,
   Confirm, Renew, Rebind, Decline, Release, and Information-request
   messages sent by a client.  The server will also send a Reply in
   response to a Solicit with a Rapid Commit option (see Section 21.14)
   when the server is configured to respond with committed lease
   assignments.

   These Advertise and Reply messages MUST always contain the Server
   Identifier option (see Section 21.3) containing the server's DUID and
   the Client Identifier option (see Section 21.2) from the client
   message if one was present.

   In most response messages, the server includes options containing
   configuration information for the client.  The server must be aware
   of the recommendations on packet sizes and the use of fragmentation

   as discussed in Section 5 of [RFC8200].  If the client included an
   Option Request option (see Section 21.7) in its message, the server
   includes options in the response message containing configuration
   parameters for all of the options identified in the Option Request
   option that the server has been configured to return to the client.
   The server MAY return additional options to the client if it has been
   configured to do so.

   Any message sent from a client may arrive at the server encapsulated
   in one or more Relay-forward messages.  The server MUST use the
   received message to construct the proper Relay-reply message to allow
   the response to the received message to be relayed through the same
   relay agents (in reverse order) as the original client message; see
   Section 19.3 for more details.  The server may also need to record
   this information with each client in case it is needed to send a
   Reconfigure message at a later time, unless the server has been
   configured with addresses that can be used to send Reconfigure
   messages directly to the client (see Section 18.3.11).  Note that
   servers that support leasequery [RFC5007] also need to record this
   information.

   By sending Reconfigure messages, the server MAY initiate a
   configuration exchange to cause DHCP clients to obtain new addresses,
   prefixes, and other configuration information.  For example, an
   administrator may use a server-initiated configuration exchange when
   links in the DHCP domain are to be renumbered or when other
   configuration options are updated, perhaps because servers are moved,
   added, or removed.

   When a client receives a Reconfigure message from the server, the
   client initiates sending a Renew, Rebind, or Information-request
   message as indicated by msg-type in the Reconfigure Message option
   (see Section 21.19).  The server sends IAs and/or other configuration
   information to the client in a Reply message.  The server MAY include
   options containing the IAs and new values for other configuration
   parameters in the Reply message, even if those IAs and parameters
   were not requested in the client's message.

18.3.1.  Receipt of Solicit Messages

   See Section 18.4 for details regarding the handling of Solicit
   messages received via unicast.  Unicast transmission of Solicit
   messages is not allowed, regardless of whether the Server Unicast
   option (see Section 21.12) is configured or not.

   The server determines the information about the client and its
   location as described in Section 13 and checks its administrative
   policy about responding to the client.  If the server is not

   permitted to respond to the client, the server discards the Solicit
   message.  For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client does not include a Reconfigure
   Accept option (see Section 21.20) in the Solicit message, the server
   discards the Solicit message.

   If (1) the server is permitted to respond to the client, (2) the
   client has not included a Rapid Commit option (see Section 21.14) in
   the Solicit message, or (3) the server has not been configured to
   respond with committed assignments of leases and other resources, the
   server sends an Advertise message to the client as described in
   Section 18.3.9.

   If the client has included a Rapid Commit option in the Solicit
   message and the server has been configured to respond with committed
   assignments of leases and other resources, the server responds to the
   Solicit with a Reply message.  The server produces the Reply message
   as though it had received a Request message as described in
   Section 18.3.2.  The server transmits the Reply message as described
   in Section 18.3.10.  The server MUST commit the assignment of any
   addresses and delegated prefixes or other configuration information
   before sending a Reply message to a client.  In this case, the server
   includes a Rapid Commit option in the Reply message to indicate that
   the Reply is in response to a Solicit message.

   DISCUSSION:

      When using the Solicit/Reply message exchange, the server commits
      the assignment of any leases before sending the Reply message.
      The client can assume that it has been assigned the leases in the
      Reply message and does not need to send a Request message for
      those leases.

      Typically, servers that are configured to use the Solicit/Reply
      message exchange will be deployed so that only one server will
      respond to a Solicit message.  If more than one server responds,
      the client will only use the leases from one of the servers, while
      the leases from the other servers will be committed to the client
      but not used by the client.

18.3.2.  Receipt of Request Messages

   See Section 18.4 for details regarding the handling of Request
   messages received via unicast.

   When the server receives a valid Request message, the server creates
   the bindings for that client according to the server's policy and
   configuration information and records the IAs and other information
   requested by the client.

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Request message into
   the "transaction-id" field.

   The server MUST include in the Reply message a Server Identifier
   option (see Section 21.3) containing the server's DUID and the Client
   Identifier option (see Section 21.2) from the Request message.

   The server examines all IAs in the message from the client.

   For each IA_NA option (see Section 21.4) and IA_TA option (see
   Section 21.5) in the Request message, the server checks if the
   prefixes of included addresses are appropriate for the link to which
   the client is connected.  If any of the prefixes of the included
   addresses are not appropriate for the link to which the client is
   connected, the server MUST return the IA to the client with a Status
   Code option (see Section 21.13) with the value NotOnLink.  If the
   server does not send the NotOnLink status code but it cannot assign
   any IP addresses to an IA, the server MUST return the IA option in
   the Reply message with no addresses in the IA and a Status Code
   option containing status code NoAddrsAvail in the IA.

   For any IA_PD option (see Section 21.21) in the Request message to
   which the server cannot assign any delegated prefixes, the server
   MUST return the IA_PD option in the Reply message with no prefixes in
   the IA_PD and with a Status Code option containing status code
   NoPrefixAvail in the IA_PD.

   The server MAY assign different addresses and/or delegated prefixes
   to an IA than those included within the IA of the client's Request
   message.

   For all IAs to which the server can assign addresses or delegated
   prefixes, the server includes the IAs with addresses (for IA_NAs and
   IA_TAs), prefixes (for IA_PDs), and other configuration parameters
   and records the IA as a new client binding.  The server MUST NOT
   include any addresses or delegated prefixes in the IA that the server
   does not assign to the client.

   The T1/T2 times set in each applicable IA option for a Reply MUST be
   the same values across all IAs.  The server MUST determine the T1/T2
   times across all of the applicable client's bindings in the Reply.
   This facilitates the client being able to renew all of the bindings
   at the same time.

   The server SHOULD include a Reconfigure Accept option (see
   Section 21.20) if the server policy enables the reconfigure mechanism
   and the client supports it.  Currently, sending this option in a
   Reply is technically redundant, as the use of the reconfiguration
   mechanism requires authentication; at present, the only defined
   mechanism is RKAP (see Section 20.4), and the presence of the
   reconfigure key signals support for the acceptance of Reconfigure
   messages.  However, there may be better security mechanisms defined
   in the future that would cause RKAP to not be used anymore.

   The server includes other options containing configuration
   information to be returned to the client as described in
   Section 18.3.

   If the server finds that the client has included an IA in the Request
   message for which the server already has a binding that associates
   the IA with the client, the server sends a Reply message with
   existing bindings, possibly with updated lifetimes.  The server may
   update the bindings according to its local policies, but the server
   SHOULD generate the response again and not simply retransmit
   previously sent information, even if the "transaction-id" field value
   matches a previous transmission.  The server MUST NOT cache its
   responses.

   DISCUSSION:

      Cached replies are bad because lifetimes need to be updated
      (either decrease the timers by the amount of time elapsed since
      the original transmission or keep the lifetime values and update
      the lease information in the server's database).  Also, if the
      message uses any security protection (such as the Replay Detection
      Method (RDM), as described in Section 20.3), its value must be
      updated.  Additionally, any digests must be updated.  Given all of
      the above, caching replies is far more complex than simply sending
      the same buffer as before, and it is easy to miss some of those
      steps.

18.3.3.  Receipt of Confirm Messages

   See Section 18.4 for details regarding the handling of Confirm
   messages received via unicast.  Unicast transmission of Confirm
   messages is not allowed, regardless of whether the Server Unicast
   option (see Section 21.12) is configured or not.

   When the server receives a Confirm message, the server determines
   whether the addresses in the Confirm message are appropriate for the
   link to which the client is attached.  If all of the addresses in the
   Confirm message pass this test, the server returns a status of
   Success.  If any of the addresses do not pass this test, the server
   returns a status of NotOnLink.  If the server is unable to perform
   this test (for example, the server does not have information about
   prefixes on the link to which the client is connected) or there were
   no addresses in any of the IAs sent by the client, the server
   MUST NOT send a Reply to the client.

   The server ignores the T1 and T2 fields in the IA options and the
   preferred-lifetime and valid-lifetime fields in the IA Address
   options (see Section 21.6).

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Confirm message into
   the "transaction-id" field.

   The server MUST include in the Reply message a Server Identifier
   option (see Section 21.3) containing the server's DUID and the Client
   Identifier option (see Section 21.2) from the Confirm message.  The
   server includes a Status Code option (see Section 21.13) indicating
   the status of the Confirm message.

18.3.4.  Receipt of Renew Messages

   See Section 18.4 for details regarding the handling of Renew messages
   received via unicast.

   For each IA in the Renew message from a client, the server locates
   the client's binding and verifies that the information in the IA from
   the client matches the information stored for that client.

   If the server finds the client entry for the IA, the server sends the
   IA back to the client with new lifetimes and, if applicable, T1/T2
   times.  If the server is unable to extend the lifetimes of an address
   or delegated prefix in the IA, the server MAY choose not to include
   the IA Address option (see Section 21.6) for that address or IA
   Prefix option (see Section 21.22) for that delegated prefix.  If the
   server chooses to include the IA Address or IA Prefix option for such

   an address or delegated prefix, the server SHOULD set T1 and T2
   values to the valid lifetime for the IA option unless the server also
   includes other addresses or delegated prefixes that the server is
   able to extend for the IA.  Setting T1 and T2 to values equal to the
   valid lifetime informs the client that the leases associated with
   said IA will not be extended, so there is no point in trying.  Also,
   it avoids generating unnecessary traffic as the remaining lifetime
   approaches 0.

   The server may choose to change the list of addresses or delegated
   prefixes and the lifetimes in IAs that are returned to the client.

   If the server finds that any of the addresses in the IA are not
   appropriate for the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.

   If the server finds that any of the delegated prefixes in the IA are
   not appropriate for the link to which the client is attached, the
   server returns the delegated prefix to the client with lifetimes
   of 0.

   For each IA for which the server cannot find a client entry, the
   server has the following choices, depending on the server's policy
   and configuration information:

   -  If the server is configured to create new bindings as a result of
      processing Renew messages, the server SHOULD create a binding and
      return the IA with assigned addresses or delegated prefixes with
      lifetimes and, if applicable, T1/T2 times and other information
      requested by the client.  If the client included the IA Prefix
      option within the IA_PD option (see Section 21.21) with a zero
      value in the "IPv6-prefix" field and a non-zero value in the
      "prefix-length" field, the server MAY use the "prefix-length"
      value as a hint for the length of the prefixes to be assigned (see
      [RFC8168] for further details on prefix-length hints).

   -  If the server is configured to create new bindings as a result of
      processing Renew messages but the server will not assign any
      leases to an IA, the server returns the IA option containing a
      Status Code option (see Section 21.13) with the NoAddrsAvail or
      NoPrefixAvail status code and a status message for a user.

   -  If the server does not support creation of new bindings for the
      client sending a Renew message or if this behavior is disabled
      according to the server's policy or configuration information, the
      server returns the IA option containing a Status Code option with
      the NoBinding status code and a status message for a user.

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Renew message into
   the "transaction-id" field.

   The server MUST include in the Reply message a Server Identifier
   option (see Section 21.3) containing the server's DUID and the Client
   Identifier option (see Section 21.2) from the Renew message.

   The server includes other options containing configuration
   information to be returned to the client as described in
   Section 18.3.

   The server MAY include options containing the IAs and values for
   other configuration parameters, even if those parameters were not
   requested in the Renew message.

   The T1/T2 values set in each applicable IA option for a Reply MUST be
   the same across all IAs.  The server MUST determine the T1/T2 values
   across all of the applicable client's bindings in the Reply.  This
   facilitates the client being able to renew all of the bindings at the
   same time.

18.3.5.  Receipt of Rebind Messages

   See Section 18.4 for details regarding the handling of Rebind
   messages received via unicast.  Unicast transmission of Rebind
   messages is not allowed, regardless of whether the Server Unicast
   option (see Section 21.12) is configured or not.

   When the server receives a Rebind message that contains an IA option
   from a client, it locates the client's binding and verifies that the
   information in the IA from the client matches the information stored
   for that client.

   If the server finds the client entry for the IA and the server
   determines that the addresses or delegated prefixes in the IA are
   appropriate for the link to which the client's interface is attached
   according to the server's explicit configuration information, the
   server SHOULD send the IA back to the client with new lifetimes and,
   if applicable, T1/T2 values.  If the server is unable to extend the
   lifetimes of an address in the IA, the server MAY choose not to
   include the IA Address option (see Section 21.6) for this address.
   If the server is unable to extend the lifetimes of a delegated prefix
   in the IA, the server MAY choose not to include the IA Prefix option
   (see Section 21.22) for this prefix.

   If the server finds that the client entry for the IA and any of the
   addresses or delegated prefixes are no longer appropriate for the
   link to which the client's interface is attached according to the
   server's explicit configuration information, the server returns those
   addresses or delegated prefixes to the client with lifetimes of 0.

   If the server cannot find a client entry for the IA, the server
   checks if the IA contains addresses (for IA_NAs and IA_TAs) or
   delegated prefixes (for IA_PDs).  The server checks if the addresses
   and delegated prefixes are appropriate for the link to which the
   client's interface is attached according to the server's explicit
   configuration information.  For any address that is not appropriate
   for the link to which the client's interface is attached, the server
   MAY include the IA Address option with lifetimes of 0.  For any
   delegated prefix that is not appropriate for the link to which the
   client's interface is attached, the server MAY include the IA Prefix
   option with lifetimes of 0.  The Reply with lifetimes of 0
   constitutes an explicit notification to the client that the specific
   addresses and delegated prefixes are no longer valid and MUST NOT be
   used by the client.  If the server chooses to not include any IAs
   containing IA Address or IA Prefix options with lifetimes of 0 and
   the server does not include any other IAs with leases and/or status
   codes, the server does not send a Reply message.  In this situation,
   the server discards the Rebind message.

   Otherwise, for each IA for which the server cannot find a client
   entry, the server has the following choices, depending on the
   server's policy and configuration information:

   -  If the server is configured to create new bindings as a result of
      processing Rebind messages (also see the note below about the
      Rapid Commit option (Section 21.14)), the server SHOULD create a
      binding and return the IA with allocated leases with lifetimes
      and, if applicable, T1/T2 values and other information requested
      by the client.  The server MUST NOT return any addresses or
      delegated prefixes in the IA that the server does not assign to
      the client.

   -  If the server is configured to create new bindings as a result of
      processing Rebind messages but the server will not assign any
      leases to an IA, the server returns the IA option containing a
      Status Code option (see Section 21.13) with the NoAddrsAvail or
      NoPrefixAvail status code and a status message for a user.

   -  If the server does not support creation of new bindings for the
      client sending a Rebind message or if this behavior is disabled
      according to the server's policy or configuration information, the
      server returns the IA option containing a Status Code option with
      the NoBinding status code and a status message for a user.

   When the server creates new bindings for the IA, it is possible that
   other servers also create bindings as a result of receiving the same
   Rebind message; see the "DISCUSSION" text in Section 21.14.
   Therefore, the server SHOULD only create new bindings during
   processing of a Rebind message if the server is configured to respond
   with a Reply message to a Solicit message containing the Rapid Commit
   option.

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Rebind message into
   the "transaction-id" field.

   The server MUST include in the Reply message a Server Identifier
   option (see Section 21.3) containing the server's DUID and the Client
   Identifier option (see Section 21.2) from the Rebind message.

   The server includes other options containing configuration
   information to be returned to the client as described in
   Section 18.3.

   The server MAY include options containing the IAs and values for
   other configuration parameters, even if those IAs and parameters were
   not requested in the Rebind message.

   The T1 or T2 values set in each applicable IA option for a Reply MUST
   be the same values across all IAs.  The server MUST determine the T1
   or T2 values across all of the applicable client's bindings in the
   Reply.  This facilitates the client being able to renew all of the
   bindings at the same time.

18.3.6.  Receipt of Information-request Messages

   See Section 18.4 for details regarding the handling of
   Information-request messages received via unicast.

   When the server receives an Information-request message, the client
   is requesting configuration information that does not include the
   assignment of any leases.  The server determines all configuration
   parameters appropriate to the client, based on the server
   configuration policies known to the server.

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Information-request
   message into the "transaction-id" field.

   The server MUST include a Server Identifier option (see Section 21.3)
   containing the server's DUID in the Reply message.  If the client
   included a Client Identifier option (see Section 21.2) in the
   Information-request message, the server copies that option to the
   Reply message.

   The server includes options containing configuration information to
   be returned to the client as described in Section 18.3.  The server
   MAY include additional options that were not requested by the client
   in the Information-request message.

   If the Information-request message received from the client did not
   include a Client Identifier option, the server SHOULD respond with a
   Reply message containing any configuration parameters that are not
   determined by the client's identity.  If the server chooses not to
   respond, the client may continue to retransmit the
   Information-request message indefinitely.

18.3.7.  Receipt of Release Messages

   See Section 18.4 for details regarding the handling of Release
   messages received via unicast.

   The server constructs a Reply message by setting the "msg-type" field
   to REPLY and copying the transaction ID from the Release message into
   the "transaction-id" field.

   Upon the receipt of a valid Release message, the server examines the
   IAs and the leases in the IAs for validity.  If the IAs in the
   message are in a binding for the client and the leases in the IAs
   have been assigned by the server to those IAs, the server deletes the
   leases from the IAs and makes the leases available for assignment to
   other clients.  The server ignores leases not assigned to the IAs,
   although it may choose to log an error.

   After all the leases have been processed, the server generates a
   Reply message and includes a Status Code option (see Section 21.13)
   with the value Success, a Server Identifier option (see Section 21.3)
   with the server's DUID, and a Client Identifier option (see
   Section 21.2) with the client's DUID.  For each IA in the Release
   message for which the server has no binding information, the server
   adds an IA option using the IAID from the Release message and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option.

   A server may choose to retain a record of assigned leases and IAs
   after the lifetimes on the leases have expired to allow the server to
   reassign the previously assigned leases to a client.

18.3.8.  Receipt of Decline Messages

   See Section 18.4 for details regarding the handling of Decline
   messages received via unicast.

   Upon the receipt of a valid Decline message, the server examines the
   IAs and the addresses in the IAs for validity.  If the IAs in the
   message are in a binding for the client and the addresses in the IAs
   have been assigned by the server to those IAs, the server deletes the
   addresses from the IAs.  The server ignores addresses not assigned to
   the IAs (though it may choose to log an error if it finds such
   addresses).

   The client has found any addresses in the Decline messages to be
   already in use on its link.  Therefore, the server SHOULD mark the
   addresses declined by the client so that those addresses are not
   assigned to other clients and MAY choose to make a notification that
   addresses were declined.  Local policy on the server determines when
   the addresses identified in a Decline message may be made available
   for assignment.

   After all the addresses have been processed, the server generates a
   Reply message by setting the "msg-type" field to REPLY and copying
   the transaction ID from the Decline message into the "transaction-id"
   field.  The client includes a Status Code option (see Section 21.13)
   with the value Success, a Server Identifier option (see Section 21.3)
   with the server's DUID, and a Client Identifier option (see
   Section 21.2) with the client's DUID.  For each IA in the Decline
   message for which the server has no binding information, the server
   adds an IA option using the IAID from the Decline message and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option.

18.3.9.  Creation of Advertise Messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   contents of the "transaction-id" field from the Solicit message
   received from the client to the Advertise message.  The server
   includes its server identifier in a Server Identifier option (see
   Section 21.3) and copies the Client Identifier option (see
   Section 21.2) from the Solicit message into the Advertise message.

   The server MAY add a Preference option (see Section 21.8) to carry
   the preference value for the Advertise message.  The server
   implementation SHOULD allow the setting of a server preference value
   by the administrator.  The server preference value MUST default to 0
   unless otherwise configured by the server administrator.

   The server includes a Reconfigure Accept option (see Section 21.20)
   if the server wants to indicate that it supports the Reconfigure
   mechanism.  This information may be used by the client during the
   server selection process.

   The server includes the options the server will return to the client
   in a subsequent Reply message.  The information in these options may
   be used by the client in the selection of a server if the client
   receives more than one Advertise message.  The server MUST include
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option (see
   Section 21.7) in the Solicit message that the server has been
   configured to return to the client.  If the Option Request option
   includes a container option, the server MUST include all the options
   that are eligible to be encapsulated in the container.  The Option
   Request option MAY be used to signal support for a feature even when
   that option is encapsulated, as in the case of the Prefix Exclude
   option [RFC6603].  In this case, special processing is required by
   the server.  The server MAY return additional options to the client
   if it has been configured to do so.

   The server MUST include IA options in the Advertise message
   containing any addresses and/or delegated prefixes that would be
   assigned to IAs contained in the Solicit message from the client.  If
   the client has included addresses in the IA Address options (see
   Section 21.6) in the Solicit message, the server MAY use those
   addresses as hints about the addresses that the client would like to
   receive.  If the client has included IA Prefix options (see
   Section 21.22), the server MAY use the prefix contained in the
   "IPv6-prefix" field and/or the prefix length contained in the
   "prefix-length" field as hints about the prefixes the client would
   like to receive.  If the server is not going to assign an address or
   delegated prefix received as a hint in the Solicit message, the
   server MUST NOT include this address or delegated prefix in the
   Advertise message.

   If the server will not assign any addresses to an IA_NA or IA_TA in
   subsequent Request messages from the client, the server MUST include
   the IA option in the Advertise message with no addresses in that IA
   and a Status Code option (see Section 21.13) encapsulated in the IA
   option containing status code NoAddrsAvail.

   If the server will not assign any prefixes to an IA_PD in subsequent
   Request messages from the client, the server MUST include the IA_PD
   option (see Section 21.21) in the Advertise message with no prefixes
   in the IA_PD option and a Status Code option encapsulated in the
   IA_PD containing status code NoPrefixAvail.

   Transmission of Advertise messages is described in the next section.

18.3.10.  Transmission of Advertise and Reply Messages

   If the original message was received directly by the server, the
   server unicasts the Advertise or Reply message directly to the client
   using the address in the source address field from the IP datagram in
   which the original message was received.  The Advertise or Reply
   message MUST be unicast through the interface on which the original
   message was received.

   If the original message was received in a Relay-forward message, the
   server constructs a Relay-reply message with the Reply message in the
   payload of a Relay Message option (see Section 21.10).  If the
   Relay-forward messages included an Interface-Id option (see
   Section 21.18), the server copies that option to the Relay-reply
   message.  The server unicasts the Relay-reply message directly to the
   relay agent using the address in the source address field from the IP
   datagram in which the Relay-forward message was received.  See
   Section 19.3 for more details on the construction of Relay-reply
   messages.

18.3.11.  Creation and Transmission of Reconfigure Messages

   The server sets the "msg-type" field to RECONFIGURE and sets the
   "transaction-id" field to 0.  The server includes a Server Identifier
   option (see Section 21.3) containing its DUID and a Client Identifier
   option (see Section 21.2) containing the client's DUID in the
   Reconfigure message.

   Because of the risk of denial-of-service (DoS) attacks against DHCP
   clients, the use of a security mechanism is mandated in Reconfigure
   messages.  The server MUST use DHCP authentication in the Reconfigure
   message (see Section 20.4).

   The server MUST include a Reconfigure Message option (see
   Section 21.19) to select whether the client responds with a Renew
   message, a Rebind message, or an Information-request message.

   The server MUST NOT include any other options in the Reconfigure
   message, except as specifically allowed in the definition of
   individual options.

   A server sends each Reconfigure message to a single DHCP client,
   using an IPv6 unicast address of sufficient scope belonging to the
   DHCP client.  If the server does not have an address to which it can
   send the Reconfigure message directly to the client, the server uses
   a Relay-reply message (as described in Section 19.3) to send the
   Reconfigure message to a relay agent that will relay the message to
   the client.  The server may obtain the address of the client (and the
   appropriate relay agent, if required) through the information the
   server has about clients that have been in contact with the server
   (see Section 18.3) or through some external agent.

   To reconfigure more than one client, the server unicasts a separate
   message to each client.  The server may initiate the reconfiguration
   of multiple clients concurrently; for example, a server may send a
   Reconfigure message to additional clients while previous
   reconfiguration message exchanges are still in progress.

   The Reconfigure message causes the client to initiate a Renew/Reply,
   Rebind/Reply, or Information-request/Reply message exchange with the
   server.  The server interprets the receipt of a Renew, Rebind, or
   Information-request message (whichever was specified in the original
   Reconfigure message) from the client as satisfying the Reconfigure
   message request.

   When transmitting the Reconfigure message, the server sets the
   retransmission time (RT) to REC_TIMEOUT.  If the server does not
   receive a Renew, Rebind, or Information-request message from the
   client before the RT elapses, the server retransmits the Reconfigure
   message, doubles the RT value, and waits again.  The server continues
   this process until REC_MAX_RC unsuccessful attempts have been made,
   at which point the server SHOULD abort the reconfigure process for
   that client.

   Default and initial values for REC_TIMEOUT and REC_MAX_RC are
   documented in Section 7.6.

18.4.  Reception of Unicast Messages

   Unless otherwise stated in the subsections of Section 18.3 that
   discuss the receipt of specific messages, the server is not supposed
   to accept unicast traffic when it is not explicitly configured to do
   so.  For example, unicast transmission is not allowed for Solicit,
   Confirm, and Rebind messages (see Sections 18.3.1, 18.3.3, and
   18.3.5, respectively), even if the Server Unicast option (see
   Section 21.12) is configured.  For Request, Renew,
   Information-request, Release, and Decline messages, it is allowed
   only if the Server Unicast option is configured.

   When the server receives a message via unicast from a client to which
   the server has not sent a Server Unicast option (or is not currently
   configured to do so), the server discards that message and responds
   with an Advertise (when responding to a Solicit message) or Reply
   message (when responding to any other messages) containing a Status
   Code option (see Section 21.13) with the value UseMulticast, a Server
   Identifier option (see Section 21.3) containing the server's DUID,
   the Client Identifier option (see Section 21.2) from the client
   message (if any), and no other options.