6. Operational Models
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
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 can be used at any time, typically when a 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 assign
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 (see
Section 12.1), 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.5 and 12).
6.3. DHCP for Prefix Delegation
The prefix delegation mechanism is another stateful mode of operation
and was originally intended for simple delegation of prefixes from a
DHCP server to DHCP clients (typically routers). It is appropriate
for situations in which the client (1) does not have knowledge about
the topology of the networks to which it is attached and (2) does not
require other information 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].
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].
The model of operation for prefix delegation is as follows:
* The 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
(see Section 12.2), 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
+-------+-------+ |
| /
|Network link to /
|subscriber premises /
|
+------+--------+ \
| CPE | \
| (DHCP client) | \
+----+---+------+ |
| | | Subscriber
---+-------------+-----+ +-----+------ | network
| | | |
+----+-----+ +-----+----+ +----+-----+ |
|Subscriber| |Subscriber| |Subscriber| /
| PC | | PC | | PC | /
+----------+ +----------+ +----------+ /
Figure 1: Prefix Delegation Network
In this example, the server (in the ISP core network or integrated in
the aggregation device) 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 (or Customer Premises Equipment (CPE)) requests
configuration information through DHCP. The DHCP messages from the
client are received by the server via 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.
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.
A client that has delegated any of the address space received through
DHCP Prefix Delegation MUST NOT issue a DHCP Release on the relevant
delegated prefix while any of the address space is outstanding. That
includes addresses leased out by DHCPv6 (IA_NA), prefixes delegated
via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router
Advertisements. Requirement WPD-9 in [RFC9096] makes this the best
current practice.
[RFC9096], Section 3.3 provides further guidance on coordination of
lifetimes between WAN (DHCPv6-PD client) and LAN (DHCPv6-PD server)
sides.
Several problems related to Prefix Delegation and Relay Agents and a
set of requirements to address them are defined in [RFC8987].
6.4. DHCP for Customer Edge Routers
The DHCP requirements and network architecture for Customer Edge
Routers are described in [RFC7084], with improvements for renumbering
described in [RFC9096]. 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. 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).
To meet the recommendations of [RFC7934], a client can explicitly
request multiple addresses by sending multiple IA_NA options. A
client can send multiple IA_NA options in its initial transmissions.
Alternatively, it can send an extra Request message with additional
new IA_NA 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.
6.6. Registering Self-Generated Addresses
[RFC9686] introduces a method for devices to register their self-
generated or statically configured addresses in the DHCPv6 servers.
The general idea is that devices would notify the server about
addresses that they are using, so that the server can log or record
these addresses as required by local policy.
The major specificity of this mechanism is that the address selection
is not done by the DHCP server, but by the device itself. The
majority of the lifecycle remains the same in principle: a lease is
created by the server, the device performs periodic actions to get
the lease renewed, and, eventually, the lease can expire. However,
this mechanism uses different message types (ADDR-REG-INFORM and
ADDR-REG-REPLY) and has different source address requirements, as
defined in [RFC9686].