5.  Client/Server Exchanges

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

   A DHCP client sends most messages using a reserved, link-scoped
   multicast destination address 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.

   Once the client has determined the address of a server, it may, under
   some circumstances, send messages directly to the server using
   unicast.

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 confirmed assignment of addresses and/or delegated
   prefixes and other configuration information.  The server responds
   with a Reply message that contains the confirmed 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.  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]).

6.  Operational Models

   This section describes some of the current most common DHCP
   operational models.  The described models are not mutually exclusive
   and are sometimes used together.  For example, a device may start in
   stateful mode to obtain an address and, at a later time when an
   application is started, request additional parameters using
   stateless mode.

   This document assumes that the DHCP servers and the client,
   communicating with the servers via a specific interface, belong to a
   single provisioning domain.

   DHCP may be extended to support additional stateful services that may
   interact with one or more of the models described below.  Such
   interaction should be considered and documented as part of any future
   protocol extension.

6.1.  Stateless DHCP

   Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining
   a lease but a node (DHCP client) desires one or more DHCP "other
   configuration" parameters, such as a list of DNS recursive name
   servers or DNS domain search lists [RFC3646].  Stateless DHCP may be
   used when a node initially boots or at any time the software on the
   node requires some missing or expired configuration information that
   is available via DHCP.

   This is the simplest and most basic operation for DHCP and requires a
   client (and a server) to support only two messages --
   Information-request and Reply.  Note that DHCP servers and relay
   agents typically also need to support the Relay-forward and
   Relay-reply messages to accommodate operation when clients and
   servers are not on the same link.

6.2.  DHCP for Non-temporary Address Assignment

   This model of operation was the original motivation for DHCP.  It is
   appropriate for situations where stateless address autoconfiguration
   alone is insufficient or impractical, e.g., because of network
   policy, additional requirements such as dynamic updates to the DNS,
   or client-specific requirements.

   The model of operation for non-temporary address assignment is as
   follows.  The server is provided with prefixes from which it may
   allocate addresses to clients, as well as any related network
   topology information as to which prefixes are present on which links.
   A client requests a non-temporary address to be assigned by the
   server.  The server allocates an address or addresses appropriate for
   the link on which the client is connected.  The server returns the
   allocated address or addresses to the client.

   Each address has associated preferred and valid lifetimes, which
   constitute an agreement about the length of time over which the
   client is allowed to use the address.  A client can request an
   extension of the lifetimes on an address and is required to terminate
   the use of an address if the valid lifetime of the address expires.

   Typically, clients request other configuration parameters, such as
   the DNS name server addresses and domain search lists, when
   requesting addresses.

   Clients can also request more than one address or set of addresses
   (see Sections 6.6 and 12).

6.3.  DHCP for Prefix Delegation

   The prefix delegation mechanism, originally described in [RFC3633],
   is another stateful mode of operation and was originally intended for
   simple delegation of prefixes from a delegating router (DHCP server)
   to requesting routers (DHCP clients).  It is appropriate for
   situations in which the delegating router (1) does not have knowledge
   about the topology of the networks to which the requesting router is
   attached and (2) does not require other information aside from the
   identity of the requesting router to choose a prefix for delegation.
   This mechanism is appropriate for use by an ISP to delegate a prefix
   to a subscriber, where the delegated prefix would possibly be
   subnetted and assigned to the links within the subscriber's network.
   [RFC7084] and [RFC7368] describe such use in detail.

   The design of this prefix delegation mechanism meets the requirements
   for prefix delegation in [RFC3769].

   While [RFC3633] assumes that the DHCP client is a router (hence the
   use of "requesting router") and that the DHCP server is a router
   (hence the use of "delegating router"), DHCP prefix delegation itself
   does not require that the client forward IP packets not addressed to
   itself and thus does not require that the client (or server) be a
   router as defined in [RFC8200].  Also, in many cases (such as
   tethering or hosting virtual machines), hosts are already forwarding
   IP packets and thus are operating as routers as defined in [RFC8200].
   Therefore, this document mostly replaces "requesting router" with
   "client" and "delegating router" with "server".

   The model of operation for prefix delegation is as follows.  A server
   is provisioned with prefixes to be delegated to clients.  A client
   requests prefix(es) from the server, as described in Section 18.  The
   server chooses prefix(es) for delegation and responds with prefix(es)
   to the client.  The client is then responsible for the delegated
   prefix(es).  For example, the client might assign a subnet from a
   delegated prefix to one of its interfaces and begin sending Router
   Advertisements for the prefix on that link.

   Each prefix has an associated preferred lifetime and valid lifetime,
   which constitute an agreement about the length of time over which the
   client is allowed to use the prefix.  A client can request an
   extension of the lifetimes on a delegated prefix and is required to
   terminate the use of a delegated prefix if the valid lifetime of the
   prefix expires.

   Figure 1 illustrates a network architecture in which prefix
   delegation could be used.

                      ______________________         \
                     /                      \         \
                    |    ISP core network    |         \
                     \__________ ___________/           |
                                |                       |
                        +-------+-------+               |
                        |  Aggregation  |               | ISP
                        |    device     |               | network
                        |  (delegating  |               |
                        |    router)    |               |
                        +-------+-------+               |
                                |                      /
                                |Network link to      /
                                |subscriber premises /
                                |
                         +------+------+             \
                         |     CPE     |              \
                         | (requesting |               \
                         |   router)   |                |
                         +----+---+----+                |
                              |   |                     | Subscriber
       ---+-------------+-----+   +-----+------         | network
          |             |               |               |
     +----+-----+ +-----+----+     +----+-----+         |
     |Subscriber| |Subscriber|     |Subscriber|        /
     |    PC    | |    PC    |     |    PC    |       /
     +----------+ +----------+     +----------+      /

                    Figure 1: Prefix Delegation Network

   In this example, the server (delegating router) is configured with a
   set of prefixes to be used for assignment to customers at the time of
   each customer's first connection to the ISP service.  The prefix
   delegation process begins when the client (requesting router)
   requests configuration information through DHCP.  The DHCP messages
   from the client are received by the server in the aggregation device.
   When the server receives the request, it selects an available prefix
   or prefixes for delegation to the client.  The server then returns
   the prefix or prefixes to the client.

   The client subnets the delegated prefix and assigns the longer
   prefixes to links in the subscriber's network.  In a typical scenario
   based on the network shown in Figure 1, the client subnets a single
   delegated /48 prefix into /64 prefixes and assigns one /64 prefix to
   each of the links in the subscriber network.

   The prefix delegation options can be used in conjunction with other
   DHCP options carrying other configuration information to the client.

   The client may, in turn, provide DHCP service to nodes attached to
   the internal network.  For example, the client may obtain the
   addresses of DNS and NTP servers from the ISP server and then pass
   that configuration information on to the subscriber hosts through a
   DHCP server in the client (requesting router).

   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.

6.4.  DHCP for Customer Edge Routers

   The DHCP requirements and network architecture for Customer Edge
   Routers are described in [RFC7084].  This model of operation combines
   address assignment (see Section 6.2) and prefix delegation (see
   Section 6.3).  In general, this model assumes that a single set of
   transactions between the client and server will assign or extend the
   client's non-temporary addresses and delegated prefixes.

6.5.  DHCP for Temporary Addresses

   Temporary addresses were originally introduced to avoid privacy
   concerns with stateless address autoconfiguration, which based
   64 bits of the address on the EUI-64 (see [RFC4941].  They were added
   to DHCP to provide complementary support when stateful address
   assignment is used.

   Temporary address assignment works mostly like non-temporary address
   assignment (see Section 6.2); however, these addresses are generally
   intended to be used for a short period of time and not to have their
   lifetimes extended, though they can be if required.

6.6.  Multiple Addresses and Prefixes

   DHCP allows a client to receive multiple addresses.  During typical
   operation, a client sends one instance of an IA_NA option and the
   server assigns at most one address from each prefix assigned to the
   link to which the client is attached.  In particular, the server can
   be configured to serve addresses out of multiple prefixes for a given

   link.  This is useful in cases such as when a network renumbering
   event is in progress.  In a typical deployment, the server will grant
   one address for each IA_NA option (see Section 21.4).

   A client can explicitly request multiple addresses by sending
   multiple IA_NA options (and/or IA_TA options; see Section 21.5).  A
   client can send multiple IA_NA (and/or IA_TA) options in its initial
   transmissions.  Alternatively, it can send an extra Request message
   with additional new IA_NA (and/or IA_TA) options (or include them in
   a Renew message).

   The same principle also applies to prefix delegation.  In principle,
   DHCP allows a client to request new prefixes to be delegated by
   sending additional IA_PD options (see Section 21.21).  However, a
   typical operator usually prefers to delegate a single, larger prefix.
   In most deployments, it is recommended that the client request a
   larger prefix in its initial transmissions rather than request
   additional prefixes later on.

   The exact behavior of the server (whether to grant additional
   addresses and prefixes or not) is up to the server policy and is out
   of scope for this document.

   For more information on how the server distinguishes between IA
   option instances, see Section 12.