Introduction
In this story, we will demonstrate how DHCP works in the eyes of the machines. Specifically, we will go deep and analyse 4 types of DHCP packets from DORA using Wireshark. If you would like to learn how DHCP works in the eyes of human, read here instead.
Let’s quickly recap on DORA. DHCP use (D)iscover, (R)equest, (O)ffer and (A)cknowledge to assign dynamic IP to network hosts. We have learnt the intuition behind each messages in DORA; and that network hosts can automatically obtained an IP by completing DORA process. But how does the DHCP client and DHCP server knows who is asking for an IP? Who is the server in the LAN? What’s IP is being offered by the server? and whether the client accept the IP address that is being offered? Well, simply because any hosts that support TCP/IP understand DHCP — and that’s where all the magic lies; in the packet header of DHCP packets from DORA.
Here, we explain the DHCP DORA using the packets obtained from this network (shown below). There are two end points; one being the DHCP client, and one being the DHCP server. We sniff the network when the end point is asking for a dynamic IP. The DORA messages are captured using Wireshark (a popular network sniffer). The packet capture file (.pcap) of DORA can be downloaded here for your own experiment. Note: in Wireshark, type ‘bootp’ in the filter bar to show only DHCP packets.
The DHCP Packet Header Explained
This is the general structure of DHCP packet header. The value in some of the fields changes depending on which type of DORA message that is currently being exchanged. Note that a DHCP header is encapsulated within an IP packet. Let’s go through some of the important fields in the header.
OP Code (8 bits)— this field indicates whether this DHCP packet is a request or a response packet. In DORA, the Discover and the Request are consider as request packet; meanwhile, the Offer and Acknowledge are consider as response packet. The value 0x01 represents request, while 0x02 represents response. For example, if we examine the OP Code of a DHCP Discover, we will find 0x01 in this field; whereas we will find 0x02 if we examine a DHCP Acknowledge packet.
Hardware Type (8 bits) — this field indicates the type of Layer 2 protocol that is using the DHCP. Some examples of layer 2 (the data link layer) protocols includes Ethernet and 802.11x. Each protocols are assigned a unique identifier which is found in this table. For our example, the client and server are connected through an Ethernet connection. So, if we examine the any of the DHCP packets for this network; we will find 0x01 in the ‘Hardware Type’ field that indicates Ethernet is being used. When your iPhone ask for an IP, we will find 0x06 in this field that indicates 802.x protocol.
Hardware Address Length (8 bits) — this field indicates the length of the hardware address. This ‘hardware’ here refers to the ‘hardware type’ specified earlier. In our case, it is the Ethernet address length which is 6 bytes. So, we will find 0x06 in this field when we examine the packet header.
Hops (8 bits) — this field indicates the number of hops the DHCP DORA packet can travel before being discarded. When a packet traverse from one network to another, it is consider 1 hop count. Hop count is similar to the time-to-live field in IP header; this value is decremented by 1 every time a packet traverse across a router (to prevent packet looping). For example, if the hop value here is set to ‘2’; this means that this DORA packet can only go pass 2 routers before being discarded. Normally, this value is set to 0x0 or 0x1 because DHCP only serves its own LAN (remember that DORA are all broadcast messages and broadcast messages do not get out from its own LAN). The hop count, in some rare cases might have value higher than 1 when the DHCP-helper options is used.
Transaction ID (32 bits) — this number is used to identify the DORA’s ID. This is an arbitary number generated by DHCP protocol. Each round of DORA will share the same transaction ID. This ID is important because in a large network, there might be many hosts that are asking for IP at the same time. This means that there are multiple sets of D-O-R-A floating around the LAN. Thus, each host will look into this ID to check if a particular DORA messages is destined for it. In our example, the four DORA message should have the same transaction ID of 0xa27af44c.
Seconds (16 bits) — this field indicates the elapsed time since the client ask for an IP. The timer is cumulative. For example, let’s say each steps in D-O-R-A takes 10 seconds. In the first Discover packet, the timer is set to 10 seconds. In the second Offer packet, the timer value is now 20 seconds. In the third Request packet, the timer is now 30 seconds. Lastly, in the Acknowledgement packet, the timer is now 40 seconds. This means that by the time the client get a valid IP; it took DORA 40 seconds to complete the request. This value is important so that the server know if a DHCP offer is not being accepted; and that it can safely return this IP address back to the IP pool for future request.
Flags (8 bits) — this field indicates the flags option in the DHCP header. We are only concerned with the first bit among these 8 bits. The first bit indicate if it is a broadcast or a unicast. If the first bit is 0, it is a broadcast; if it is 0, it is a unicast. This means that we will see 1000 0000 for a broadcast; and 0000 0000 for a unicast.
Client IP (32 bits) — all IPv4 is 32 bits long. This field indicate the IP address of the DHCP client. In TCP/IP, any new host who join a network without an IP address will use 0.0.0.0 temporarily. Throughout all four DORA messages; this field is set to 0.0.0.0. That’s because the client can only start to use the IP offered after DORA completes. This is also the reason why all DORA messages are broadcasted; because without a valid IP; the DHCP server is not able to build a unicast packet destined to the DHCP client (everyone is 0.0.0.0 before getting an IP). If there is any IP here, then there is no need for DORA in the first place.
Your IP Address (32 bits) — this field hold the IP address that is being offered by the server to the client. Client checks on this field to find out what’s the IP being offered. For example, if the server offers 192.168.1.100 to the client; then this field is set to 192.168.1.100. This is perhaps the most important field in DHCP offer. In fact, this field is only set by the Offer and Acknowledgement. For other times, this field is always set to 0.0.0.0.
Server IP (32 bits) — this field indicates the IPv4 address of the DHCP server. Although client’s IP is 0.0.0.0; remember that the server has a valid static IPv4 address. In our example, the server has the IP 172.16.20.211. That means, this field is set to 172.16.20.211 in the Offer and Acknowledgement packets. Notice that in the Discover and Request, this server IP is still set to 0.0.0.0 despite the server already informed the client about its IP address in the Offer packet. In truth, this address serve no purpose as the client simply does not care about the what’s the Server IP in DORA.
Gateway IP (32 bits) — this field indicate the gateway IP address in LAN to reach a remote DHCP server. Although each LAN typically has it owns DHCP server; there are cases where a global DHCP server is used to serve multiple networks in the enterprise network. This means that, for a client in LAN1 to get an IP; it might need to contact a server in LAN8; which is not in the same LAN. Remember that DHCP DORA are broadcast messages. When the client send Discover, this packet will be discarded by the router because router do not forward broadcast. When this IP is set; together with the DHCP-helper option; the router would rewrite the packet header of DORA into unicast message and forward it to the remote DHCP server in LAN8 instead of discarding it.
Client Hardware (16 bytes) — this field indicates the MAC address of the DHCP client. In our case, this field is set to 00:01:1C:E8:23:21. This value must be consistent for all four DORA messages. In fact, this value is exactly the same with the Ethernet address value in the Ethernet header.
Options (8–214 bytes) — the options field allows DHCP to specify what types of DHCP messages that is being encapsulated in the DHCP packet. There are many different types of DHCP messages; here, we only focus on four (DORA). There are two parameters to indicate options: (a) the ‘code type’ and (b) ‘the data length’. The code is used to indicate the type of DHCP data in the DHCP packet. The data length is used to indicate the size of the DHCP data. Refer to this table for the full listing. DORA messages use code ‘53’; with the length of 1. The individual code for Discover is 0x01; Offer is 0x02, Request is 0x03 and the Acknowledge is 0x05.
For example, a Discover message will has 0x35 01 01 in the option field. The ‘35’ indicates this is DORA packet. The first ‘01’ indicates 1 bit in length. The second ‘01’ indicates Discover. Similarly, an Offer will has 0x35 01 02; a Request will has 0x35 01 03 and an Acknowledge will has 0x35 01 05.
Analysing DORA packets
(A) DHCP Discover
This is an example of how DHCP header looks like with the values filled.
The OP code is 1; this indicates that Discover is a request packet. The HW Type is 1; this indicates that the communication happens on an Ethernet network. HW LEN is 6; this confirmed that Ethernet is being used as MAC address is 6 bytes long. All IP address is set to 0.0.0.0; which is common for a discover since the client does not know anyone yet. The CLIENT HARDWARE ADDR is set to 0001.6392.C086. We can easily confirm this by checking the for the MAC address on the DHCP Client.
(B) DHCP OFFER
The OpCode is 2; which indicates a response. The rest of the fields are the same. Your Client Address is set to 172.16.0.1. This is the IP address being offered to the DHCP Client. The DHCP server IP is 172.16.20.211 as indicated in the Server Address field. Client HW Address is still the DHCP Client’s MAC as seen in the DHCP Discover. The Domain Name Server option is set to 10.10.10.2; which is used to inform the DHCP client that this is the DNS server IP for this LAN. This means that when the client accept this offer; it will set its own IP to 172.16.0.1 and the DNS Server to 10.10.10.2. The Options is set to 0x35 01 02.
(C) DHCP REQUEST
The fields found in DHCP Request are similar to DHCP Discover. The Options is set to 0x 35 01 03.
(D) DHCP ACKNOWLEDGEMENT
The fields in DHCP ACK is similar to DHCP Offer; except the Options is set to 0x35 01 05.
Analysing DORA on Wireshark
Wireshark can readily decode DHCP packets out of the box. Wireshark shows the different types of DORA based on the DHCP Options. Now let’s try to to analyze a DORA packet based on what we’ve learnt earlier. The example shown here is based on this DHCP.pcap file.
Wireshark shows the decoded information in a hierachal tree view for clarity. We only expands the fields of interest to reduce clutters. Decoding with Wireshark is so intuitive that you do not really need to understand DHCP header structure. In the first line, Wireshark displayed this as the Discover packet; this means there is no need for us to map the ‘Message type’ of 1 to ‘request’; the ‘Hardware type’ of 0x01 to Ethernet etc….
Since this is a Discover, all IP is set to 0.0.0.0. Notice that in the Option (50); the client requested 172.16.20.104. This is common for a host that has previously joined the network. In the previous lease, this host is most likely to have used the IP 172.16.20.104. Now when it is rejoining; it is requesting the server to reassign the same IP it used previously. The DHCP server in most case will entertain this request, unless this IP has been assigned to some other hosts.
So, there you go. That’s how you analyze DORA packets in Wireshark to find out more about what’s going on under the hood when DHCP is used. We do not show further examples of analysis on Offer, Request and Acknowledge on Wireshark for brevity.
