How DHCP works Explained with Examples

When a host (DHCP client) needs an IP configuration, it connects to a DHCP server and requests an IP configuration. A DHCP server contains several pre-configured IP configurations. When it receives a DHCP request from a DHCP client, it provides an IP configuration to the client from all available IP configurations.

This process goes through four steps: Discover, Offer, Request, and Acknowledgment.

The following image shows all four steps of a DHCP communication.

DHCP discovery

When we start a device, it checks whether a valid IP configuration is available. If it is not available, the device generates a special message known as the DHCPDISCOVER message and broadcasts this message on the local LAN segment.

In this message, the device uses the addresses 0.0.0.0 and 255.255.255.255 in the source and destination address fields, respectively.

The 0.0.0.0 and 255.255.255.255 are two special addresses. Any device, whether it has a valid IP configuration or not, can use these addresses to send local broadcast messages.

From these addresses, the 0.0.0.0 is used as the source address. If a device does not have the source address, it can use this address to send broadcast messages. 255.255.255.255 is the local broadcast address. Any message sent to this address is received by all hosts of the local network.

DHCP offer

Since the client sends the DHCPDISCOVER message to the local broadcast address, if a DHCP server is configured on the local network, it will also receive the message. If multiple DHCP servers are configured on the local network, they all will receive the DHCPDISCOVER message.

If multiple DHCP servers are available, based on their configuration, one of them or all of them can reply to the DHCPDISCOVER message. In reply to the DHCPDISCOVER message, a DHCP server sends a DHCPOFFER message to the client.

Since the client does not have an IP address, the DHCP server cannot send the DHCPOFFER message directly to the client. Because of this, the server sets the destination address to 255.255.255.255. In other words, the server also broadcasts the DHCPOFFER message to the local network.

The DHCPOFFER message includes protocol-specific information and an IP address, subnet mask, default gateway's IP address, DNS server's IP address, and other configured servers' IP addresses such as TFTP and FTP.

Apart from these, the DHCPOFFER message also contains other protocol-specific information such as the lease duration and client ID. This information is required by the core functions of DHCP.

DHCP request

All hosts in the local network receive the DHCPOFFER message. The host that sent the DHCPDISCOVER message accepts the DHCPOFFER message. Apart from the original host, all other hosts ignore the DHCPOFFER.

How does a host know whether the broadcasted DHCPOFFER message is for it?

The DHCPDISCOVER message contains the host's MAC address. When a DHCP server broadcasts a DHCPOFFER message, it also includes the host's MAC address in a parameter known as the client ID. When hosts receive the DHCPOFFER message, they check the client ID field in the message. If a host sees its MAC address in the client ID field, it knows the message is intended for it. If a host sees the MAC address of another host in the client ID field, it knows the message is not intended for it.

Depending on the number of DHCP servers, a host may receive multiple DHCPOFFER messages. If a host receives multiple DHCPOFFER messages, it accepts only one message and tells the corresponding server with a DHCPREQUEST message that it wants to use the offered IP configuration.

If only one DHCP server is available and the provided IP configuration conflicts with the client’s configuration, the client can respond with a DHCPDECLINE message. In this situation, the DHCP server offers another IP configuration.

When DHCP servers receive the DHCPREQUEST message, besides the server whose offer has been accepted, all other servers withdraw their offer and return them to the pool of available addresses.

The DHCPREQUEST message contains a Transaction ID field. Just like hosts use the client ID field of the DHCPOFFER message to know whether the message is intended for them or not, DHCP servers use the Transaction ID field of the DHCPREQUEST message to know whether their offer has been accepted or not.

DHCP acknowledgment

When the DHCP server receives a DHCPREQUEST message from the client, the configuration process enters its final stage. In this stage, the server sends a DHCPACK message to the client.

The DHCPACK message is an acknowledgment to the client indicating that the DHCP server has received the DHCPREQUEST message of the client, and the client can use the offered IP configuration.

In some cases, the server may also respond with a DHCPNACK message. The DHCPNACK message tells the client that the offer is no longer valid and the client needs to request an IP configuration again. Typically, this occurs when the client takes too long to respond with a DHCPREQUEST message after receiving a DHCPOFFER message from the server. In such a case, the client can make a new request for another IP configuration.

The following image shows the above steps.

The following table summarizes messages that are used in each stage.

An easy way to remember these messages in the correct order is to think of the popular children's show "Dora the Explorer".

Each letter of the spelling DORA corresponds with the first letter of each step: D (Discover), O (Offer), R (Request), and A (Acknowledgment). Just as DORA discovers new things in her show, a DHCP client discovers a new IP configuration in the process.

That's all for this tutorial. In the next part of this tutorial, we will understand DHCP configuration parameters and settings in detail.