Community Area

Understanding the DHCP Protocol (Part 2)

In part one of this article series on DHCP we went over a lot of the theory on the protocol itself. Specifically what types of messages there are, how DHCP works, and why it is normally used. In this last part we will look at two DHCP packets that exemplify what DHCP is all about.

DHCP and you Part II

In part one of this article series on DHCP we have seen that this protocol is typically enabled on most networks. This greatly eases the workload of the network administrator as DHCP will provide clients with key configuration details. Details such as what its IP address will be, the subnet mask, and the DNS servers it should use. Rather important information if you want to be able to access the Internet. Furthermore, we covered some of the various DHCP message types that you could encounter on a network. Well in this part of the article series we will actually look at two of the more common DHCP message types as seen from the packets perspective. It is always helpful to have a packet to look at in order to view a protocols usage. This will give you some context, and a reference point.

Down in the weeds

Well it is now time for everyone’s favourite part! Let’s roll up our sleeves as it were, and take a look at some actual packets. Being comfortable with looking at packets as they appear on the wire will give a you a level of comfort should you ever have to approach packet analysis. Either that, or you will have to buy a very expensive protocol analyzer! With that said let's get on with the task at hand. Please note that I will comment on the packet in question directly beneath it.

Alright then, in the packet above us we can see that the UDP header starts at the underlined bytes of 0044. From there onwards we have the BOOTP or bootstrap protocol starting at the underlined two bytes of 0101. We largely have not really discussed the relationship that BOOTP has with DHCP as many people find it rather confusing to say the least. It is a symbiotic one as in reality BOOTP asks for the client configuration such as IP address and such from the DHCP server. With that said, in reality you have packets like the one above that really contain BOOTP protocol data, and not the expected DHCP one. Though, as you may have guessed it, this information is sent to the DHCP server.

We can see, if we go from right to left in the above packet, that we start off with our packet timestamp. This is followed by the source address/port and then the destination address/port. The UDP checksum computation is “ok” as seen above. Next we have our “xid” number of 0x908759f5. This is basically the transaction number, much like that one found in DNS to keep track of queries and responses. Then we have the client IP address of 192.168.1.102. Now the vendor rfc 1048, and the DHCP message type. Next up is the client id as seen in the “CID”. Seen next is the hardware type [ether]. The following is the client MAC address noted by the six octets of hex 00:0c:6e:8c:d4:61. The next few fields are fairly self-evident as to meaning. Much like DNS this is a dense protocol that is generally best broken out using a protocol analyzer. On that note let’s take a look at the server response seen in the packet below.

First off please note that for the above packet we are seeing the DHCP server respond back to the client ie: the first packet in this article. I will not go back over and cover the same fields as I did above except for those that are different. You should note that the xid number as underlined above is indeed the same as the DHCP client packet seen above this packet. That, as mentioned, is a way for the DHCP client to keep track of various requests. After that value we see the client IP address that made a request of the DHCP server whose IP address as seen in this packet is 192.168.1.1 Following that we have “Y: 192.168.1.102” which breaks out to the clients IP address. In this case the same IP address as the client who made the initial request.

Next we see the DHCP:ACK as underlined above. This denotes the DHCP message type, or also known as Option 53. After this we have the “SID: 192.168.1.1” and this is the server identifier. In other words the IP address of the DHCP server. Next we have our “LT: 86400” which is our lease time for the IP address being confirmed for the DHCP client by the DHCP server. That 86400 is a unit measured in seconds and in reality is 24 hours. After that is the “SM: 255.255.255.0” which relates to a subnet mask. Now I have spent a fair amount of time running the “DG:1” field to ground and have found it to be related to “default gateway”. That being said I would of thought this would list the full IP address of the gateway. Should any of you have further information on this please feel free to drop me an email. As you can see, sometimes when there is something you don’t know it is best to use resources such as our sister site Security-Forums.

Well as you can see now, DHCP is indeed a rather involved protocol when you actually dig into it at the packet level. Overall it may not seem complex, but once you begin reading up on it you can quickly see it is. Much like NetBIOS, still waters often run deep. I hope you enjoyed this two part series on DHCP and as always I welcome your feedback.

The Author — Don Parker

Don Parker, GCIA GCIH specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security. You can contact Don Parker at dparker@bridonsecurity.com