How DHCP v4 really works

If you ask people how DHCP works, most people will think that a computer gets connected to the network and an IP is handed to them. This is a simplistic view as to what REALLY happens. I will cover the process of the initial DHCP request and the subsequent packets as well as the DHCP Relay process and finally the renewal process. This blog post will cover IPv4 only.

First things first. When you plug you machine into a switch or connect to an SSID and your machine is configured for DHCP, your machine will go through the following steps. If you want to see this for yourself, I suggest setting up a SPAN port and capturing or using Wireshark on your PC while you boot up.

There is a very nice Windows tool for troubleshooting DHCP. I have not run in since I went to Mac about 9 years ago, but it is worth a try.

1. DHCPDISCOVERY – Here the PC or device has no IP address and sends a broadcast essentially asking for a DHCP server to provide an IP address. This packet is a UDP packet on port 67. The reason this is a broadcast is that simply the device does not know where the DHCP server is. If there is no local DHCP and no BOOTP configured (more on this later), the device will revert to a ‘link-local IPv4’ (RFC 3927). APIPA.

2. DHCPOFFER – The next step is ALL DHCP servers that received the DHCPDISCOVERY broadcast packet will respond on UDP 68 with a

3. DHCPREQUEST -Once the client receives the DHCPOFFER, it replies with a DHCPREQUEST message, indicating that it plans to accept the parameters in the DHCPOFFER. If there are multiple DHCP servers (not a good practice), the device may receive multiple DHCPOFFER messages, one from each DHCP server that received the original DHCPDISCOVER message. The device will choose one DHCPOFFER and responds to THAT DHCP server only, declining all other DHCPOFFER messages. The server identifier is the IP address of a selected DHCP server. This option type is used in two possible ways. First, servers include this option type in DHCPOffer messages so that clients can distinguish between multiple lease offers. This option is used in DHCPOffer and DHCPRequest messages and sometimes appears in DHCP Acknowledgment messages (DHCPAck, DHCPNak)

4. DHCPACK – Once the DHCP server receives the DHCPREQUEST from the device/client, it sends and ACK packet for the request with a DHCPACK message. This comples the initialization process. Now, this DHCPACK message has a source IP address of the DHCP server and the destination address remains as a broadcast and contains the parameters that the client requested in the DHCPREQUEST message. When the device receives the DHCPACK, this is called the BOUND state. The DHCP server stores the leaseinformation into its database and identifies it using the client identifier or chaddr, and the assigned IP address.

5. DHCPNAK – If the server is unable to provide an IP for the DHCPREQUEST message, the DHCP server will respond with a DHCPNAK message. When the device receives a DHCPNAK message, or does not receive a response to a DHCPREQUEST message, the client restarts the process by going into the REQUESTING state. The device will then retransmit the DHCPREQUEST at least four times within 60 seconds before restarting the Initializing state.

6. DHCPDECLINE – The client receives the DHCPACK and CAN perform a final check on the parameters. The client performs this by sending Address Resolution Protocol ‘ARP’ requests for the IP address provided in the DHCPACK. If the client detects that the address is already in use by receiving a reply to the ARP request, the client will send a DHCPDECLINE message to the server and restart the configuration process by going into the Requesting state. This can be a device that has been assigned a static IP address from the pool of addresses defined in the DHCP scope.

7. DHCPINFORM – In some cases, you can define a static IP address on your device while still telling the OS to use DHCP for the domain name, DNS servers and other options (e.g. Option 150 for TFTP used for phones to boot their images). If this is the case the device will send a DHCPINFORM request message to obtain other local configuration parameters. This DHCPACK will be sent unicast to the client.

8. DHCPRELEASE – If a device wants to release its lease on a network address by sending a DHCPRELEASE message to the DHCP server. The device identifies the lease to be released by using the client identifier field and network address in the DHCPRELEASE message.

Renewing the Lease

The IP address assigned by the server belongs to the server and periodically the IP lease needs to be renewed. When the lease time has been reached its halfway point the client will try to renew the lease. The device will then re-enter into DHCPREQUEST mode. It will send this to the DHCP server that owns the lease. Once the server recieves this request it will reply to the request to renew with a DHCPACK message if in face, it wants to renew the lease. The DHCPACK message sent by the server to the client will contain the new lease and any new configuration parameters, in the event that any changes are made to the server during the time of the previous lease. If the device does not ger a response from the originating server, it will request a DHCP from any DHCP server that responds.

If the client previously had a DHCP assigned IP address and it is restarted, the client will request the previously leased IP address in a DHCPREQUEST packet. This DHCPREQUEST will still
have the source IP address as 0.0.0.0, and the destination as the IP broadcast address 255.255.255.255.

A client sending a DHCPREQUEST during a reboot does no fill in the server indentifier field, rather it will use the requested IP address option field. Strict RFC compliant clients will populate
the ciaddr field with the address requested instead of the DHCP option field. The DHCP server will accept either method.