跳到主要内容

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.