Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

1.1. Relationship to Previous DHCPv6 Standards

The initial specification of DHCPv6 was defined in [RFC3315], and a number of follow-up documents were published over the years:¶

• [RFC3633] ("IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6")¶
• [RFC3736] ("Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6")¶
• [RFC4242] ("Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)")¶
• [RFC7083] ("Modification to Default Values of SOL_MAX_RT and INF_MAX_RT")¶
• [RFC7283] ("Handling Unknown DHCPv6 Messages")¶
• [RFC7550] ("Issues and Recommendations with Multiple Stateful DHCPv6 Options")¶

[RFC8415] provided a unified, corrected, and cleaned-up definition of DHCPv6 that also covered all applicable errata filed against older RFCs. It also obsoleted a small number of mechanisms: delayed authentication, lifetime and timer hints sent by a client.¶

This document obsoletes [RFC8415] by applying all applicable errata and obsoleting two features that have not been widely implemented - the assignment of temporary addresses using the IA_TA option and allowing clients to unicast some messages directly to the server if the server sent the Server Unicast option to a client in an early exchange. It also clarifies that clients, servers, and relay agents can send DHCP messages from any UDP (source) port they are allowed to use including their designated destination ports. For a complete list of changes made to [RFC8415] see Appendix A.¶

1.2. Relationship to DHCPv4

The operational models and relevant configuration information for DHCPv4 [RFC2131] [RFC2132] and DHCPv6 are sufficiently different that integration between the two services is not included in this document. [RFC3315] suggested that future work might be to extend DHCPv6 to carry IPv4 address and configuration information. However, the current consensus of the IETF is that DHCPv4 should be used rather than DHCPv6 when conveying IPv4 configuration information to nodes. For IPv6-only networks, [RFC7341] describes a transport mechanism to carry DHCPv4 messages using the DHCPv6 protocol for the dynamic provisioning of IPv4 address and configuration information.¶

Merging DHCPv4 and DHCPv6 configuration is out of scope for this document. [RFC4477] discusses some issues and possible strategies for running DHCPv4 and DHCPv6 services together. While [RFC4477] is a bit dated, it provides a good overview of the issues at hand.¶

4.2. DHCP Terminology

Terminology specific to DHCP can be found below.¶

appropriate to the link

An address is "appropriate to the link" when the address is consistent with the DHCP server's knowledge of the network topology, prefix assignment, and address assignment policies.¶

binding

A binding (or client binding) is a group of server data records containing the information the server has about the addresses or delegated prefixes in an Identity Association (IA) or configuration information explicitly assigned to the client. Configuration information that has been returned to a client through a policy, such as the information returned to all clients on the same link, does not require a binding. A binding containing information about an IA is indexed by the tuple <DUID, IA‑type, IAID> (where IA-type is the type of lease in the IA -- for example, address or delegated prefix). A binding containing configuration information for a client is indexed by <DUID>. See below for definitions of DUID, IA, and IAID.¶

configuration parameter

An element of the configuration information set on the server and delivered to the client using DHCP. Such parameters may be used to carry information to be used by a node to configure its network subsystem and enable communication on a link or internetwork, for example.¶

container option

An option that encapsulates other options (for example, the IA_NA option (see Section 21.4) may contain IA Address options (see Section 21.6)).¶

delegating router

The router that acts as a DHCP server and responds to requests for delegated prefixes. This document primarily uses the term "DHCP server" or "server" when discussing the "delegating router" functionality of prefix delegation (see Section 1).¶

DHCP

Dynamic Host Configuration Protocol for IPv6. The terms "DHCPv4" and "DHCPv6" are used only in contexts where it is necessary to avoid ambiguity.¶

DHCP client

Also referred to as "client". A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers. The node may act as a requesting router (see below) if it supports prefix delegation.¶

DHCP domain

A set of links managed by DHCP and operated by a single administrative entity.¶

DHCP relay agent

Also referred to as "relay agent". A node that acts as an intermediary to deliver DHCP messages between clients and servers. In certain configurations, there may be more than one relay agent between clients and servers, so a relay agent may send DHCP messages to another relay agent.¶

DHCP server

Also referred to as "server". A node that responds to requests from clients. It may or may not be on the same link as the client(s). Depending on its capabilities, if it supports prefix delegation it may also feature the functionality of a delegating router.¶

DUID

A DHCP Unique Identifier for a DHCP participant. Each DHCP client and server has exactly one DUID. See Section 11 for details of the ways in which a DUID may be constructed.¶

encapsulated option

A DHCP option that is usually only contained in another option. For example, the IA Address option is contained in IA_NA options (see Section 21.5). See Section 9 of [RFC7227] for a more complete definition.¶

IA

Identity Association: a collection of leases assigned to a client. Each IA has an associated IAID (see below). A client may have more than one IA assigned to it -- for example, one for each of its interfaces. Each IA holds one type of lease; for example, an identity association for non-temporary addresses (IA_NA) holds addresses, and an identity association for prefix delegation (IA_PD) holds delegated prefixes. Throughout this document, "IA" is used to refer to an identity association without identifying the type of a lease in the IA. This document defines three IA types: IA_NA, IA_TA (obsoleted), and IA_PD. Another IA type (IA_LL) was defined in [RFC8947] and more may be defined.¶

IA option(s)

In this document, one or more IA_NA, IA_TA (obsoleted), and/or IA_PD. Another IA type (IA_LL) was defined in [RFC8947] and more may be defined.¶

IAID

Identity Association Identifier: an identifier for an IA, chosen by the client. Each IA has an IAID, which is chosen to be unique among IAIDs for IAs of a specific type that belong to that client.¶

IA_NA

Identity Association for Non‑temporary Addresses: an IA that carries assigned addresses. See Section 21.4 for details on the IA_NA option.¶

IA_PD

Identity Association for Prefix Delegation: an IA that carries delegated prefixes. See Section 21.21 for details on the IA_PD option.¶

IA_TA

Identity Association for Temporary Addresses: an IA that carries temporary addresses (see [RFC8981]). This option is obsolete. See [RFC8415] for details.¶

lease

A contract by which the server grants the use of an address or delegated prefix to the client for a specified period of time.¶

message

A unit of data carried as the payload of a UDP datagram, exchanged among DHCP servers, relay agents, and clients.¶

Reconfigure key

A key supplied to a client by a server. Used to provide security for Reconfigure messages (see Section 7.3 for the list of available message types).¶

relaying

A DHCP relay agent relays DHCP messages between DHCP participants.¶

requesting router

The router that acts as a DHCP client and is requesting prefix(es) to be assigned. This document primarily uses the term "DHCP client" or "client" when discussing the "requesting router" functionality of prefix delegation (see Section 1).¶

retransmission

Another attempt to send the same DHCP message by a client or server, as a result of not receiving a valid response to the previously sent messages. The retransmitted message is typically modified prior to sending, as required by the DHCP specifications. In particular, the client updates the value of the Elapsed Time option in the retransmitted message.¶

RKAP

The Reconfiguration Key Authentication Protocol (see Section 20.4).¶

singleton option

An option that is allowed to appear only once as a top-level option or at any encapsulation level. Most options are singletons.¶

T1

The time interval after which the client is expected to contact the server that did the assignment to extend (renew) the lifetimes of the addresses assigned (via IA_NA option(s)) and/or prefixes delegated (via IA_PD option(s)) to the client. T1 is expressed as an absolute value in messages (in seconds), is conveyed within IA containers (currently the IA_NA and IA_PD options), and is interpreted as a time interval since the packet's reception. The value stored in the T1 field in IA options is referred to as the T1 value. The actual time when the timer expires is referred to as the T1 time.¶

T2

The time interval after which the client is expected to contact any available server to extend (rebind) the lifetimes of the addresses assigned (via IA_NA option(s)) and/or prefixes delegated (via IA_PD option(s)) to the client. T2 is expressed as an absolute value in messages (in seconds), is conveyed within IA containers (currently the IA_NA and IA_PD options), and is interpreted as a time interval since the packet's reception. The value stored in the T2 field in IA options is referred to as the T2 value. The actual time when the timer expires is referred to as the T2 time.¶

top-level option

An option conveyed in a DHCP message directly, i.e., not encapsulated in any other option, as described in Section 9 of [RFC7227].¶

transaction ID

An opaque value used to match responses with replies initiated by either a client or a server.¶

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).¶

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.5 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    |       /
  +----------+ +----------+     +----------+      /

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.¶

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. [RFC9096] section WPD-9 makes this Best Current Practice. That includes addresses leased out by DHCPv6 (IA_NA), prefixes delegated via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router Advertisements.¶

[RFC9096] section 3.3 further provides more 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]. 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).¶

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.¶

7.1. Multicast Addresses

DHCP makes use of the following multicast addresses:¶

All_DHCP_Relay_Agents_and_Servers (ff02::1:2)

A link-scoped multicast address used by a client to communicate with neighboring (i.e., on-link) relay agents and servers. All servers and relay agents are members of this multicast group.¶

All_DHCP_Servers (ff05::1:3)

A site-scoped multicast address used by a relay agent to communicate with servers, either because the relay agent wants to send messages to all servers or because it does not know the unicast addresses of the servers. Note that in order for a relay agent to use this address, it must have an address of sufficient scope to be reachable by the servers. All servers within the site are members of this multicast group on the interfaces that are within the site.¶

7.3. DHCP Message Types

DHCP defines the following message types. The formats of these messages are provided in Sections 8 and 9. Additional message types have been defined and may be defined in the future; see <https://www.iana.org/assignments/dhcpv6-parameters>. The numeric encoding for each message type is shown in parentheses.¶

SOLICIT (1)

A client sends a Solicit message to locate servers.¶

ADVERTISE (2)

A server sends an Advertise message to indicate that it is available for DHCP service, in response to a Solicit message received from a client.¶

REQUEST (3)

A client sends a Request message to request configuration parameters, including addresses and/or delegated prefixes, from a specific server.¶

CONFIRM (4)

A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected.¶

RENEW (5)

A client sends a Renew message to the server that originally provided the client's leases and configuration parameters to extend the lifetimes on the leases assigned to the client and to update other configuration parameters.¶

REBIND (6)

A client sends a Rebind message to any available server to extend the lifetimes on the leases assigned to the client and to update other configuration parameters; this message is sent after a client receives no response to a Renew message.¶

REPLY (7)

A server sends a Reply message containing assigned leases and configuration parameters in response to a Solicit, Request, Renew, or Rebind message received from a client. A server sends a Reply message containing configuration parameters in response to an Information-request message. A server sends a Reply message in response to a Confirm message confirming or denying that the addresses assigned to the client are appropriate to the link to which the client is connected. A server sends a Reply message to acknowledge receipt of a Release or Decline message.¶

RELEASE (8)

A client sends a Release message to the server that assigned leases to the client to indicate that the client will no longer use one or more of the assigned leases.¶

DECLINE (9)

A client sends a Decline message to a server to indicate that the client has determined that one or more addresses assigned by the server are already in use on the link to which the client is connected.¶

RECONFIGURE (10)

A server sends a Reconfigure message to a client to inform the client that the server has new or updated configuration parameters and that the client is to initiate a Renew⁠/Reply, Rebind/Reply, or Information‑request/Reply transaction with the server in order to receive the updated information.¶

INFORMATION-REQUEST (11)

A client sends an Information-request message to a server to request configuration parameters without the assignment of any leases to the client.¶

RELAY-FORW (12)

A relay agent sends a Relay-forward message to relay messages to servers, either directly or through another relay agent. The received message -- either a client message or a Relay-forward message from another relay agent -- is encapsulated in an option in the Relay-forward message.¶

RELAY-REPL (13)

A server sends a Relay-reply message to a relay agent containing a message that the relay agent delivers to a client. The Relay-reply message may be relayed by other relay agents for delivery to the destination relay agent.¶

The server encapsulates the client message as an option in the Relay-reply message, which the relay agent extracts and relays to the client.¶

7.6. Transmission and Retransmission Parameters

This section presents a table of values used to describe the message transmission behavior of clients and servers. Some of the values are adjusted by a randomization factor and backoffs (see Section 15). Transmissions may also be influenced by rate limiting (see Section 14.1).¶

7.7. Representation of Time Values and "Infinity" as a Time Value

All time values for lifetimes, T1, and T2 are unsigned 32-bit integers and are expressed in units of seconds. The value 0xffffffff is taken to mean "infinity" when used as a lifetime (as in [RFC4861]) or a value for T1 or T2.¶

Setting the valid lifetime of an address or a delegated prefix to 0xffffffff ("infinity") amounts to a permanent assignment of an address or delegation to a client and should only be used in cases where permanent assignments are desired.¶

Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). A client will never attempt to extend the lifetimes of any addresses in an IA with T1 set to 0xffffffff. A client will never attempt to use a Rebind message to locate a different server to extend the lifetimes of any addresses in an IA with T2 set to 0xffffffff.¶

11.1. DUID Contents

A DUID consists of a 2-octet type code represented in network byte order, followed by a variable number of octets that make up the actual identifier. The length of the DUID (not including the type code) is at least 1 octet and at most 128 octets. The following types are currently defined:¶

Formats for the variable field of the DUID for the first three of the above types are shown below. The fourth type, DUID-UUID [RFC6355], can be used in situations where there is a UUID stored in a device's firmware settings.¶

12.1. Identity Associations for Address Assignment

A client must associate at least one distinct IA with each of its network interfaces for which it is to request the assignment of IPv6 addresses from a DHCP server. The client uses the IAs assigned to an interface to obtain configuration information from a server for that interface. Each such IA must be associated with exactly one interface.¶

The configuration information in an IA_NA option consists of one or more IPv6 addresses along with the T1 and T2 values for the IA. See Section 21.4 for details regarding the representation of an IA_NA in a DHCP message.¶

Each address in an IA has a preferred lifetime and a valid lifetime, as defined in [RFC4862]. The lifetimes are transmitted from the DHCP server to the client in the IA Address option (see Section 21.6). The lifetimes apply to the use of addresses; see Section 5.5.4 of [RFC4862].¶

12.2. Identity Associations for Prefix Delegation

An IA_PD is different from an IA for address assignment in that it does not need to be associated with exactly one interface. One IA_PD can be associated with the client, with a set of interfaces, or with exactly one interface. A client configured to request delegated prefixes must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the server.¶

The configuration information in an IA_PD option consists of one or more prefixes along with the T1 and T2 values for the IA_PD. See Section 21.21 for details regarding the representation of an IA_PD in a DHCP message.¶

Each delegated prefix in an IA has a preferred lifetime and a valid lifetime, as defined in [RFC4862]. The lifetimes are transmitted from the DHCP server to the client in the IA Prefix option (see Section 21.22). The lifetimes apply to the use of delegated prefixes; see Section 5.5.4 of [RFC4862].¶

13.1. Selecting Addresses for Assignment to an IA_NA

A server selects addresses to be assigned to an IA_NA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from some combination of the following sources:¶

• The link to which the client is attached. The server determines the link as follows:¶

  • If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is a link-local address, then the client is on the same link to which the interface over which the message was received is attached.¶
  • If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface, identified by the link-address field in the message from the relay agent, is attached. According to [RFC6221], the server MUST ignore any link-address field whose value is zero. The link-address in this case may come from any of the Relay-forward messages encapsulated in the received Relay-forward, and in general the most encapsulated (closest Relay-forward to the client) has the most useful value.¶
• The DUID supplied by the client.¶
• Other information in options supplied by the client, e.g., IA Address options (see Section 21.6) that include the client's requests for specific addresses.¶
• Other information in options supplied by the relay agent.¶

By default, DHCP server implementations SHOULD NOT generate predictable addresses (see Section 4.7 of [RFC7721]). Server implementers are encouraged to review [RFC8981], [RFC7824], [RFC7707], and [RFC7943] as to possible considerations for how to generate addresses.¶

A server MUST NOT assign an address that is otherwise reserved for some other purpose. For example, a server MUST NOT assign addresses that use a reserved IPv6 Interface Identifier [RFC5453] [RFC7136] [IANA-RESERVED-IID].¶

See [RFC7969] for a more detailed discussion on how servers determine a client's location on the network.¶

14.1. Rate Limiting

In order to avoid prolonged message bursts that may be caused by possible logic loops, a DHCP client MUST limit the rate of DHCP messages it transmits or retransmits. One example is that a client obtains an address or delegated prefix but does not like the response, so it reverts back to the Solicit procedure, discovers the same (sole) server, requests an address or delegated prefix, and gets the same address or delegated prefix as before (as the server has this previously requested lease assigned to this client). This loop can repeat infinitely if there is not a quit/stop mechanism. Therefore, a client must not initiate transmissions too frequently.¶

A recommended method for implementing the rate-limiting function is a token bucket (see Appendix A of [RFC3290]), limiting the average rate of transmission to a certain number in a certain time interval. This method of bounding burstiness also guarantees that the long-term transmission rate will not be exceeded.¶

A transmission rate limit SHOULD be configurable. A possible default could be 20 packets in 20 seconds.¶

For a device that has multiple interfaces, the limit MUST be enforced on a per-interface basis.¶

Rate limiting of forwarded DHCP messages and server-side messages is out of scope for this specification.¶

14.2. Client Behavior when T1 and/or T2 Are 0

In certain cases, T1 and/or T2 values may be set to 0. Currently, there are two such cases:¶

1. a client received an IA_NA option (see Section 21.4) with a zero value¶
2. a client received an IA_PD option (see Section 21.21) with a zero value¶

This is an indication that the renew and rebind times are left to the discretion of the client. However, they are not completely discretionary.¶

When T1 and/or T2 values are set to 0, the client MUST choose a time to avoid packet storms. In particular, it MUST NOT transmit immediately. If the client received multiple IA options, it SHOULD pick renew and/or rebind transmission times so all IA options are handled in one exchange, if possible. The client MUST choose renew and rebind times to not violate rate-limiting restrictions as defined in Section 14.1.¶

17.1. Source Address and Interface Selection for Address Assignment

When a client sends a DHCP message to the All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send the message through the interface for which configuration information (including the addresses) is being requested. However, the client MAY send the message through another interface if the interface for which configuration is being requested is a logical interface without direct link attachment or the client is certain that two interfaces are attached to the same link.¶

18.2. Client Behavior

A client uses the Solicit message to discover DHCP servers configured to assign leases or return other configuration parameters on the link to which the client is attached.¶

A client uses Request, Renew, Rebind, Release, and Decline messages during the normal lifecycle of addresses and delegated prefixes. When a client detects that it may have moved to a new link, it uses Confirm if it only has addresses and Rebind if it has delegated prefixes (and addresses). It uses Information-request messages when it needs configuration information but no addresses and no prefixes.¶

When a client requests multiple IA option types or multiple instances of the same IA types in a Solicit, Request, Renew, or Rebind, it is possible that the available server(s) may only be configured to offer a subset of them. When possible, the client SHOULD use the best configuration available and continue to request the additional IAs in subsequent messages. This allows the client to maintain a single session and state machine. In practice, especially in the case of handling IA_NA and IA_PD requests [RFC7084], this situation should be rare or a result of a temporary operational error. Thus, it is more likely that the client will get all configuration if it continues, in each subsequent configuration exchange, to request all the configuration information it is programmed to try to obtain, including any stateful configuration options for which no results were returned in previous message exchanges.¶

Upon receipt of a Reconfigure message from the server, a client responds with a Renew, Rebind, or Information-request message as indicated by the Reconfigure Message option (see Section 21.19). The client SHOULD be suspicious of the Reconfigure message (they may be faked), and it MUST NOT abandon any resources it might have already obtained. The client SHOULD treat the Reconfigure message as if the T1 timer had expired. The client will expect the server to send IAs and/or other configuration information to the client in a Reply message.¶

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.4. Reception of Unicast Messages

The server is not supposed to accept unicast traffic from a client. The Server Unicast option (see Section 21.12) and UseMulticast status code (see Section 21.13) have been obsoleted and hence clients should no longer send messages to a server's unicast address nor receive the UseMulticast status code. However, a server that previously supported the Server Unicast option and is upgraded to not support it, may continue to receive unicast messages if it previously sent the client the Server Unicast option. But this causes no harm and the client will eventually switch back to sending multicast messages (such as after the lease's rebinding time is reached or the client is rebooted).¶

19.3. Construction of Relay-reply Messages

A server uses a Relay-reply message to (1) return a response to a client if the original message from the client was relayed to the server in a Relay-forward message or (2) send a Reconfigure message to a client if the server does not have an address it can use to send the message directly to the client.¶

A response to the client MUST be relayed through the same relay agents as the original client message. The server causes this to happen by creating a Relay-reply message that includes a Relay Message option (see Section 21.10) containing the message for the next relay agent in the return path to the client. The contained Relay-reply message contains another Relay Message option to be sent to the next relay agent, and so on. The server must record the contents of the peer-address fields in the received message so it can construct the appropriate Relay-reply message carrying the response from the server.¶

For example, if client C sent a message that was relayed by relay agent A to relay agent B and then to the server, the server would send the following Relay-reply message to relay agent B:¶

   msg-type:       RELAY-REPL
   hop-count:      1
   link-address:   0
   peer-address:   A
   Relay Message option containing the following:
      msg-type:     RELAY-REPL
      hop-count:    0
      link-address: address from link to which C is attached
      peer-address: C
      Relay Message option: <response from server>

When sending a Reconfigure message to a client through a relay agent, the server creates a Relay-reply message that includes a Relay Message option containing the Reconfigure message for the next relay agent in the return path to the client. The server sets the peer‑address field in the Relay-reply message header to the address of the client and sets the link-address field as required by the relay agent to relay the Reconfigure message to the client. The server obtains the addresses of the client and the relay agent through prior interaction with the client or through some external mechanism.¶

19.4. Interaction between Relay Agents and Servers

Each time a packet is relayed by a relay agent towards a server, a new encapsulation level is added around the packet. Each relay is allowed to insert additional options on the encapsulation level it added but MUST NOT change anything in the packet being encapsulated. If there are multiple relays between a client and a server, multiple encapsulations are used. Although it makes packet processing slightly more complex, it provides the major advantage of having a clear indication as to which relay inserted which option. The response packet is expected to travel through the same relays, but in reverse order. Each time a response packet is relayed back towards a client, one encapsulation level is removed.¶

In certain cases, relays can add one or more options. These options can be added for several reasons:¶

• First, relays can provide additional information about the client. That source of information is usually more trusted by a server administrator, as it comes from the network infrastructure rather than the client and cannot be easily spoofed. These options can be used by the server to determine its allocation policy.¶
• Second, a relay may need some information to send a response back to the client. Relay agents are expected to be stateless (not retain any state after a packet has been processed). A relay agent may include the Interface-Id option (see Section 21.18), which will be echoed back in the response. It can include other options and ask the server to echo one or more of the options back in the response. These options can then be used by the relay agent to send the response back to the client, or for other needs. The client will never see these options. See [RFC4994] for details.¶
• Third, sometimes a relay is the best device to provide values for certain options. A relay can insert an option into the packet being forwarded to the server and ask the server to pass that option back to the client. The client will receive that option. It should be noted that the server is the ultimate authority here, and -- depending on its configuration -- it may or may not send the option back to the client. See [RFC6422] for details.¶

For various reasons, servers may need to retain the relay information after the packet processing is completed. One is a bulk leasequery mechanism that may ask for all addresses and/or prefixes that were assigned via a specific relay. A second is for the reconfigure mechanism. The server may choose to not send the Reconfigure message directly to the client but rather to send it via relays. This particular behavior is considered an implementation detail and is out of scope for this document.¶

20.1. Security of Messages Sent between Servers and Relay Agents

Relay agents and servers that exchange messages can use IPsec as detailed in [RFC8213].¶

20.3. Replay Detection

The RDM field of the Authentication option (see Section 21.11) determines the type of replay detection used in the replay detection field.¶

If the RDM field contains 0x00, the replay detection field MUST be set to the value of a strictly monotonically increasing 64-bit unsigned integer (modulo 2^64). Using this technique can reduce the danger of replay attacks. This method MUST be supported by all Authentication option protocols. One choice might be to use the 64-bit NTP timestamp format [RFC5905]).¶

A client that receives a message with the RDM field set to 0x00 MUST compare its replay detection field with the previous value sent by that same server (based on the Server Identifier option; see Section 21.3) and only accept the message if the received value is greater and record this as the new value. If this is the first time a client processes an Authentication option sent by a server, the client MUST record the replay detection value and skip the replay detection check.¶

Servers that support the reconfigure mechanism MUST ensure that the replay detection value is retained between restarts. Failing to do so may cause clients to refuse Reconfigure messages sent by the server, effectively rendering the reconfigure mechanism useless.¶

20.4. Reconfiguration Key Authentication Protocol (RKAP)

RKAP provides protection against misconfiguration of a client caused by a Reconfigure message sent by a malicious DHCP server. In this protocol, a DHCP server sends a reconfigure key to the client in the initial exchange of DHCP messages. The client records the reconfigure key for use in authenticating subsequent Reconfigure messages from that server. The server then includes a Hashed Message Authentication Code (HMAC) computed from the reconfigure key in subsequent Reconfigure messages.¶

Both the reconfigure key sent from the server to the client and the HMAC in subsequent Reconfigure messages are carried as the authentication information in an Authentication option (see Section 21.11). The format of the authentication information is defined in the following section.¶

RKAP is used (initiated by the server) only if the client and server have negotiated to use Reconfigure messages.¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                 Value (128 bits)              |
   +-+-+-+-+-+-+-+-+                                               |
   .                                                               .
   .                                                               .
   .                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

21.1. Format of DHCP Options

The format of DHCP options is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          option-code          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          option-data                          |
   |                      (option-len octets)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

An unsigned integer identifying the specific option type carried in this option. A 2‑octet field.¶

option-len

An unsigned integer giving the length of the option-data field in this option in octets. A 2-octet field.¶

option-data

The data for the option; the format of this data depends on the definition of the option. A variable-length field (the length, in octets, is specified by option-len).¶

DHCP options are scoped by using encapsulation. Some options apply generally to the client, some are specific to an IA, and some are specific to the addresses within an IA. These latter two cases are discussed in Sections 21.4, 21.5, and 21.6.¶

21.2. Client Identifier Option

The Client Identifier option is used to carry a DUID (see Section 11) that identifies the client. The format of the Client Identifier option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        OPTION_CLIENTID        |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                              DUID                             .
   .                        (variable length)                      .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_CLIENTID (1).¶

option-len

Length of DUID in octets.¶

DUID

The DUID for the client.¶

21.3. Server Identifier Option

The Server Identifier option is used to carry a DUID (see Section 11) that identifies the server. The format of the Server Identifier option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        OPTION_SERVERID        |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                              DUID                             .
   .                        (variable length)                      .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_SERVERID (2).¶

option-len

Length of DUID in octets.¶

DUID

The DUID for the server.¶

21.4. Identity Association for Non-temporary Addresses Option

The Identity Association for Non-temporary Addresses (IA_NA) option is used to carry an IA_NA, the parameters associated with the IA_NA, and the non-temporary addresses associated with the IA_NA.¶

Addresses appearing in an IA_NA option are not temporary addresses (see Section 21.5).¶

The format of the IA_NA option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OPTION_IA_NA         |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IAID (4 octets)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              T1                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              T2                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                         IA_NA-options                         .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_IA_NA (3).¶

option-len

12 + length of IA_NA-options field.¶

IAID

The unique identifier for this IA_NA; the IAID must be unique among the identifiers for all of this client's IA_NAs. The number space for IA_NA IAIDs is separate from the number space for other IA option types (i.e., IA_PD). A 4‑octet field containing an unsigned integer.¶

T1

The time interval after which the client should contact the server from which the addresses in the IA_NA were obtained to extend the lifetimes of the addresses assigned to the IA_NA; T1 is a time duration relative to the current time expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

T2

The time interval after which the client should contact any available server to extend the lifetimes of the addresses assigned to the IA_NA; T2 is a time duration relative to the current time expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

IA_NA-options

Options associated with this IA_NA. A variable-length field (12 octets less than the value in the option-len field).¶

The IA_NA-options field encapsulates those options that are specific to this IA_NA. For example, all of the IA Address options (see Section 21.6) carrying the addresses associated with this IA_NA are in the IA_NA-options field.¶

Each IA_NA carries one "set" of non-temporary addresses; it is up to the server policy to determine how many addresses are assigned, but typically at most one address is assigned from each prefix assigned to the link to which the client is attached.¶

An IA_NA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_NA options (though each must have a unique IAID).¶

The status of any operations involving this IA_NA is indicated in a Status Code option (see Section 21.13) in the IA_NA-options field.¶

Note that an IA_NA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_NA have expired, the IA_NA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA_NA.¶

In a message sent by a client to a server, the T1 and T2 fields SHOULD be set to 0. The server MUST ignore any values in these fields in messages received from a client.¶

In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 times, unless values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2 and are calculated since reception of the message.¶

As per Section 7.7, the value 0xffffffff is taken to mean "infinity" and should be used carefully.¶

The server selects the T1 and T2 values to allow the client to extend the lifetimes of any addresses in the IA_NA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively. If the "shortest" preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets the T1 and T2 values to 0. The client MUST follow the rules defined in Section 14.2.¶

If a client receives an IA_NA with T1 greater than T2 and both T1 and T2 are greater than 0, the client discards the IA_NA option and processes the remainder of the message as though the server had not included the invalid IA_NA option.¶

21.5. Identity Association for Temporary Addresses Option

The Identity Association for Temporary Addresses (IA_TA) option is obsolete. Please refer to [RFC8415] for historical information on this option.¶

The client SHOULD NOT send this option. The server SHOULD NOT send this option. When the server receives IA_TA option, the option SHOULD be ignored and the message processing should continue as usual.¶

As this option was never popular among server or client implementations before being deprecated, any implementations that still attempt to send it are unlikely to have the option processed.¶

21.6. IA Address Option

The IA Address option is used to specify an address. In this document it is only specified to be encapsulated within an IA_NA. DHCPv6 Leasequery [RFC5007] makes use of the IA Address Option without encapsulating it in IA_NA. The IAaddr‑options field encapsulates those options that are specific to this address.¶

The format of the IA Address option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OPTION_IAADDR        |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         IPv6-address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      preferred-lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        valid-lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                        IAaddr-options                         .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_IAADDR (5).¶

option-len

24 + length of IAaddr-options field.¶

IPv6-address

An IPv6 address. A client MUST NOT form an implicit prefix with a length other than 128 for this address. A 16-octet field.¶

preferred-lifetime

The preferred lifetime for the address in the option, expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

valid-lifetime

The valid lifetime for the address in the option, expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

IAaddr-options

Options associated with this address. A variable-length field (24 octets less than the value in the option-len field).¶

In a message sent by a client to a server, the preferred-lifetime and valid-lifetime fields SHOULD be set to 0. The server MUST ignore any received values.¶

The client SHOULD NOT send the IA Address option with an unspecified address (::).¶

In a message sent by a server to a client, the client MUST use the values in the preferred-lifetime and valid-lifetime fields for the preferred and valid lifetimes. The values in these fields are the number of seconds remaining in each lifetime.¶

The client MUST discard any addresses for which the preferred lifetime is greater than the valid lifetime.¶

As per Section 7.7, if the valid lifetime of an address is 0xffffffff, it is taken to mean "infinity" and should be used carefully.¶

More than one IA Address option can appear in an IA_NA option.¶

The status of any operations involving this IA Address is indicated in a Status Code option in the IAaddr-options field, as specified in Section 21.13.¶

21.7. Option Request Option

The Option Request option is used to identify a list of options in a message between a client and a server. The format of the Option Request option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           OPTION_ORO          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    requested-option-code-1    |    requested-option-code-2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_ORO (6).¶

option-len

2 * number of requested options.¶

requested-option-code-n

The option code for an option requested by the client. Each option code is a 2‑octet field containing an unsigned integer.¶

A client MUST include an Option Request option in a Solicit, Request, Renew, Rebind, or Information-request message to inform the server about options the client wants the server to send to the client. For certain message types, some option codes MUST be included in the Option Request option; see [IANA-OPTION-DETAILS] for details.¶

The Option Request option MUST NOT include the following options:¶

• Client Identifier (see Section 21.2)¶
• Server Identifier (see Section 21.3)¶
• IA_NA (see Section 21.4)¶
• IA_TA (option obsoleted, see Section 21.5)¶
• IA_PD (see Section 21.21)¶
• IA Address (see Section 21.6)¶
• IA Prefix (see Section 21.22)¶
• Option Request (this section)¶
• Elapsed Time (see Section 21.9)¶
• Preference (see Section 21.8)¶
• Relay Message (see Section 21.10)¶
• Authentication (see Section 21.11)¶
• Server Unicast (option obsoleted, see Section 21.12)¶
• Status Code (see Section 21.13)¶
• Rapid Commit (see Section 21.14)¶
• User Class (see Section 21.15)¶
• Vendor Class (see Section 21.16)¶
• Interface-Id (see Section 21.18)¶
• Reconfigure Message (see Section 21.19)¶
• Reconfigure Accept (see Section 21.20)¶

Other top-level options MUST appear in the Option Request option or they will not be sent by the server. Only top-level options MAY appear in the Option Request option. Options encapsulated in a container option SHOULD NOT appear in an Option Request option; see [RFC7598] for an example of container options. However, options MAY be defined that specify exceptions to this restriction on including encapsulated options in an Option Request option. For example, 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]. See [IANA-OPTION-DETAILS].¶

21.8. Preference Option

The Preference option is sent by a server to a client to control the selection of a server by the client.¶

The format of the Preference option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_PREFERENCE       |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  pref-value   |
   +-+-+-+-+-+-+-+-+

option-code

OPTION_PREFERENCE (7).¶

option-len

1.¶

pref-value

The preference value for the server in this message. A 1‑octet unsigned integer.¶

A server MAY include a Preference option in an Advertise message to control the selection of a server by the client. See Section 18.2.9 for information regarding the use of the Preference option by the client and the interpretation of the Preference option data value.¶

21.9. Elapsed Time Option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_ELAPSED_TIME      |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          elapsed-time         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_ELAPSED_TIME (8).¶

option-len

2.¶

elapsed-time

The amount of time since the client began its current DHCP transaction. This time is expressed in hundredths of a second (10^‑2 seconds). A 2-octet field containing an unsigned integer.¶

A client MUST include an Elapsed Time option in messages to indicate how long the client has been trying to complete a DHCP message exchange. The elapsed time is measured from the time at which the client sent the first message in the message exchange, and the elapsed-time field is set to 0 in the first message in the message exchange. Servers and relay agents use the data value in this option as input to policy that controls how a server responds to a client message. For example, the Elapsed Time option allows a secondary DHCP server to respond to a request when a primary server has not answered in a reasonable time. The elapsed-time value is a 16-bit (2-octet) unsigned integer. The client uses the value 0xffff to represent any elapsed-time values greater than the largest time value that can be represented in the Elapsed Time option.¶

21.10. Relay Message Option

The Relay Message option carries a DHCP message in a Relay-forward or Relay-reply message.¶

The format of the Relay Message option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        OPTION_RELAY_MSG       |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                       DHCP-relay-message                      .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_RELAY_MSG (9).¶

option-len

Length of DHCP-relay-message field.¶

DHCP-relay-message

In a Relay-forward message, the received message, relayed verbatim to the next relay agent or server; in a Relay-reply message, the message to be copied and relayed to the relay agent or client whose address is in the peer-address field of the Relay-reply message. The length, in octets, is specified by option-len.¶

21.11. Authentication Option

The Authentication option carries authentication information to authenticate the identity and contents of DHCP messages. The use of the Authentication option is described in Section 20. The delayed authentication protocol, defined in [RFC3315], was obsoleted by [RFC8415]. The format of the Authentication option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OPTION_AUTH          |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   protocol    |   algorithm   |      RDM      |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   |          replay detection (64 bits)           +-+-+-+-+-+-+-+-+
   |                                               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   .                   authentication information                  .
   .                       (variable length)                       .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_AUTH (11).¶

option-len

11 + length of authentication information field.¶

protocol

The authentication protocol used in this Authentication option. A 1‑octet unsigned integer.¶

algorithm

The algorithm used in the authentication protocol. A 1‑octet unsigned integer.¶

RDM

The replay detection method used in this Authentication option. A 1‑octet unsigned integer.¶

replay detection

The replay detection information for the RDM. A 64-bit (8-octet) field.¶

authentication information

The authentication information, as specified by the protocol and algorithm used in this Authentication option. A variable-length field (11 octets less than the value in the option-len field).¶

IANA maintains a registry for the protocol, algorithm, and RDM values at <https://www.iana.org/assignments/auth-namespaces>.¶

21.12. Server Unicast Option

The Server Unicast option is obsolete. Please refer to [RFC8415] for historical information on this option.¶

The client SHOULD NOT request this option in ORO. The server SHOULD NOT send this option, even when requested by clients. When any entity receives server unicast option, the option SHOULD be ignored and the message processing should continue as usual.¶

As this option was not very popular and it typically required special configuration by those server implementations that did support it, clients still requesting this option in ORO are increasingly unlikely to get it.¶

21.13. Status Code Option

This option returns a status indication related to the DHCP message or option in which it appears. The format of the Status Code option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_STATUS_CODE      |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          status-code          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   .                                                               .
   .                        status-message                         .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_STATUS_CODE (13).¶

option-len

2 + length of status-message field.¶

status-code

The numeric code for the status encoded in this option. A 2-octet field containing an unsigned integer.¶

status-message

A UTF-8 encoded [RFC3629] text string suitable for display to an end user. MUST NOT be null-terminated. A variable-length field (2 octets less than the value in the option-len field).¶

A Status Code option may appear in the "options" field of a DHCP message and/or in the "options" field of another option. If the Status Code option does not appear in a message in which the option could appear, the status of the message is assumed to be Success.¶

The status-code values previously defined by [RFC3315] and [RFC3633] are:¶

See the "Status Codes" registry at <https://www.iana.org/assignments/dhcpv6-parameters> for the current list of status codes.¶

21.14. Rapid Commit Option

The Rapid Commit option is used to signal the use of the two-message exchange for address assignment. The format of the Rapid Commit option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_RAPID_COMMIT      |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_RAPID_COMMIT (14).¶

option-len

0.¶

A client MAY include this option in a Solicit message if the client is prepared to perform the Solicit/Reply message exchange described in Section 18.2.1.¶

A server MUST include this option in a Reply message sent in response to a Solicit message when completing the Solicit/Reply message exchange.¶

DISCUSSION:¶

• Each server that responds with a Reply to a Solicit that includes a Rapid Commit option will commit the leases in the Reply message to the client but will not receive any confirmation that the client has received the Reply message. Therefore, if more than one server responds to a Solicit that includes a Rapid Commit option, all but one server will commit leases that are not actually used by the client; this could result in incorrect address information in DNS if the DHCP servers update DNS [RFC4704], and responses to leasequery requests [RFC5007] may include information on leases not in use by the client.¶
• The problem of unused leases can be minimized by designing the DHCP service so that only one server responds to the Solicit or by using relatively short lifetimes for newly assigned leases.¶

21.15. User Class Option

The User Class option is used by a client to identify the type or category of users or applications it represents.¶

The format of the User Class option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_USER_CLASS       |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          user-class-data                      .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_USER_CLASS (15).¶

option-len

Length of user-class-data field.¶

user-class-data

The user classes carried by the client. The length, in octets, is specified by option‑len.¶

The information contained in the data area of this option is contained in one or more opaque fields that represent the user class or classes of which the client is a member. A server selects configuration information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client.¶

The data area of the User Class option MUST contain one or more instances of user-class-data information. Each instance of user‑class-data is formatted as follows:¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
   |        user-class-len         |          opaque-data          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

The user-class-len field is 2 octets long and specifies the length of the opaque user-class-data in network byte order.¶

A server interprets the classes identified in this option according to its configuration to select the appropriate configuration information for the client. A server may use only those user classes that it is configured to interpret in selecting configuration information for a client and ignore any other user classes. In response to a message containing a User Class option, a server may include a User Class option containing those classes that were successfully interpreted by the server so that the client can be informed of the classes interpreted by the server.¶

21.16. Vendor Class Option

This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware configuration. The format of the Vendor Class option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_VENDOR_CLASS      |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       enterprise-number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                       vendor-class-data                       .
   .                             . . .                             .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_VENDOR_CLASS (16).¶

option-len

4 + length of vendor-class-data field.¶

enterprise-number

The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4‑octet field containing an unsigned integer.¶

vendor-class-data

The hardware configuration of the node on which the client is running. A variable‑length field (4 octets less than the value in the option-len field).¶

The vendor-class-data field is composed of a series of separate items, each of which describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client.¶

Each instance of vendor-class-data is formatted as follows:¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
   |       vendor-class-len        |          opaque-data          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

The vendor-class-len field is 2 octets long and specifies the length of the opaque vendor-class-data in network byte order.¶

Servers and clients MUST NOT include more than one instance of OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances.¶

21.17. Vendor-specific Information Option

This option is used by clients and servers to exchange vendor-specific information.¶

The format of the Vendor-specific Information option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_VENDOR_OPTS       |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       enterprise-number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                       vendor-option-data                      .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_VENDOR_OPTS (17).¶

option-len

4 + length of vendor-option-data field.¶

enterprise-number

The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4‑octet field containing an unsigned integer.¶

vendor-option-data

Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in the option-len field).¶

The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. A DHCP client that does not receive requested vendor-specific information will still configure the node's IPv6 stack to be functional.¶

The vendor-option-data field MUST be encoded as a sequence of code/length/value fields of format identical to the DHCP options (see Section 21.1). The suboption codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the suboptions is formatted as follows:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          sub-opt-code         |         suboption-len         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                        suboption-data                        .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

sub-opt-code

The code for the suboption. A 2-octet field.¶

suboption-len

An unsigned integer giving the length of the suboption-data field in this suboption in octets. A 2-octet field.¶

suboption-data

The data area for the suboption. The length, in octets, is specified by sub‑option‑len.¶

Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific Information option MAY contain multiple suboptions.¶

A client that is interested in receiving a Vendor-specific Information option:¶

• MUST specify the Vendor-specific Information option in an Option Request option.¶
• MAY specify an associated Vendor Class option (see Section 21.16).¶
• MAY specify the Vendor-specific Information option with appropriate data.¶

Servers only return the Vendor-specific Information options if specified in Option Request options from clients and:¶

• MAY use the Enterprise Numbers in the associated Vendor Class options to restrict the set of Enterprise Numbers in the Vendor‑specific Information options returned.¶
• MAY return all configured Vendor-specific Information options.¶
• MAY use other information in the packet or in its configuration to determine which set of Enterprise Numbers in the Vendor-specific Information options to return.¶

21.18. Interface-Id Option

The relay agent MAY send the Interface-Id option to identify the interface on which the client message was received. If a relay agent receives a Relay-reply message with an Interface-Id option, the relay agent relays the message to the client through the interface identified by the option.¶

The format of the Interface-Id option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_INTERFACE_ID      |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                         interface-id                          .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_INTERFACE_ID (18).¶

option-len

Length of interface-id field.¶

interface-id

An opaque value of arbitrary length generated by the relay agent to identify one of the relay agent's interfaces. The length, in octets, is specified by option-len.¶

The server MUST copy the Interface-Id option from the Relay-forward message into the Relay-reply message the server sends to the relay agent in response to the Relay-forward message. This option MUST NOT appear in any message except a Relay-forward or Relay-reply message.¶

Servers MAY use the interface-id field for parameter assignment policies. The interface-id value SHOULD be considered an opaque value, with policies based on exact match only; that is, the interface-id field SHOULD NOT be internally parsed by the server. The interface-id value for an interface SHOULD be stable and remain unchanged -- for example, after the relay agent is restarted; if the interface-id value changes, a server will not be able to use it reliably in parameter assignment policies.¶

21.19. Reconfigure Message Option

A server includes a Reconfigure Message option in a Reconfigure message to indicate to the client whether the client responds with a Renew message, a Rebind message, or an Information-request message. The format of the Reconfigure Message option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_RECONF_MSG        |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    msg-type   |
   +-+-+-+-+-+-+-+-+

option-code

OPTION_RECONF_MSG (19).¶

option-len

1.¶

msg-type

5 for Renew message, 6 for Rebind message, 11 for Information-request message. A 1‑octet unsigned integer.¶

The Reconfigure Message option can only appear in a Reconfigure message.¶

21.20. Reconfigure Accept Option

A client uses the Reconfigure Accept option to announce to the server whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages. In the absence of this option, the default behavior is that the client is unwilling to accept Reconfigure messages. The format of the Reconfigure Accept option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     OPTION_RECONF_ACCEPT      |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_RECONF_ACCEPT (20).¶

option-len

0.¶

21.21. Identity Association for Prefix Delegation Option

The IA_PD option is used to carry a prefix delegation identity association, the parameters associated with the IA_PD, and the prefixes associated with it. The format of the IA_PD option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         OPTION_IA_PD          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IAID (4 octets)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              T1                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              T2                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          IA_PD-options                        .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_IA_PD (25).¶

option-len

12 + length of IA_PD-options field.¶

IAID

The unique identifier for this IA_PD; the IAID must be unique among the identifiers for all of this client's IA_PDs. The number space for IA_PD IAIDs is separate from the number space for other IA option types (i.e., IA_NA). A 4‑octet field containing an unsigned integer.¶

T1

The time interval after which the client should contact the server from which the prefixes in the IA_PD were obtained to extend the lifetimes of the prefixes delegated to the IA_PD; T1 is a time duration relative to the message reception time expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

T2

The time interval after which the client should contact any available server to extend the lifetimes of the prefixes assigned to the IA_PD; T2 is a time duration relative to the message reception time expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

IA_PD-options

Options associated with this IA_PD. A variable-length field (12 octets less than the value in the option-len field).¶

The IA_PD-options field encapsulates those options that are specific to this IA_PD. For example, all of the IA Prefix options (see Section 21.22) carrying the prefixes associated with this IA_PD are in the IA_PD-options field.¶

An IA_PD option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_PD options (though each must have a unique IAID).¶

The status of any operations involving this IA_PD is indicated in a Status Code option (see Section 21.13) in the IA_PD-options field.¶

Note that an IA_PD has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the prefixes in an IA_PD have expired, the IA_PD can be considered as having expired. T1 and T2 fields are included to give the server explicit control over when a client should contact the server about a specific IA_PD.¶

In a message sent by a client to a server, the T1 and T2 fields SHOULD be set to 0. The server MUST ignore any values in these fields in messages received from a client.¶

In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 timers, unless values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2.¶

The server selects the T1 and T2 times to allow the client to extend the lifetimes of any prefixes in the IA_PD before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the prefixes in the IA_PD that the server is willing to extend, respectively. If the time at which the prefixes in an IA_PD are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. The client MUST follow the rules defined in Section 14.2.¶

If a client receives an IA_PD with T1 greater than T2 and both T1 and T2 are greater than 0, the client discards the IA_PD option and processes the remainder of the message as though the server had not included the IA_PD option.¶

21.22. IA Prefix Option

The IA Prefix option is used to specify a prefix associated with an IA_PD. The IA Prefix option must be encapsulated in the IA_PD‑options field of an IA_PD option (see Section 21.21).¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        OPTION_IAPREFIX        |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      preferred-lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        valid-lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | prefix-length |                                               |
   +-+-+-+-+-+-+-+-+          IPv6-prefix                          |
   |                           (16 octets)                         |
   |                                                               |
   |                                                               |
   |                                                               |
   |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               .
   +-+-+-+-+-+-+-+-+                                               .
   .                       IAprefix-options                        .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_IAPREFIX (26).¶

option-len

25 + length of IAprefix-options field.¶

preferred-lifetime

The preferred lifetime for the prefix in the option, expressed in units of seconds. A value of 0xffffffff represents "infinity" (see Section 7.7). A 4‑octet field containing an unsigned integer.¶

valid-lifetime

The valid lifetime for the prefix in the option, expressed in units of seconds. A value of 0xffffffff represents "infinity". A 4‑octet field containing an unsigned integer.¶

prefix-length

Length for this prefix in bits. A 1‑octet unsigned integer.¶

IPv6-prefix

An IPv6 prefix. A 16-octet field.¶

IAprefix-options

Options associated with this prefix. A variable-length field (25 octets less than the value in the option-len field).¶

In a message sent by a client to a server, the preferred-lifetime and valid-lifetime fields SHOULD be set to 0. The server MUST ignore any received values in these lifetime fields.¶

The client SHOULD NOT send an IA Prefix option with 0 in the "prefix‑length" field (and an unspecified value (::) in the "IPv6‑prefix" field). A client MAY send a non-zero value in the "prefix-length" field and the unspecified value (::) in the "IPv6‑prefix" field to indicate a preference for the size of the prefix to be delegated. See [RFC8168] for further details on prefix-length hints.¶

The client MUST discard any prefixes for which the preferred lifetime is greater than the valid lifetime.¶

The values in the preferred-lifetime and valid-lifetime fields are the number of seconds remaining in each lifetime. See Section 18.2.10.1 for more details on how these values are used for delegated prefixes.¶

As per Section 7.7, the value of 0xffffffff for the preferred lifetime or the valid lifetime is taken to mean "infinity" and should be used carefully.¶

An IA Prefix option may appear only in an IA_PD option. More than one IA Prefix option can appear in a single IA_PD option.¶

The status of any operations involving this IA Prefix option is indicated in a Status Code option (see Section 21.13) in the IAprefix‑options field.¶

21.23. Information Refresh Time Option

This option is requested by clients and returned by servers to specify an upper bound for how long a client should wait before refreshing information retrieved from a DHCP server. It is only used in Reply messages in response to Information-request messages. In other messages, there will usually be other information that indicates when the client should contact the server, e.g., T1/T2 times and lifetimes. This option is useful when the configuration parameters change or during a renumbering event, as clients running in the stateless mode will be able to update their configuration.¶

The format of the Information Refresh Time option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |OPTION_INFORMATION_REFRESH_TIME|         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   information-refresh-time                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_INFORMATION_REFRESH_TIME (32).¶

option-len

4.¶

information-refresh-time

Time duration relative to the current time, expressed in units of seconds. A 4‑octet field containing an unsigned integer.¶

A DHCP client MUST request this option in the Option Request option (see Section 21.7) when sending Information-request messages. A client MUST NOT request this option in the Option Request option in any other messages.¶

A server sending a Reply to an Information-request message SHOULD include this option if it is requested in the Option Request option of the Information-request. The option value MUST NOT be smaller than IRT_MINIMUM. This option MUST only appear in the top-level options area of Reply messages.¶

If the Reply to an Information-request message does not contain this option, the client MUST behave as if the option with the value IRT_DEFAULT was provided.¶

A client MUST use the refresh time IRT_MINIMUM if it receives the option with a value less than IRT_MINIMUM.¶

As per Section 7.7, the value 0xffffffff is taken to mean "infinity" and implies that the client should not refresh its configuration data without some other trigger (such as detecting movement to a new link).¶

If a client contacts the server to obtain new data or refresh some existing data before the refresh time expires, then it SHOULD also refresh all data covered by this option.¶

When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information‑request as specified in Section 18.2.6, except that the client MUST delay sending the first Information-request by a random amount of time between 0 and INF_MAX_DELAY.¶

A client MAY have a maximum value for the refresh time, where that value is used whenever the client receives this option with a value higher than the maximum. This also means that the maximum value is used when the received value is "infinity". A maximum value might make the client less vulnerable to attacks based on forged DHCP messages. Without a maximum value, a client may be made to use wrong information for a possibly infinite period of time. There may, however, be reasons for having a very long refresh time, so it may be useful for this maximum value to be configurable.¶

21.24. SOL_MAX_RT Option

A DHCP server sends the SOL_MAX_RT option to a client to override the default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option replaces the default value defined in Section 7.6. One use for the SOL_MAX_RT option is to set a higher value for SOL_MAX_RT; this reduces the Solicit traffic from a client that has not received a response to its Solicit messages.¶

The format of the SOL_MAX_RT option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_SOL_MAX_RT        |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SOL_MAX_RT value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_SOL_MAX_RT (82).¶

option-len

4.¶

SOL_MAX_RT value

Overriding value for SOL_MAX_RT in seconds; MUST be in this range: 60 <= "value" <= 86400 (1 day). A 4‑octet field containing an unsigned integer.¶

A DHCP client MUST include the SOL_MAX_RT option code in any Option Request option (see Section 21.7) it sends in a Solicit message.¶

The DHCP server MAY include the SOL_MAX_RT option in any response it sends to a client that has included the SOL_MAX_RT option code in an Option Request option. The SOL_MAX_RT option is sent as a top-level option in the message to the client.¶

A DHCP client MUST ignore any SOL_MAX_RT option values that are less than 60 or more than 86400.¶

If a DHCP client receives a message containing a SOL_MAX_RT option that has a valid value for SOL_MAX_RT, the client MUST set its internal SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT option. This value of SOL_MAX_RT is then used by the retransmission mechanism defined in Sections 15 and 18.2.1.¶

The purpose of this mechanism is to give network administrators a way to avoid excessive DHCP traffic if all DHCP servers become unavailable. Therefore, this value is expected to be retained for as long as practically possible.¶

An updated SOL_MAX_RT value applies only to the network interface on which the client received the SOL_MAX_RT option.¶

21.25. INF_MAX_RT Option

A DHCP server sends the INF_MAX_RT option to a client to override the default value of INF_MAX_RT. The value of INF_MAX_RT in the option replaces the default value defined in Section 7.6. One use for the INF_MAX_RT option is to set a higher value for INF_MAX_RT; this reduces the Information-request traffic from a client that has not received a response to its Information-request messages.¶

The format of the INF_MAX_RT option is:¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_INF_MAX_RT        |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       INF_MAX_RT value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_INF_MAX_RT (83).¶

option-len

4.¶

INF_MAX_RT value

Overriding value for INF_MAX_RT in seconds; MUST be in this range: 60 <= "value" <= 86400 (1 day). A 4‑octet field containing an unsigned integer.¶

A DHCP client MUST include the INF_MAX_RT option code in any Option Request option (see Section 21.7) it sends in an Information-request message.¶

The DHCP server MAY include the INF_MAX_RT option in any response it sends to a client that has included the INF_MAX_RT option code in an Option Request option. The INF_MAX_RT option is a top-level option in the message to the client.¶

A DHCP client MUST ignore any INF_MAX_RT option values that are less than 60 or more than 86400.¶

If a DHCP client receives a message containing an INF_MAX_RT option that has a valid value for INF_MAX_RT, the client MUST set its internal INF_MAX_RT parameter to the value contained in the INF_MAX_RT option. This value of INF_MAX_RT is then used by the retransmission mechanism defined in Sections 15 and 18.2.6.¶

An updated INF_MAX_RT value applies only to the network interface on which the client received the INF_MAX_RT option.¶