RFC 8415
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 154
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Part 4 of 14 – Pages 23 to 37
7. DHCP Constants
This section describes various program and networking constants used by DHCP.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.2. UDP Ports
Clients listen for DHCP messages on UDP port 546. Servers and relay
agents listen for DHCP messages on UDP port 547.
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.4. DHCP Option Codes
DHCP makes extensive use of options in messages; some of these are
defined later, in Section 21. Additional options are defined in
other documents or may be defined in the future (see [RFC7227] for
guidance on new option definitions).
7.5. Status Codes
DHCP uses status codes to communicate the success or failure of
operations requested in messages from clients and servers and to
provide additional information about the specific cause of the
failure of a message. The specific status codes are defined in
Section 21.13.
If the Status Code option (see Section 21.13) does not appear in a
message in which the option could appear, the status of the message
is assumed to be Success.
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). +-----------------+------------------+------------------------------+ | Parameter | Default | Description | +-----------------+------------------+------------------------------+ | SOL_MAX_DELAY | 1 sec | Max delay of first Solicit | | | | | | SOL_TIMEOUT | 1 sec | Initial Solicit timeout | | | | | | SOL_MAX_RT | 3600 secs | Max Solicit timeout value | | | | | | REQ_TIMEOUT | 1 sec | Initial Request timeout | | | | | | REQ_MAX_RT | 30 secs | Max Request timeout value | | | | | | REQ_MAX_RC | 10 | Max Request retry attempts | | | | | | CNF_MAX_DELAY | 1 sec | Max delay of first Confirm | | | | | | CNF_TIMEOUT | 1 sec | Initial Confirm timeout | | | | | | CNF_MAX_RT | 4 secs | Max Confirm timeout | | | | | | CNF_MAX_RD | 10 secs | Max Confirm duration | | | | | | REN_TIMEOUT | 10 secs | Initial Renew timeout | | | | | | REN_MAX_RT | 600 secs | Max Renew timeout value | | | | | | REB_TIMEOUT | 10 secs | Initial Rebind timeout | | | | | | REB_MAX_RT | 600 secs | Max Rebind timeout value | | | | | | INF_MAX_DELAY | 1 sec | Max delay of first | | | | Information-request | | | | | | INF_TIMEOUT | 1 sec | Initial Information-request | | | | timeout | | | | | | INF_MAX_RT | 3600 secs | Max Information-request | | | | timeout value | | | | |
| REL_TIMEOUT | 1 sec | Initial Release timeout | | | | | | REL_MAX_RC | 4 | Max Release retry attempts | | | | | | DEC_TIMEOUT | 1 sec | Initial Decline timeout | | | | | | DEC_MAX_RC | 4 | Max Decline retry attempts | | | | | | REC_TIMEOUT | 2 secs | Initial Reconfigure timeout | | | | | | REC_MAX_RC | 8 | Max Reconfigure attempts | | | | | | HOP_COUNT_LIMIT | 8 | Max hop count in a | | | | Relay-forward message | | | | | | IRT_DEFAULT | 86400 secs (24 | Default information refresh | | | hours) | time | | | | | | IRT_MINIMUM | 600 secs | Min information refresh time | | | | | | MAX_WAIT_TIME | 60 secs | Max required time to wait | | | | for a response | +-----------------+------------------+------------------------------+ Table 1: Transmission and Retransmission Parameters7.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.
8. Client/Server Message Formats
All DHCP messages sent between clients and servers share an identical fixed-format header and a variable-format area for options. All values in the message header and in options are in network byte order. Options are stored serially in the "options" field, with no padding between the options. Options are byte-aligned but are not aligned in any other way (such as on 2-byte or 4-byte boundaries). The following diagram illustrates the format of DHCP messages sent between clients and servers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable number and length) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Client/Server Message Format msg-type Identifies the DHCP message type; the available message types are listed in Section 7.3. A 1-octet field. transaction-id The transaction ID for this message exchange. A 3-octet field. options Options carried in this message; options are described in Section 21. A variable-length field (4 octets less than the size of the message).
9. Relay Agent/Server Message Formats
Relay agents exchange messages with other relay agents and servers to relay messages between clients and servers that are not connected to the same link. All values in the message header and in options are in network byte order. Options are stored serially in the "options" field, with no padding between the options. Options are byte-aligned but are not aligned in any other way (such as on 2-byte or 4-byte boundaries). There are two relay agent messages (Relay-forward and Relay-reply), which share the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | hop-count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | link-address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | peer-address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Relay Agent/Server Message Format
The following sections describe the use of the relay agent message header.9.1. Relay-forward Message
The following table defines the use of message fields in a Relay-forward message. msg-type RELAY-FORW (12). A 1-octet field. hop-count Number of relay agents that have already relayed this message. A 1-octet field. link-address An address that may be used by the server to identify the link on which the client is located. This is typically a globally scoped unicast address (i.e., GUA or ULA), but see the discussion in Section 19.1.1. A 16-octet field. peer-address The address of the client or relay agent from which the message to be relayed was received. A 16-octet field. options MUST include a Relay Message option (see Section 21.10); MAY include other options, such as the Interface-Id option (see Section 21.18), added by the relay agent. A variable-length field (34 octets less than the size of the message). See Section 13.1 for an explanation of how the link-address field is used.9.2. Relay-reply Message
The following table defines the use of message fields in a Relay-reply message. msg-type RELAY-REPL (13). A 1-octet field. hop-count Copied from the Relay-forward message. A 1-octet field. link-address Copied from the Relay-forward message. A 16-octet field.
peer-address Copied from the Relay-forward message.
A 16-octet field.
options MUST include a Relay Message option (see
Section 21.10); MAY include other options,
such as the Interface-Id option (see
Section 21.18). A variable-length field
(34 octets less than the size of the
message).
10. Representation and Use of Domain Names
So that domain names may be encoded uniformly, a domain name or a
list of domain names is encoded using the technique described in
Section 3.1 of [RFC1035]. A domain name, or list of domain names, in
DHCP MUST NOT be stored in compressed form as described in
Section 4.1.4 of [RFC1035].
11. DHCP Unique Identifier (DUID)
Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients for the selection of configuration parameters and in
the association of IAs with clients. DHCP clients use DUIDs to
identify a server in messages where a server needs to be identified.
See Sections 21.2 and 21.3 for details regarding the representation
of a DUID in a DHCP message.
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers SHOULD NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future. It should be noted that an attempt to
parse a DUID to obtain a client's link-layer address is unreliable,
as there is no guarantee that the client is still using the same
link-layer address as when it generated its DUID. Also, such an
attempt will be more and more unreliable as more clients adopt
privacy measures such as those defined in [RFC7844]. If this
capability is required, it is recommended to rely on the Client
Link-Layer Address option instead [RFC6939].
The DUID is carried in an option because it may be variable in length
and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server. That is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware or changes to virtual interfaces (e.g.,
logical PPP (over Ethernet) interfaces that may come and go in Customer Premises Equipment routers). The client may change its DUID as specified in [RFC7844]. The motivation for having more than one type of DUID is that the DUID must be globally unique and must also be easy to generate. The sort of globally unique identifier that is easy to generate for any given device can differ quite widely. Also, some devices may not contain any persistent storage. Retaining a generated DUID in such a device is not possible, so the DUID scheme must accommodate such devices.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: +------+------------------------------------------------------+ | Type | Description | +------+------------------------------------------------------+ | 1 | Link-layer address plus time | | 2 | Vendor-assigned unique ID based on Enterprise Number | | 3 | Link-layer address | | 4 | Universally Unique Identifier (UUID) [RFC6355] | +------+------------------------------------------------------+ Table 2: DUID Types 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.11.2. DUID Based on Link-Layer Address Plus Time (DUID-LLT)
This type of DUID consists of a 2-octet type field containing the value 1, a 2-octet hardware type code, and 4 octets containing a time value, followed by the link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated, represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by IANA; see [IANA-HARDWARE-TYPES]. Both the time and the hardware type are stored in network byte order. For Ethernet hardware types, the link-layer address is stored in canonical form, as described in [RFC2464].
The following diagram illustrates the format of a DUID-LLT: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID-Type (1) | hardware type (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DUID-LLT Format The choice of network interface can be completely arbitrary, as long as that interface provides a globally unique link-layer address for the link type; the same DUID-LLT SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID-LLT. Clients and servers using this type of DUID MUST store the DUID-LLT in stable storage and MUST continue to use this DUID-LLT even if the network interface used to generate the DUID-LLT is removed. Clients and servers that do not have any stable storage MUST NOT use this type of DUID. Clients and servers that use this DUID SHOULD attempt to configure the time prior to generating the DUID, if that is possible, and MUST use some sort of time source (for example, a real-time clock) in generating the DUID, even if that time source could not be configured prior to generating the DUID. The use of a time source makes it unlikely that two identical DUID-LLTs will be generated if the network interface is removed from the client and another client then uses the same network interface to generate a DUID-LLT. A collision between two DUID-LLTs is very unlikely even if the clocks have not been configured prior to generating the DUID. This method of DUID generation is recommended for all general-purpose computing devices such as desktop computers and laptop computers, and also for devices such as printers, routers, and so on, that contain some form of writable non-volatile storage.
It is possible that this algorithm for generating a DUID could result in a client identifier collision. A DHCP client that generates a DUID-LLT using this mechanism MUST provide an administrative interface that replaces the existing DUID with a newly generated DUID-LLT.11.3. DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)
The vendor assigns this form of DUID to the device. This DUID consists of the 4-octet vendor's registered Private Enterprise Number as maintained by IANA [IANA-PEN] followed by a unique identifier assigned by the vendor. The following diagram summarizes the structure of a DUID-EN: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID-Type (2) | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number (contd) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . identifier . . (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DUID-EN Format The source of the identifier is left up to the vendor defining it, but each identifier part of each DUID-EN MUST be unique to the device that is using it, and MUST be assigned to the device no later than at the first usage and stored in some form of non-volatile storage. This typically means being assigned during the manufacturing process in the case of physical devices or, in the case of virtual machines, when the image is created or booted for the first time. The generated DUID SHOULD be recorded in non-erasable storage. The enterprise-number is the vendor's registered Private Enterprise Number as maintained by IANA [IANA-PEN]. The enterprise-number is stored as an unsigned 32-bit number.
An example DUID of this type might look like this: +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 0 | 0 | 9| 12|192| +---+---+---+---+---+---+---+---+ |132|211| 3 | 0 | 9 | 18| +---+---+---+---+---+---+ Figure 6: DUID-EN Example This example includes the 2-octet type of 2 and the Enterprise Number (9), followed by 8 octets of identifier data (0x0CC084D303000912).11.4. DUID Based on Link-Layer Address (DUID-LL)
This type of DUID consists of 2 octets containing a DUID type of 3 and a 2-octet network hardware type code, followed by the link-layer address of any one network interface that is permanently connected to the client or server device. For example, a node that has a network interface implemented in a chip that is unlikely to be removed and used elsewhere could use a DUID-LL. The hardware type MUST be a valid hardware type assigned by IANA; see [IANA-HARDWARE-TYPES]. The hardware type is stored in network byte order. The link-layer address is stored in canonical form, as described in [RFC2464]. The following diagram illustrates the format of a DUID-LL: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID-Type (3) | hardware type (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: DUID-LL Format The choice of network interface can be completely arbitrary, as long as that interface provides a unique link-layer address and is permanently attached to the device on which the DUID-LL is being generated. The same DUID-LL SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID.
A DUID-LL is recommended for devices that have a permanently connected network interface with a link-layer address and do not have nonvolatile, writable stable storage. A DUID-LL SHOULD NOT be used by DHCP clients or servers that cannot tell whether or not a network interface is permanently attached to the device on which the DHCP client is running.11.5. DUID Based on Universally Unique Identifier (DUID-UUID)
This type of DUID consists of 16 octets containing a 128-bit UUID. [RFC6355] details when to use this type and how to pick an appropriate source of the UUID. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID-Type (4) | UUID (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 8: DUID-UUID Format
(page 37 continued on part 5)