DHCP in Practice with Wireshark

In the last post, I wrote about DHCP (Dynamic Host Configuration Protocol) in a more conceptual way, and today I’ll demonstrate the same process in a more practical manner. For this, I’ll use the Wireshark traffic analyzer.

Below, we have the 4 steps of the DHCP process that I captured when my Host requested an IP on the network.

Host (0.0.0.0) sends a DISCOVER via broadcast on the network (255.255.255.255).
DHCP server (192.168.56.56) responds with an OFFER via unicast on the network (192.168.56.100, which is already the IP it reserved for the Host, and this message can be sent via unicast due to the Host’s MAC ADDRESS as explained in the previous post).
Host (0.0.0.0) sends a REQUEST via broadcast on the network (255.255.255.255).
DHCP server (192.168.56.56) responds with ACK via unicast (192.168.56.100).

Analyzing the first frame exchanged between the Host and the server, we can already gather some important information.

Source MAC ADDRESS of the Host (08:00:27:91:F7:D0) with BROADCAST DESTINATION (ff:ff:ff:ff:ff:ff).
Source IP of the Host (0.0.0.0) with BROADCAST DESTINATION (255.255.255.255).
Source PORT of the Host (68) with DESTINATION (67) – Both UDP (Note: For brevity, the first parameter of the frame informs the type of protocol being sent/received).
Message type: DISCOVER

Below are the relevant details about DHCPDISCOVER.

In the image, there are no IP addresses listed in the “Client IP address” or “Your (client) IP address” fields because the Host does not yet know its DHCP server, nor does it have an IP on the network, so all IP fields are zeroed. Now, something very important is the parameter (55) “Parameter Request List”. In this parameter, we can see that DHCPDISCOVER already requests all necessary information along with their respective parameters for the DHCP server in addition to the IP, such as: Subnet mask, IP address lease time, domain name, gateway, among others.

Analyzing the second frame, now sent from the DHCP server to the Host, we can gather other important information.

Source MAC ADDRESS of the DHCP server (08:00:27:B1:0D:45) with UNICAST DESTINATION (08:00:27:91:F7:D0)
Source IP of the DHCP server (192.168.56.56) with UNICAST DESTINATION (192.168.56.100)
Source PORT of the DHCP server (67) with DESTINATION (68) – Both UDP
Message type: OFFER

Below are the relevant details about DHCPOFFER Now in the “Your (client) IP address” field, the information of the IP that was reserved for the Host and being “offered” to it appears. It’s interesting to note that there is no longer the (55) “Parameter Request List” field, as the server is already responding with those parameters that were requested in the previous frame. So, we can see the DHCP server “offering” to the host (Subnet mask, IP lease time, network domain, DNS, and Gateway). The DHCP server also sends a parameter (54) with its own identification information (IP) to the Host.

Note: I configured my DHCP service with basic information, but if you have a DHCP with other configured information, this is the moment when they will be “offered” to the Host.

Analyzing the third frame, now sent from the Host to the DHCP server, we have some more interesting information.

Source MAC ADDRESS of the Host (08:00:27:91:F7:D0) with BROADCAST DESTINATION (ff:ff:ff:ff:ff:ff)
Source IP of the Host (0.0.0.0) with BROADCAST DESTINATION (255.255.255.255)
Source PORT of the Host (68) with DESTINATION (67) – Both UDP
Message type: REQUEST

Below are the relevant details about DHCPREQUEST Basically, it’s the same information as DHCPDISCOVER, but now the Host already knows who the DHCP server is and already knows which IP was reserved for it, according to parameters (54) and (50) respectively. So, the Host sends the parameter (55) again with all that information.

Analyzing the fourth and last frame, sent from the DHCP server to the Host, we can gather other important information.

Source MAC ADDRESS of the DHCP server (08:00:27:B1:0D:45) with UNICAST DESTINATION (08:00:27:91:F7:D0)
Source IP of the DHCP server (192.168.56.56) with UNICAST DESTINATION (192.168.56.100)
Source PORT of the DHCP server (67) with DESTINATION (68) – Both UDP
Message type: ACK

Below are the relevant details about DHCPACK.

Now we have the same information that was sent to the Host at the time of DHCPOFFER, but representing one more “acceptance” that all this information was successfully reserved and the Host can now use them.

After the DHCPACK is sent, there is no more communication between the Host and the DHCP server until the IP lease time expires. Then, there is again an exchange of information between them. In this case, since the Host already knows the DHCP server and the DHCP server already made the first IP reservation for the Host, there is no more DHCPDISCOVER and DHCPOFFER processes, and in this case only DHCPREQUEST and DHCPACK are used again.

In the image below, we have a capture that I made at the moment the Host requests IP renewal from the DHCP server. All communication is now done via UNICAST, as they both know each other.

Analyzing the first frame, sent from the Host to the DHCP server, we can confirm that all communication is now Unicast, unlike the first Request.

Source MAC ADDRESS of the Host (08:00:27:91:F7:D0) with UNICAST DESTINATION (08:00:27:b1:0d:45)
Source IP of the Host (192.168.56.100) with UNICAST DESTINATION (192.168.56.56)
Source PORT of the Host (68) with DESTINATION (67) – Both UDP
Message type: REQUEST

Opening the parameters of the Request again, we have some important information. Now in the “Client IP Address” field, we already have the Host’s IP information, very important information for the DHCP server, because with this information it can identify who is requesting the renewal. The rest of the information is the same as the previous Request, including the (55) parameter, where all those necessary network information are requested.

Analyzing the second and last frame sent from the DHCP Server to the Host, we have some other interesting information

Now, the server has in the “Client IP address” field the IP of the Host that requested the IP and is sending the renewal IP, which is the same as before. Since the information in the “Client IP address” parameter was filled, the server understands that the request is a renewal and not a new lease. The server then responds with all the necessary information for the Host to have its IP renewed.