Dynamic Host Configuration Protocol (DHCP) | Hotspot Networks(c) Wi-Fi for Public Access Locations

As we've previously noted, a hotspot network is likely to use DHCP to support nomadic users.

Overview of DHCP

DHCP is an Internet protocol for automating the configuration of computers that use TCP/IP. The DHCP protocol is described in RFC 2131 (RFC 2131 obsoletes RFC 1541). DHCP can be used to automatically assign IP addresses to wireless stations in hotspots, to deliver TCP/IP stack configuration parameters such as the subnet mask and default router, and to provide other configuration information. DHCP uses UDP as its transport protocol. The client sends messages to the server on port (67), while the server sends messages to the client on port (68). DHCP is an extension of the Bootstrap Protocol (BOOTP) mechanism.

DHCP works well when one has to manage a large number of mobile users: users with laptops working in and out of the office, visiting branch offices, entering hotspot environments, and so on. Once the mobile stations configure a laptop to use DHCP, it can be automatically configured on any network with a DHCP server.

DHCP stores a list of addresses in a table for each of the subnets it is serving. When a DHCP client starts, it requests an address from the server. The server looks up an available address and assigns the address to the client. DHCP can also assign static addresses to clients if needed. In DHCP terms, clients 'lease' IP addresses. DHCP leases only last a certain amount of time; the default period is one day, but one can modify this parameter. Clients can request leases of a specific duration, but to prevent any machine from holding onto the lease forever, you can configure a maximum allowable lease time on your server. DHCP has broad appeal, but it is particularly useful in hotspot services.

DHCP is also used to enable hosts (DHCP clients) on an IP network to obtain their configurations from a server (DHCP server). This reduces the work necessary to administer an IP network. The most significant configuration option the client receives from the server is its IP address, but other configuration parameters (timers, SSIDs, encryption keys, subnet masks, routers, domains, and Domain Name Servers [DNSs]) can also be downloaded.

Three mechanisms are used to assign an IP address to the client:

Automatic allocation DHCP assigns a permanent IP address to a client.
Manual allocation A client's IP address is assigned by the administrator, and DHCP conveys the address to the client.
Dynamic allocation DHCP assigns an IP address to the client for a limited period of time (lease).

In general terms, the client (such as a wireless nomadic terminal entering a hotspot area) sends a request for an IP address. The server responds with an available IP address. Next, the client sends a request to the selected server for its configuration options. Thirdly, the server responds with the client's committed IP address along with other options (see Figure 8-22).

click to expand
Figure 8-22: DHCP mechanism

DHCP in Some Detail

DHCP provides configuration parameters to Internet hosts, and this is described in RFC 2131. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for the allocation of network addresses to hosts.^[10]

DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. In DHCP parlance, the term 'server' refers to a host providing initialization parameters through DHCP, and the term 'client' refers to a host requesting initialization parameters from a DHCP server.

A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations on the Internet would preclude reliable operations if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or be assumed to have correct defaults. Also, distributed address allocation schemes depend on a polling/defense mechanism for the discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid the allocation of duplicate network addresses.

DHCP supports three mechanisms for IP address allocation. In the first, known as automatic allocation, DHCP assigns a permanent IP address to a client. In dynamic allocation, DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In manual allocation, a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

Dynamic allocation is the only one of the three mechanisms that enables the automatic reuse of an address that is no longer needed by the client to which it is assigned. Thus, dynamic allocation is particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently connected to a network where IP addresses are sufficiently scarce so that it is important to reclaim them when old clients are retired. Manual allocation enables DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reason) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

The format of DHCP messages is based on the format of BOOTP messages in order to capture the BOOTP relay agent behavior described as part of the BOOTP specification and to enable the interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates the necessity of having a DHCP server on each physical network segment.

The RFC uses the following terms:

DHCP client A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCP server A DHCP server is an Internet host that returns configuration parameters to DHCP clients.
BOOTP relay agent A BOOTP relay agent or relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification.
Binding A binding is a collection of configuration parameters, including at least an IP address associated with or bound to a DHCP client. DHCP servers manage bindings.

The following list gives the general design goals for DHCP:

DHCP should be a mechanism rather than a policy. It must enable local system administrators control over configuration parameters where desired; for example, local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired.
Clients should require no manual configuration. Each client should be able to discover the appropriate local configuration parameters without user intervention and incorporate those parameters into its own configuration.
Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager should not have to enter any per-client configuration parameters.
DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.
A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance.
DHCP must coexist with statically configured, nonparticipating hosts and with existing network protocol implementations.
DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and RFC 1542.^[13]
DHCP must provide service to existing BOOTP clients.

The following list gives design goals specific to the transmission of the network-layer parameters. DHCP must

Guarantee that any specific network address will not be in use by more than one DHCP client at a time.
Retain DHCP client configuration across DHCP client reboots. A DHCP client should, whenever possible, be assigned the same configuration parameters (such as the network address) in response to each request.
Retain DHCP client configuration across server reboots and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism.
Enable the automated assignment of configuration parameters to new clients to avoid hand configuration (manual configuration) for new clients.
Support fixed or permanent allocation of configuration parameters to specific clients.

Protocol Summary

From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. RFC 1542 describes interactions between BOOTP and DHCP clients and servers. New, optional transactions that optimize the interaction between DHCP clients and servers are described in upcoming sections on DHCP's client/server protocol and some of its specifications.

Figure 8-23 gives the format of a DHCP message and Table 8-4 describes each of the fields in the DHCP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields in the figure will be used throughout this document to refer to the fields in DHCP messages.

click to expand
Figure 8-23: Format of a DHCP message

Table 8-4. Description of fields in a DHCP message
Field	Octets	Description
op	1	Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY.
htype	1	Hardware address type, see ARP section in 'Assigned Numbers' RFC; for example, 1 = 10 MB Ethernet.
hlen	1	Hardware address length (6 for 10 MB Ethernet).
hops	1	Client sets to 0, optionally used by relay agents when booting via a relay agent.
xid	4	Transaction ID, a random number chosen by the client and used by the client and server to associate messages and responses between a client and a server.
secs	2	Filled in by client, seconds elapsed since client began address acquisition or renewal process.
flags	2	Flags (see Figure 8-24).
ciaddr	4	Client IP address; only filled in if client is in BOUND, RENEW, or REBINDING state and can respond to Address Resolution Protocol (ARP) requests.
yiaddr	4	Your (client) IP address.
siaddr	4	IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server.
giaddr	4	Relay agent IP address, used in booting via a relay agent.
chaddr	16	Client hardware address.
sname	64	Optional server host name, null-terminated string.
file	128	Boot file name, null-terminated string; generic name or null in DHCPDISCOVER, fully qualified directory path name in DHCPOFFER.
options	var	Optional parameters field. See the options documents for a list of defined options.

click to expand
Figure 8-24: Format of the flags field

Two primary differences exist between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for the serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.

DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the Vendor extensions field in BOOTP has been renamed the Options field in DHCP. Similarly, the tagged data items that were used inside the BOOTP Vendor extensions field, which were formerly referred to as vendor extensions, are now termed simply options.

DHCP defines a new Client identifier option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the chaddr field in BOOTP messages, where chaddr is used both as a hardware address for the transmission of BOOTP reply messages and as a client identifier. The client identifier is an opaque key, not to be interpreted by the server. For example, the client identifier may contain a hardware address, identical to the contents of the chaddr field, or it may contain another type of identifier, such as a DNS name. The client identifier chosen by a DHCP client must be unique to that client within the subnet to which the client is attached. If the client uses a client identifier in one message, it must use that same identifier in all subsequent messages to ensure that all servers correctly identify the client.

DHCP clarifies the interpretation of the siaddr field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the siaddr field if the server is prepared to supply the next bootstrap service (such as the delivery of an operating system executable image). A DHCP server always returns its own address in the server identifier option.

The options field is now variable length. A DHCP client must be prepared to receive DHCP messages with an options field of at least 312 octets long. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP datagram size an IP host must be prepared to accept. DHCP clients may negotiate the use of larger DHCP messages through the maximum DHCP message size option. The options field may be further extended into the file and sname fields.

In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires the creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software should accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured. DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.

To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured, as discussed in the previous paragraph, DHCP uses the flags field.^[13] The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in the 'Constructing and Sending DHCP Messages' section. The remaining bits of the flags field are reserved for future use. They must be set to zero by clients and ignored by servers and relay agents. Figure 8-24 gives the format of the flags field.

Configuration Parameters Repository

The first service provided by DHCP is to provide persistent storage of network parameters for network clients. The model of DHCP persistent storage is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for example, an IP subnet number and a unique identifier within the subnet) and the value contains the configuration parameters for the client.

For example, the key might be the pair of IP-subnet-number and hardware-address, allowing for the serial or concurrent reuse of a hardware address on different subnets, and for hardware addresses that may not be globally unique. Note that the hardware-address should be typed by the type of hardware to accommodate the possible duplication of hardware addresses resulting from bit-ordering problems in a mixed-media, bridged network. Alternately, the key might be the pair of IP-subnet-number and hostname, allowing the server to assign parameters intelligently to a DHCP client that has been moved to a different subnet or has changed hardware addresses (perhaps because the network interface failed and was replaced). The protocol defines that the key will be IP-subnet-number and hardware-address unless the client explicitly supplies an identifier using the client identifier option. A client can query the DHCP service to retrieve its configuration parameters. The client interface to the configuration parameters repository consists of protocol messages to request configuration parameters and responses from the server carrying the configuration parameters.

Dynamic Allocation of Network Addresses

The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to clients. The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a lease. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning 'permanent' addresses, a server may choose to give out lengthy but noninfinite leases to enable the detection of the fact that the client has been retired.

In some environments, it will be necessary to reassign network addresses due to the exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose leases have expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocating server should probe the reused address before allocating the address, such as with an ICMP echo request, and the client should probe the newly received address, such as with the Address Resolution Protocol (ARP).

The Client-Server Protocol

DHCP uses the BOOTP message format defined in RFC 951 and given in Table 8-5 and Figure 8-25. The op field of each DHCP message sent from a client to a server contains BOOTREQUEST. BOOTREPLY is used in the op field of each DHCP message sent from a server to a client.

click to expand
Figure 8-25: Timeline diagram of messages exchanged between the DHCP client and servers when allocating a new network address

The first four octets of the options field of the DHCP message contain the (decimal) values 99, 130, 83, and 99, respectively (this is the same magic cookie as defined in RFC 1497 ). The remainder of the options field consists of a list of tagged parameters that are called options. All of the vendor extensions listed in RFC 1497 are also DHCP options. RFC 1533 gives the complete set of options defined for use with DHCP.

Several options have been defined so far. One particular option, the DHCP message type option, must be included in every DHCP message. This option defines the type of the DHCP message. Additional options may be allowed, required, or not allowed, depending on the DHCP message type.

Throughout this document, DHCP messages that include a DHCP message type option will be identified by the type of the message. For example, a DHCP message with DHCP message type option type 1 will be referred to as a DHCPDISCOVER message.

Client-server Interaction: Allocating a Network Address

The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in Table 8-5. The timeline in Figure 8-25 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in the next subsection.

Table 8-5. DHCP messages
Message	Use
DHCPDISCOVER	Client broadcast to locate available servers.
DHCPOFFER	Server to client in response to DHCPDISCOVER with offer of configuration parameters.
DHCPREQUEST	Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) correctness of previously allocated address after system reboot, for example, or (c) extending the lease on a particular network address.
DHCPACK	Server to client with configuration parameters, including committed network address.
DHCPNAK	Server to client indicating client's notion of network address is incorrect (client has moved to new subnet) or client's lease has expired.
DHCPDECLINE	Client to server indicating network address is already in use.
DHCPRELEASE	Client to server relinquishing network address and cancelling remaining lease.
DHCPINFORM	Client to server, asking only for local configuration parameters; client already has externally configured network address.

The sequence of protocol exchanges is as follows:

The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message may include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
Each server may respond with a DHCPOFFER message that includes an available network address in the yiaddr field (and other configuration parameters in DHCP options). Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers should check that the offered network address is not already in use; for example, the server may probe the offered address with an ICMP echo request. Servers should be implemented so that network administrators may choose to disable probes of newly allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary.
The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that must include the server identifier option to indicate which server it has selected, and that may include other options specifying desired configuration values. The requested IP address option must be set to the value of yiaddr in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message must use the same value in the DHCP message header's secs field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages.
The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of client identifier or chaddr and assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP message. Any configuration parameters in the DHCPACK message should not conflict with those in the earlier DHCPOFFER message to which the client is responding. The server should not check the offered network address at this point. The yiaddr field in the DHCPACK messages is filled in with the selected network address.

If the selected server is unable to satisfy the DHCPREQUEST message (if the requested network address has been allocated), the server should respond with a DHCPNAK message.

A server may choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server should mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.
The client receives the DHCPACK message with configuration parameters. The client should perform a final check on the parameters (ARP for allocated network address) and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (through the use of ARP), the client must send a DHCPDECLINE message to the server and restart the configuration process. The client should wait a minimum of 10 seconds before restarting the configuration process to avoid excessive network traffic in case of looping.

If the client receives a DHCPNAK message, the client restarts the configuration process.

The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK nor a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in the section on constructing and sending DHCP messages. The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up. For example, a client retransmitting as described in the upcoming section on message construction might retransmit the DHCPREQUEST message 4 times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK nor a DHCPNAK message after employing the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. The client should notify the user that the initialization process has failed and is restarting.
The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its client identifier or chaddr and network address in the DHCPRELEASE message. If the client used a client identifier when it obtained the lease, it must use the same client identifier in the DHCPRELEASE message.

Client-server Interaction: Reusing a Previously Allocated Network Address

If a client remembers and wishes to reuse a previously allocated network address, a client may choose to omit some of the steps described in the previous section. The timeline diagram in Figure 8-26 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.

click to expand
Figure 8-26: Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address

The sequence of protocol exchanges is as follows:

The client broadcasts a DHCPREQUEST message on its local subnet. The message includes the client's network address in the requested IP address option. As the client has not received its network address, it must not fill in the ciaddr field. BOOTP relay agents pass the message on to DHCP servers not on the same subnet. If the client used a client identifier to obtain its address, the client must use the same client identifier in the DHCPREQUEST message.
Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. Servers should not check that the client's network address is already in use; the client may respond to ICMP echo request messages at this point.

If the client's request is invalid (the client has moved to a new subnet), servers should respond with a DHCPNAK message to the client. Servers should not respond if their information is not guaranteed to be accurate. For example, a server that identifies a request for an expired binding that is owned by another server should not respond with a DHCPNAK unless the servers are using an explicit mechanism to maintain coherency among them.

If giaddr is 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server. The server must broadcast the DHCPNAK message to the 0xffffffff broadcast address because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests. Otherwise, the server must send the DHCPNAK message to the IP address of the BOOTP relay agent, as recorded in giaddr. The relay agent will, in turn, forward the message directly to the client's hardware address, so that the DHCPNAK can be delivered even if the client has moved to a new network.
The client receives the DHCPACK message with configuration parameters. The client performs a final check on the parameters, as in the previous section, and notes the duration of the lease specified in the DHCPACK message. The specific lease is implicitly identified by the client identifier or chaddr and the network address. At this point, the client is configured.

If the client detects that the IP address in the DHCPACK message is already in use, the client must send a DHCPDECLINE message to the server and restart the configuration process by requesting a new network address. This action corresponds to the client moving to the INIT state in the DHCP state diagram, described in more detail when we discuss DHCP client behavior.

If the client receives a DHCPNAK message, it cannot reuse its remembered network address. It must instead request a new address by restarting the configuration process, this time using the (nonabbreviated) procedure from the last section. This action also corresponds to the client moving to the INIT state in the DHCP state diagram.

The client times out and retransmits the DHCPREQUEST message if it receives neither a DHCPACK nor a DHCPNAK message. A retransmission uses the retransmission algorithm. The client must retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up. For example, a client might retransmit the DHCPREQUEST message 4 times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK nor a DHCPNAK message after employing the retransmission algorithm, it may choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease. This corresponds to moving to a BOUND state in the client state transition diagram shown in Figure 8-27.

Figure 8-27: State transition diagram for DHCP clients
The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with its client identifier or chaddr and network address in the DHCPRELEASE message.

Note that in this case, where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown. Only in the case where the client explicitly needs to relinquish its lease (when the client is about to be moved to a different subnet, for example) will the client send a DHCPRELEASE message.

Interpretation and Representation of Time Values

A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent infinity.

As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client's local clock. Representing relative times in units of seconds in an unsigned, 32-bit word gives a range of relative times from 0 to approximately 100 years, which is sufficient for the relative times to be measured using DHCP.

The algorithm for lease duration interpretation given in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is a drift between the two clocks, the server may consider the lease expired before the client does. To compensate, the server may return a shorter lease to the client than it commits to its local database of client information.

Obtaining Parameters with an Externally Configured Network Address

If a client has obtained a network address through some other means (such as manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without allocating a new address, checking for an existing binding, filling in yiaddr, or including lease time parameters. The servers should unicast the DHCPACK reply to the address given in the ciaddr field of the DHCPINFORM message.

The server should check the network address in a DHCPINFORM message for consistency, but it must not check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.

Client Parameters in DHCP

Not all clients require the initialization of all parameters listed in the RFC. Two techniques are used to reduce the number of parameters transmitted from the server to the client. First, most of the parameters have defaults defined in the Host Requirements RFCs; if the client receives no parameters from the server that override the defaults, a client uses those default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in. If the client includes a list of parameters in a DHCPDISCOVER message, it must include that list in any subsequent DHCPREQUEST messages.

Clients should include the maximum DHCP message size option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the options field of the message) indicate that the file and sname fields are to be used for options.

The client can inform the server as to which configuration parameters the client is interested in by including the parameter request list option. The data portion of this option explicitly lists the options requested by tag number.

In addition, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the requested IP address option to suggest that a particular IP address be assigned, and it may include the IP address lease time option to suggest the lease time it would like. Other options representing hints at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. However, additional options may be ignored by servers, and multiple servers may therefore not return identical values for some options. The requested IP address option is to be filled in only in a DHCPREQUEST message when the client is verifying network parameters obtained previously. The client fills in the ciaddr field only when correctly configured with an IP address in a BOUND, RENEWING, or REBINDING state.

If a server receives a DHCPREQUEST message with an invalid requested IP address option, the server should respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the message option.

Use of DHCP in Clients with Multiple Interfaces

A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for them.

When Should Clients Use DHCP? A client should use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed. This may be at system boot time or after a disconnection from the local network, as the local network configuration may change without the client or user's knowledge.

If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.

Specification of the DHCP Client-Server Protocol In this section, we assume that a DHCP server has a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage.

Constructing and Sending DHCP Messages DHCP clients and servers both construct DHCP messages by filling in fields in the fixed format section of the message and appending tagged data items in the variable length option area. The options area includes a four-octet 'magic cookie,' followed by the options. The last option must always be the end option.

DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the DHCP server port (67), and DHCP messages from a server to a client are sent to the DHCP client port (68). A server with multiple network addresses (a multihomed host) may use any of its network addresses in outgoing DHCP messages.

The server identifier field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses must be prepared to accept any of its network addresses as identifying that server in a DHCP message. To accommodate potentially incomplete network connectivity, a server must choose an address as a server identifier that, to the best of the server's knowledge, is reachable from the client.

For example, if the DHCP server and the DHCP client are connected to the same subnet (the giaddr field in the message from the client is zero), the server should select the IP address the server is using for communication on that subnet as the server identifier. If the server is using multiple IP addresses on that subnet, any such address may be used. If the server has received a message through a DHCP relay agent, the server should choose an address from the interface on which the message was received as the server identifier (unless the server has other, better information on which to make its choice). DHCP clients must use the IP address provided in the server identifier option for any unicast requests to the DHCP server. DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to zero.

If the giaddr field in a DHCP message from a client is nonzero, the server sends any return messages to the DHCP server port on the BOOTP relay agent whose address appears in giaddr. If the giaddr field is zero and the ciaddr field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in ciaddr. If giaddr is zero and ciaddr is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and giaddr is zero and ciaddr is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and yiaddr address. In all cases, when giaddr is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.

If the options in a DHCP message extend into the sname and file fields, the option overload option must appear in the options field with value 1, 2, or 3, as specified in RFC 1533. If the option overload option is present in the options field, the options in the options field must be terminated by an end option and may contain one or more pad options to fill the options field. The options in the sname and file fields (if in use as indicated by the options overload option) must begin with the first octet of the field, must be terminated by an end option, and must be followed by pad options to fill the remainder of the field. Any individual option in the options, sname, and file fields must be entirely contained in that field. The options in the options field must be interpreted first, so that any option overload options may be interpreted. The file field must be interpreted next (if the option overload option indicates that the file field contains DHCP options), followed by the sname field.

The values to be passed in an option tag may be too long to fit in the 255 octets available to a single option (a list of routers in a router option^[13]). Options may appear only once, unless otherwise specified in the options document. The client concatenates the values of multiple instances of the same option into a single parameter list for configuration.

DHCP clients are responsible for all message retransmission. The client must adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions should be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server.

For example, in a 10 Mbps Ethernet internetwork, the delay before the first retransmission should be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a noninteger randomization value. The delay before the next retransmission should be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay should be doubled with subsequent retransmissions up to a maximum of 64 seconds. The client may provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process.

The client uses the xid field to match incoming DHCP messages with pending requests. A DHCP client must choose xids in such a way as to minimize the chance of using an xid that is identical to one used by another client. For example, a client may choose a different, random initial xid each time the client is rebooted and subsequently use sequential xids until the next reboot. Selecting a new xid for each retransmission is an implementation decision. A client may choose to reuse the same xid or select a new ‘one for each retransmitted message.

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK, and DHCPNAK messages directly to the client using unicast delivery. The IP destination address (in the IP header) is set to the DHCP yiaddr address, and the link-layer destination address is set to the DHCP chaddr address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address should set the BROADCAST bit in the Flags field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that the client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured should clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit.^[13]

A server or relay agent sending or relaying a DHCP message directly to a DHCP client (not to a relay agent specified in the giaddr field) should examine the BROADCAST bit in the Flags field. If this bit is set to 1, the DHCP message should be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message should be sent as an IP unicast to the IP address specified in the yiaddr field and the link-layer address specified in the chaddr field. If unicasting is not possible, the message may be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address.

DHCP Server Administrative Controls

DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all the administrative controls that system administrators might want to use. Specific DHCP server implementations may incorporate any controls or policies desired by a network administrator. In some environments, a DHCP server will have to consider the values of the vendor class options included in DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client.

A DHCP server needs to use some unique identifier to associate a client with its lease. The client may choose to explicitly provide the identifier through the client identifier option. If the client supplies a client identifier, the client must use the same client identifier in all subsequent messages, and the server must use that identifier to identify the client. If the client does not provide a client identifier option, the server must use the contents of the chaddr field to identify the client. It is crucial for a DHCP client to use an identifier that is unique within the subnet to which the client is attached in the client identifier option. Use of chaddr as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the client identifier to avoid unexpected changes in a client's network address due to the transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the client identifier, causing address leases to be associated with the DNS name rather than a specific hardware box.

DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP should provide a mechanism for the user to select directly the vendor class identifier values.

DHCP Server Behavior

A DHCP server processes incoming DHCP messages from a client based on the current state of the binding for that client. A DHCP server can receive the following messages from a client:

DHCPDISCOVER
DHCPREQUEST
DHCPDECLINE
DHCPRELEASE
DHCPINFORM

Table 8-6 shows the use of fields and options in a DHCP message sent by a server. The remainder of this section describes the action of the DHCP server for each possible incoming message.

Table 8-6. Fields and options used by DHCP servers
Field	DHCPOFFER	DHCPACK	DHCPNAK
op	BOOTREPLY	BOOTREPLY	BOOTREPLY
htype	(From 'Assigned Numbers'
hlen	(Hardware address length
hops	0	0	0
xid	xid from client DHCPDISCOVER message	xid from client DHCPREQUEST message	xid from client DHCPREQUEST message
secs	0	0	0
ciaddr	0	ciaddr from DHCPREQUEST or 0	0
yiaddr	IP address offered to client	IP address assigned to client	0
siaddr	IP address of next bootstrap server	IP address of next bootstrap server	0
flags	flags from client DHCPDISCOVER message	flags from client DHCPREQUEST message	flags from client DHCPREQUEST message
giaddr	giaddr from client DHCPDISCOVER message	giaddr from client DHCPREQUEST message	giaddr from client DHCPREQUEST message
chaddr	chaddr from client DHCPDISCOVER message	chaddr from client DHCPREQUEST message	chaddr from client DHCPREQUEST message
sname	Server host name or options	Server host name or options	(unused)
file	Client boot file name or options	Client boot file name or options	(unused)
options	options	options
Option	DHCPOFFER	DHCPACK	DHCPNAK
Requested IP address	Must not	Must not	Must not
IP address lease time	Must	Must (DHCPREQUEST)	Must not Must not(DHCPINFORM)
Use file/sname fields	May	May	Must not
DHCP message type	DHCPOFFER	DHCPACK	DHCPNAK
Parameter request list	Must not	Must not	Must not
Message	Should	Should	Should
Client identifier	Must not	Must not	May
Vendor class identifier	May	May	May
Server identifier	Must	Must	Must
Maximum message size	Must not	Must not	Must not
All others	May	May	Must not

DHCPDISCOVER Message When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address should be chosen as follows:

Use the client's current address as recorded in the client's current binding.
Otherwise, use the client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated.
Otherwise, use the address requested in the Requested IP Address option, if that address is valid and not already allocated.
Otherwise, use a new address allocated from the server's pool of available addresses. The address is selected based on the subnet from which the message was received (if giaddr is 0) or on the address of the relay agent that forwarded the message (giaddr when not 0).

As described in the last section, a server may, for administrative reasons, assign an address other than the one requested or it may refuse to allocate an address to a particular client even though free addresses are available.

Note that in some network architectures (Internets with more than one IP subnet assigned to a physical network segment), it may be the case that the DHCP client should be assigned an address from a different subnet than the address recorded in giaddr. Thus, DHCP does not require that the client be assigned as an address from the subnet in giaddr. A server is free to choose some other subnet, and it is beyond the scope of the DHCP specification to describe ways in which the assigned IP address might be chosen.

Although not required for the correct operation of DHCP, the server should not reuse the selected network address before the client responds to the server's DHCPOFFER message. The server may choose to record the address as offered to the client.

The server must also choose an expiration time for the lease, as follows:

If the client has not requested a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address).
Otherwise, if the client has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time.
Otherwise, if the client has requested a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server may choose either to return the requested lease (if the lease is acceptable to local policy) or select another lease.

Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. The configuration parameters must be selected by applying the following rules in the specified order. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server must return to the client

The client's network address, as determined by the rules given earlier in this section
The expiration time for the client's lease, as determined by the rules given earlier in this section
Parameters requested by the client, according to the following rules:
- If the server has been explicitly configured with a default value for the parameter, the server must include that value in an appropriate option in the option field.
- Otherwise, if the server recognizes the parameter as a parameter defined in the Host Requirements document, the server must include the default value for that parameter as given in the Host Requirements document in an appropriate option in the option field.
- Otherwise, the server must not return a value for that parameter. The server must supply as many of the requested parameters as possible and must omit any parameters it cannot provide. The server must include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document.
Return any parameters from the existing binding that differ from the Host Requirements document are by default.
Return any parameters that are specific to this client (as identified by the contents of chaddr or client identifier in the DHCPDISCOVER or DHCPREQUEST message), such as those configured by the network administrator.
Return any parameters that are specific to this client's class (as identified by the contents of the vendor class identifier option in the DHCPDISCOVER or DHCPREQUEST message), such as those configured by the network administrator. The parameters must be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server.
Return any parameters that have nondefault values on the client's subnet.

The server may choose to return the vendor class identifier used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept. The server inserts the xid field from the DHCPDISCOVER message into the xid field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.

DHCPREQUEST Message A DHCPREQUEST message may come from a client responding to a DHCPOFFER message from a server, from a client verifying a previously allocated IP address, or from a client extending the lease on a network address. If the DHCPREQUEST message contains a server identifier option, the message is in response to a DHCPOFFER message. Otherwise, the message is a request to verify or extend an existing lease. If the client uses a client identifier in a DHCPREQUEST message, it must use that same client identifier in all subsequent messages. If the client included a list of requested parameters in a DHCPDISCOVER message, it must include that list in all subsequent messages.

Any configuration parameters in the DHCPACK message should not conflict with those in the earlier DHCPOFFER message to which the client is responding. The client should use the parameters in the DHCPACK message for configuration.

Clients send DHCPREQUEST messages as follows:

DHCPREQUEST generated during the SELECTING state The client inserts the address of the selected server in server identifier, ciaddr must be zero, and requested IP address must be filled in with the yiaddr value from the chosen DHCPOFFER.

Note that the client may choose to collect several DHCPOFFER messages and select the best offer. The client indicates its selection by identifying the offering server in the DHCPREQUEST message. If the client receives no acceptable offers, the client may choose to try another DHCPDISCOVER message. Therefore, the servers may not receive a specific DHCPREQUEST from which they can decide whether or not the client has accepted the offer. Because the servers have not committed any network address assignments on the basis of a DHCPOFFER, servers are free to reuse offered network addresses in response to subsequent requests. As an implementation detail, servers should not reuse offered addresses and may use an implementation-specific timeout mechanism to decide when to reuse an offered address.
DHCPREQUEST generated during the INIT-REBOOT state server identifier must not be filled in, but requested IP address option must be filled in with the client's notion of its previously assigned address. ciaddr must be zero. The client is seeking to verify a previously allocated, cached configuration. The server should send a DHCPNAK message to the client if the requested IP address is incorrect or is on the wrong network.

Determining whether a client in the INIT-REBOOT state is on the correct network is done by examining the contents of giaddr, the requested IP address option, and a database lookup. If the DHCP server detects that the client is on the wrong net (the result of applying the local subnet mask or remote subnet mask, if giaddr is not zero, to the requested IP address option value doesn't match reality), then the server should send a DHCPNAK message to the client.

If the network is correct, then the DHCP server should check if the client's notion of its IP address is correct. If not, then the server should send a DHCPNAK message to the client. If the DHCP server has no record of this client, then it must remain silent and may output a warning to the network administrator. This behavior is necessary for peaceful coexistence of noncommunicating DHCP servers on the same wire.

If giaddr is 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server. The server must broadcast the DHCPNAK message to the 0xffffffff broadcast address because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests.

If giaddr is set in the DHCPREQUEST message, the client is on a different subnet. The server must set the broadcast bit in the DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the client, because the client may not have a correct network address or subnet mask, and the client may not be answering ARP requests.
DHCPREQUEST generated during the RENEWING state The server identifier and requested IP address options must not be filled in, but ciaddr must be filled in with the client's IP address. In this situation, the client is completely configured and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its transmission. Because giaddr is therefore not filled in, the DHCP server will trust the value in ciaddr and use it when replying to the client.

A client may choose to renew or extend its lease prior to T1. The server may choose not to extend the lease (as a policy decision by the network administrator) but should return a DHCPACK message regardless.
DHCPREQUEST generated during the REBINDING state The server identifier and requested IP address options must not be filled in, but ciaddr must be filled in with the client's IP address. In this situation, the client is completely configured and is trying to extend its lease. This message must be broadcast to the 0xffffffff IP broadcast address. The DHCP server should check ciaddr for correctness before replying to the DHCPREQUEST.

The DHCPREQUEST from a REBINDING client is intended to accommodate sites that have multiple DHCP servers and a mechanism for maintaining consistency among leases managed by multiple servers. A DHCP server may extend a client's lease only if it has the local administrative authority to do so.

DHCPDECLINE Message If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server must mark the network address as not available and should notify the local system administrator of a possible configuration problem.

DHCPRELEASE Message Upon receipt of a DHCPRELEASE message, the server marks the network address as not allocated. The server should retain a record of the client's initialization parameters for possible reuse in response to subsequent requests from the client.

DHCPINFORM Message The server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the ciaddr field of the DHCPINFORM message. The server must not send a lease expiration time to the client and should not fill in yiaddr. The server includes other parameters in the DHCPACK message as defined in the section on DHCPDISCOVER.

Client Messages Table 8-7 details the differences between messages from clients in various states.

Table 8-7. Client messages from different states
	INIT-REBOOT	SELECTING	RENEWING	REBINDING
broad/unicast	Broadcast	Broadcast	Unicast	Broadcast
server-ip	Must not	Must	Must not	Must not
requested-ip	Must	Must	Must not	Must not
ciaddr	Zero	Zero	IP address	IP address

DHCP Client Behavior

Figure 8-27 is a state-transition diagram for a DHCP client. A client can receive the following messages from a server:

DHCPOFFER
DHCPACK
DHCPNAK

Note that the figure does not show a DHCPINFORM message. A client simply sends the DHCPINFORM and waits for DHCPACK messages. Once the client has selected its parameters, it has completed the configuration process.

Table 8-8 shows the use of the fields and options in a DHCP message by a client. The remainder of this section describes the action of the DHCP client for each possible incoming message. The description in the following section corresponds to the full configuration procedure previously described in allocating a network address. The text in the subsequent section corresponds to the abbreviated configuration procedure described in reusing a previously allocated address.

Table 8-8. Fields and options used by DHCP clients
Field	DHCPDISCOVER/ DHCPINFORM	DHCPREQUEST	DHCPDECLINE/ DHCPRELEASE
op	BOOTREQUEST	BOOTREQUEST	BOOTREQUEST
htype	(From 'Assigned Numbers'
hlen	(Hardware address length	in octets)
hops	0	0	0
xid	selected by client	xid from server DHCPOFFER message	selected by client
secs	0 or seconds since DHCP process started	0 or seconds since DHCP process started	0
flags	Set BROADCAST flag if client requires broadcast reply	Set BROADCAST flag if client requires broadcast reply	0
ciaddr	0 (DHCPDISCOVER) client's network address (DHCPINFORM)	0 or client's network address (BOUND/ RENEW/REBIND)	0 (DHCPDECLINE) client's network address (DHCPRELEASE)
yiaddr	0	0	0
siaddr	0	0	0
giaddr	0	0	0
chaddr	client's hardware address	client's hardware address	client's hardware address
sname	options, if indicated in sname/file option; otherwise unused	options, if indicated in sname/file option; otherwise unused	client's hardware address (unused)
file	options, if indicated in sname/file option; otherwise unused	options, if indicated in sname/file option; otherwise unused	(unused)
options	options	options	(unused)
Option	Field	DHCPREQUEST	DHCPREQUEST
Requested IP address	May (DISCOVER) Must not (INFORM)	Must (in SELECTING or INIT-REBOOT), Must not (in BOUND or RENEWING)	Must (DHCPDECLINE), Must not (DHCPRELEASE)
IP address lease time	May (DISCOVER) Must not (INFORM)	May	Must not
Use file/ sname fields	May	May	May
DHCP message type	DHCPDISCOVER/ DHCPINFORM	DHCPREQUEST	DHCPDECLINE/ DHCPRELEASE
Client identifier	May	May	May
Vendor class identifier	May	May	Must not
Server identifier	Must not	Must (after SELECTING), Must not (after INIT-REBOOT, BOUND, RENEWING or REBINDING)	Must
Parameter request list	May	May	Must not
Maximum message size	May	May	Must not
Message	Should not	Should not	Should
Site-specific	May	May	Must not
All others	May	May	Must not

Initialization and Allocation of Network Addresses

The client begins in the INIT state and forms a DHCPDISCOVER message. The client should wait a random time between 1 and 10 seconds to desynchronize the use of DHCP at startup. The client sets ciaddr to 0x00000000. The client may request specific parameters by including the parameter request list option. The client may suggest a network address and/or lease time by including the requested IP address and IP address lease time options. The client must include its hardware address in the chaddr field, if necessary for the delivery of DHCP reply messages. The client may include a different unique identifier in the client identifier option, as noted in the discussion of server administrative controls. If the client included a list of requested parameters in a DHCPDISCOVER message, it must include that list in all subsequent messages.

The client generates and records a random transaction identifier and inserts that identifier into the xid field. The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER on the local hardware broadcast address to the 0xffffffff IP broadcast address and DHCP server UDP port.

If the xid of an arriving DHCPOFFER message does not match the xid of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.

The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (such as the first DHCPOFFER message or the DHCPOFFER message from the previously used server), and extracts the server address from the server identifier option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent.

If the parameters are acceptable, the client records the address of the server that supplied the parameters from the server identifier field and sends that address in the server identifier field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same xid as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. The client should perform a check on the suggested address to ensure that the address is not already in use.

For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and fill in 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client must send a DHCPDECLINE message to the server. The client should broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet.

Initialization with a Known Network Address

The client begins in the INIT-REBOOT state and sends a DHCPREQUEST message. The client must insert its known network address as a requested IP address option in the DHCPREQUEST message. The client may request specific configuration parameters by including the parameter request list option. The client generates and records a random transaction identifier and inserts that identifier into the xid field. The client records its own local time for later use in computing the lease expiration. The client must not include a server identifier in the DHCPREQUEST message. The client then broadcasts the DHCPREQUEST on the local hardware broadcast address to the DHCP server UDP port.

Once a DHCPACK message with an xid field matching the field in the client's DHCPREQUEST message arrives from any server, the client is initialized and moves to BOUND state. The client records the lease expiration time as the sum of the time at which the DHCPREQUEST message was sent and the duration of the lease from the DHCPACK message.

Initialization with an Externally Assigned Network Address

The client sends a DHCPINFORM message. The client may request specific configuration parameters by including the parameter request list option. The client generates and records a random transaction identifier and inserts that identifier into the xid field. The client places its own network address in the ciaddr field. The client should not request lease time parameters.

The client then unicasts the DHCPINFORM to the DHCP server if it knows the server's address; otherwise, it broadcasts the message to the limited (all 1s) broadcast address. DHCPINFORM messages must be directed to the DHCP server UDP port.

Once a DHCPACK message with an xid field matching the field in the client's DHCPINFORM message arrives from any server, the client is initialized.

If the client does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using the timeout suggested in the 'Constructing and Sending DHCP Messages' section), then the client should display a message informing the user (the client's user) of the problem. It should then begin network processing using suitable defaults (as provided in the RFC).

Use of Broadcast and Unicast The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM messages, unless the client knows the address of a DHCP server. The client unicasts DHCPRELEASE messages to the server. Because the client is declining the use of the IP address supplied by the server, the client broadcasts DHCPDECLINE messages.

When the DHCP client knows the address of a DHCP server in either an INIT or REBOOTING state, the client may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. The client may also use unicast to send DHCPINFORM messages to a known DHCP server. If the client receives no response to DHCP messages sent to the IP address of a known DHCP server, the DHCP client reverts to using the IP broadcast address.

Reacquisition and Expiration The client maintains two times, T1 and T2, which specify when the client requests a lease extension on its network address. T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server. T1 must be earlier than T2, which, in turn, must be earlier than the time at which the client's lease will expire. To avoid the need for synchronized clocks, T1 and T2 are expressed in options as relative times. ^[14]

At time T1, the client moves to a RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the ciaddr field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client must not include a server identifier in the DHCPREQUEST message.

Any DHCPACK messages that arrive with an xid that does not match the xid of the client's DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message. The client has successfully reacquired its network address, returns to BOUND state, and may continue network processing.

If no DHCPACK arrives before time T2, the client moves to a REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the ciaddr field in the DHCPREQUEST to its current network address. The client must not include a server identifier in the DHCPREQUEST message.

Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 x duration of lease). T2 defaults to (0.875 x duration of lease). Times T1 and T2 should be chosen with some random fuzz around a fixed value to avoid synchronization of client reacquisition.

A client may choose to renew or extend its lease prior to T1. The server may choose to extend the client's lease according to a policy set by the network administrator. The server should return T1 and T2, and their values should be adjusted from their original values to take account of the time remaining on the lease.

In both RENEWING and REBINDING states, if the client receives no response to its DHCPREQUEST message, the client should wait half of the remaining time until T2 (in RENEWING state) and half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message.

If the lease expires before the client receives a DHCPACK, the client moves to the INIT state, must immediately stop any other network processing, and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating its previous network address, the client should continue network processing. If the client is given a new network address, it must not continue using the previous network address and should notify the local users of the problem.

DHCPRELEASE If the client no longer requires the use of its assigned network address (for example, the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages.

^[10]The angle of signal coverage provided by a radio; it may be decreased by a directional antenna to increase gain.

^[13]Wimer, W. 'RFC 1542: Clarifications and Extensions for the Bootstrap Protocol,' Carnegie Mellon University, October 1993.

^[14]Alexander, S., and R. Droms. 'RFC 1533: DHCP Options and BOOTP Vendor Extensions,' Lachman Technology, Inc., Bucknell University, October 1993.