7. DHCP Constants
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
7. DHCP Constants
This section describes various program and networking constants used
by DHCP.
7.1. Multicast Addresses
The following multicast addresses are used by DHCPv6:
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 MUST listen for DHCP messages on UDP port 546. Servers and
relay agents MUST listen for DHCP messages on UDP port 547.
Therefore, clients MUST send DHCP messages to UDP destination port
547. Servers MUST send Relay-reply messages to UDP destination port
547 and client messages to UDP destination port 546. Relay agents
MUST send Relay-forward and Relay-reply messages to UDP destination
port 547 and client messages to UDP destination port 546.
It is RECOMMENDED for clients to send messages from UDP source port
546 and for servers and relay agents from UDP source port 547.
However, clients, servers, and relay agents MAY send DHCP messages
from any UDP source port they are allowed to use.
Please note that the Relay Source Port Option [RFC8357] changes some
of these rules for servers and relays agents.
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
The table of values (Table 1) is 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 | Default information |
| | (24 hours) | refresh 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 Parameters
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.