Aller au contenu principal

5. DHCP Constants

  1. DHCP Constants

    This section describes various program and networking constants used by DHCP.

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

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. More detail on these message types can be found in sections 6 and 7. Message types not listed here are reserved for future use. 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 IP
addresses, 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 addresses
and configuration parameters to extend the
lifetimes on the addresses 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
addresses 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 addresses and configuration parameters
in response to a Solicit, Request, Renew,
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 addresses to the client 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 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
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 IP
addresses 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.

5.4. Status Codes

DHCPv6 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 24.4.

5.5. Transmission and Retransmission Parameters

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

Parameter Default Description

SOL_MAX_DELAY 1 sec Max delay of first Solicit SOL_TIMEOUT 1 sec Initial Solicit timeout SOL_MAX_RT 120 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 120 secs Max Information-request timeout value REL_TIMEOUT 1 sec Initial Release timeout REL_MAX_RC 5 MAX Release attempts DEC_TIMEOUT 1 sec Initial Decline timeout DEC_MAX_RC 5 Max Decline attempts REC_TIMEOUT 2 secs Initial Reconfigure timeout REC_MAX_RC 8 Max Reconfigure attempts HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message

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 is taken to mean "infinity" when used as a lifetime (as in RFC2461 [17]) or a value for T1 or T2.