Skip to main content

5. Client/Server 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​

5.  Client/Server Exchanges

   Clients and servers exchange DHCP messages using UDP (see [RFC0768]
   and [BCP145]).  The client uses a link-local source address or
   addresses determined through other mechanisms for transmitting and
   receiving DHCP messages.

   A DHCP client sends all messages using a reserved, link-scoped
   multicast destination address (All_DHCP_Relay_Agents_and_Servers -
   ff02::1:2) so that the client need not be configured with the address
   or addresses of DHCP servers.

   To allow a DHCP client to send a message to a DHCP server that is not
   attached to the same link, a DHCP relay agent on the client's link
   will relay messages between the client and server.  The operation of
   the relay agent is transparent to the client.  The discussion of
   message exchanges in the remainder of this section will omit the
   description of the relaying of messages by relay agents.

5.1.  Client/Server Exchanges Involving Two Messages

   When a DHCP client does not need to have a DHCP server assign IP
   addresses or delegated prefixes to it, the client can obtain other
   configuration information such as a list of available DNS servers
   [RFC3646] or NTP servers [RFC5908] through a single message and reply
   exchange with a DHCP server.  To obtain other configuration
   information, the client first sends an Information-request message to
   the All_DHCP_Relay_Agents_and_Servers multicast address.  Servers
   respond with a Reply message containing the other configuration
   information for the client.

   A client may also request the server to expedite address assignment
   and/or prefix delegation by using a two-message exchange instead of
   the normal four-message exchange as discussed in the next section.
   Expedited assignment can be requested by the client, and servers may
   or may not honor the request (see Sections 18.3.1 and 21.14 for more
   details and why servers may not honor this request).  Clients may
   request this expedited service in environments where it is likely
   that there is only one server available on a link and no expectation
   that a second server would become available, or when completing the
   configuration process as quickly as possible is a priority.

   To request the expedited two-message exchange, the client sends a
   Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast
   address requesting the assignment of addresses and/or delegated
   prefixes and other configuration information.  This message includes
   an indication (the Rapid Commit option; see Section 21.14) that the
   client is willing to accept an immediate Reply message from the
   server.  The server that is willing to commit the assignment of
   addresses and/or delegated prefixes to the client immediately
   responds with a Reply message.  The configuration information and the
   addresses and/or delegated prefixes in the Reply message are then
   immediately available for use by the client.

   Each address or delegated prefix assigned to the client has
   associated preferred and valid lifetimes specified by the server.  To
   request an extension of the lifetimes assigned to an address or
   delegated prefix, the client sends a Renew message to the server.
   The server sends a Reply message to the client with the new
   lifetimes, allowing the client to continue to use the address or
   delegated prefix without interruption.  If the server is unable to
   extend the lifetime of an address or delegated prefix, it indicates
   this by returning the address or delegated prefix with lifetimes of
   0.  At the same time, the server may assign other addresses or
   delegated prefixes.

   See Section 18 for descriptions of additional two-message exchanges
   between the client and server.

5.2.  Client/Server Exchanges Involving Four Messages

   To request the assignment of one or more addresses and/or delegated
   prefixes, a client first locates a DHCP server and then requests the
   assignment of addresses and/or delegated prefixes and other
   configuration information from the server.  The client sends a
   Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast
   address to find available DHCP servers.  Any server that can meet the
   client's requirements responds with an Advertise message.  The client
   then chooses one of the servers and sends a Request message to the
   server asking for the lease of addresses and/or delegated prefixes
   and other configuration information.  The server responds with a
   Reply message that contains the leased addresses, delegated prefixes,
   and configuration.

   As described in the previous section, the client can request an
   extension of the lifetimes assigned to addresses or delegated
   prefixes (this is a two-message exchange).

5.3.  Server/Client Exchanges

   A server that has previously communicated with a client and
   negotiated for the client to listen for Reconfigure messages may send
   the client a Reconfigure message to initiate the client to update its
   configuration by sending an Information-request, Renew, or Rebind
   message.  Reconfigure messages are authenticated as per Section 20.4.
   The client then performs the two-message exchange as described
   earlier.  This can be used to expedite configuration changes to a
   client, such as the need to renumber a network (see [RFC6879] and
   [RFC9096]).
Last updated on