5. DHCP Constants

5. DHCP Constants

This section describes the various program and network constants used by DHCP.

5.1. Multicast Addresses

DHCP uses the following multicast addresses:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2)
A link-scoped multicast address used by clients to communicate with adjacent (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 relay agents to communicate with servers, when the relay agent wants to send a message to all servers, or when it does not know the unicast address of the server. Note that for a relay agent to be able to use this address, it must have an address with sufficient scope for servers to access. All servers within the site are members of this multicast group.

5.2. UDP Ports

Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.

5.3. DHCP Message Types

DHCP defines the following message types. For more details on these message types, see sections 6 and 7. Message types not listed here are reserved for future use. The numeric encoding of each message type is shown in parentheses.

SOLICIT (1)
A client sends a Solicit message to locate a server.

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 IP addresses, from a specific server.

CONFIRM (4)
A client sends a Confirm message to any available server to determine whether the addresses assigned to it are still appropriate for the link to which the client is attached.

RENEW (5)
A client sends a Renew message to the server that originally provided the client's addresses and configuration parameters, to extend the lifetimes on the addresses assigned to the client and update other configuration parameters.

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

REPLY (7)
A server sends a Reply message containing assigned addresses and configuration parameters, in response to Solicit, Request, Renew, Rebind messages 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 for the link to which the client is attached. A server sends a Reply message to confirm receipt of a Release or Decline message.

RELEASE (8)
A client sends a Release message to the server that allocated the address(es), to indicate that the client will no longer use one or more of the assigned addresses.

DECLINE (9)
A client sends a Decline message to a server to indicate that the client has determined that one or more of the addresses assigned by the server are already in use on the link to which the client is attached.

RECONFIGURE (10)
A server sends a Reconfigure message to a client to notify the client that the server has new or updated configuration parameters, and that the client should initiate a Renew/Reply or Information-request/Reply transaction with the server to receive the updated information.

INFORMATION-REQUEST (11)
A client sends an Information-request message to a server to request configuration parameters without assigning any IP addresses to the client.

RELAY-FORW (12)
A relay agent sends a Relay-forward message to relay a message to a server, directly or through another relay agent. The received message (a client message or a Relay-forward message from another relay agent) is encapsulated in the options of the Relay-forward message.

RELAY-REPL (13)
A server sends a Relay-reply message containing a message that the relay agent is to relay to the client. The Relay-reply message can be relayed by other relay agents to be delivered to the destination relay agent. The server encapsulates the client message as an option in the Relay-reply message, and the relay agent extracts this option and relays it to the client.

5.4. Status Codes

DHCPv6 uses status codes to communicate the success or failure of requested operations in client and server messages, and to provide additional information about the specific reason for message failure. Specific status codes are defined in section 24.4.

5.5. Transmission and Retransmission Parameters

This section provides a table of values used to describe message transmission behavior for clients and servers.

Parameter	Default Value	Description
SOL_MAX_DELAY	1 second	Maximum delay for first Solicit
SOL_TIMEOUT	1 second	Initial Solicit timeout
SOL_MAX_RT	120 seconds	Maximum Solicit timeout value
REQ_TIMEOUT	1 second	Initial Request timeout
REQ_MAX_RT	30 seconds	Maximum Request timeout value
REQ_MAX_RC	10	Maximum Request retry count
CNF_MAX_DELAY	1 second	Maximum delay for first Confirm
CNF_TIMEOUT	1 second	Initial Confirm timeout
CNF_MAX_RT	4 seconds	Maximum Confirm timeout
CNF_MAX_RD	10 seconds	Maximum Confirm duration
REN_TIMEOUT	10 seconds	Initial Renew timeout
REN_MAX_RT	600 seconds	Maximum Renew timeout value
REB_TIMEOUT	10 seconds	Initial Rebind timeout
REB_MAX_RT	600 seconds	Maximum Rebind timeout value
INF_MAX_DELAY	1 second	Maximum delay for first Information-request
INF_TIMEOUT	1 second	Initial Information-request timeout
INF_MAX_RT	120 seconds	Maximum Information-request timeout value
REL_TIMEOUT	1 second	Initial Release timeout
REL_MAX_RC	5	Maximum Release attempt count
DEC_TIMEOUT	1 second	Initial Decline timeout
DEC_MAX_RC	5	Maximum Decline attempt count
REC_TIMEOUT	2 seconds	Initial Reconfigure timeout
REC_MAX_RC	8	Maximum Reconfigure attempt count
HOP_COUNT_LIMIT	32	Maximum hop count in Relay-forward messages

5.6. Representation of time values and "Infinity" as a time value

All time values for lifetimes, T1, and T2 are unsigned integers. The value 0xffffffff, when used as a lifetime (as in RFC 2461 [RFC 2461]) or as a value of T1 or T2, represents "infinity".