The Dynamic Host Configuration Protocol

DHCP is based on BOOTP. BOOTP hosts can interoperate with DHCP hosts, although DHCP adds many enhancements to BOOTP, including a larger vendor-specific information field (called the options field in DHCP) and the automatic allocation of reusable network layer addresses. DHCP has bypassed BOOTP in popularity, probably because it is easier to configure. Unlike BOOTP, DHCP does not require a network administrator to maintain a MAC-to-IP address table.

DHCP uses a client/server model. Servers allocate network layer addresses and save information about which addresses have been allocated. Clients dynamically request configuration parameters from servers. The goal of DHCP is that clients should require no manual configuration. In addition, the network manager should not have to enter any per-client configuration parameters into servers.

DHCP supports three methods for IP address allocation:

• Automatic allocation. A DHCP server assigns a permanent IP address to a client.

• Dynamic allocation. A DHCP server assigns an IP address to a client for a limited period of time.

• Manual allocation. A network administrator assigns a permanent IP address to a client, and DHCP is used simply to convey the assigned address to the client. (Manual allocation is rarely used because it requires per-client configuration, which automatic and dynamic allocations do not require.)

Dynamic allocation is the most popular method, partly because its reallocation feature supports environments where hosts are not online all the time, and there are more hosts than addresses. With dynamic allocation, a client requests the use of an address for a limited period of time. The period of time is called a lease.

The allocation mechanism guarantees not to reallocate that address within the requested time, and attempts to return the same network layer address each time the client requests an address. The client may extend its lease with subsequent requests. The client may choose to relinquish its lease by sending a DHCP release message to the server.

The allocation mechanism can reuse an address if the lease for the address has expired. As a consistency check, the allocating server should probe the reused address before allocating the address. It can do this with an Internet Control Message Protocol (ICMP) echo request (also known as a ping packet). The client should also probe the newly received address. It can do this with a ping packet or an Address Resolution Protocol (ARP) request.

When a client boots, it broadcasts a DHCP discover message on its local subnet. A station that has previously received a network layer address and lease can include them in the DHCP discover message to suggest that they be used again. A router can pass the DHCP discover message on to DHCP servers not on the same physical subnet to avoid a requirement that a DHCP server reside on each subnet. (The router acts as a DHCP relay agent.)

Each server responds to the DHCP request with a DHCP offer message that includes an available network layer address in the your address (yiaddr) field. The DHCP offer message can include additional configuration parameters in the options field.

After the client receives DHCP offer messages from one or more servers, the client chooses one server from which to request configuration parameters. The client broadcasts a DHCP request message that includes the server identifier option to indicate which server it has selected. This DHCP request message is broadcast and relayed through routers if necessary.

The server selected in the DHCP request message commits the configuration parameters for the client to persistent storage and responds with a DHCP ACK message, containing the configuration parameters for the requesting client.

If a client receives no DHCP offer or DHCP ACK messages, the client times out and retransmits the DHCP discover and request messages. To avoid synchronicity and excessive network traffic, the client uses 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, based on the characteristics of the network between the client and server. For example, on a 10-Mbps Ethernet network, 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. 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.

Continue reading here: DHCP Relay Agents

Was this article helpful?

0 0