If you missed part one of this article series please read Understanding the DHCP Protocol (Part 1).
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.
11:51:04.546875 192.168.1.102.68 > 192.168.1.1.67: [udp sum ok] xid:0x908759f5 C:192.168.1.102 vend-rfc1048 DHCP:REQUEST CID:[ether]00:0c:6e:8c:d4:61 HN:”don” FQDN:”don.” VC:”MSFT 5.0″ PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+T249+VO (ttl 128, id 30744, len 328)
0x0000 4500 0148 7818 0000 8011 3dd5 c0a8 0166 E..Hx…..=….f
0x0010 c0a8 0101 0044 0043 0134 8ec4 0101 0600 …..D.C.4……
0x0020 9087 59f5 0000 0000 c0a8 0166 0000 0000 ..Y……..f….
0x0030 0000 0000 0000 0000 000c 6e8c d461 0000 ……….n..a..
0x0040 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0050 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0060 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0070 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0080 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0090 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00a0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00b0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00c0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00d0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00e0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00f0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0100 0000 0000 0000 0000 6382 5363 3501 033d ……..c.Sc5..=
0x0110 0701 000c 6e8c d461 0c03 646f 6e51 0700 ….n..a..donQ..
0x0120 0000 646f 6e2e 3c08 4d53 4654 2035 2e30 ..don.<.MSFT.5.0
0x0130 370b 010f 0306 2c2e 2f1f 21f9 2bff 0000 7…..,./.!.+…
0x0140 0000 0000 0000 0000 ……..
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.
11:51:04.562500 192.168.1.1.67 > 192.168.1.102.68: [udp sum ok] xid:0x908759f5 C:192.168.1.102 Y:192.168.1.102 vend-rfc1048 DHCP:ACK SID:192.168.1.1 LT:86400 SM:255.255.255.0 DG:1
92.168.1.1 NS:24.153.22.67,24.153.23.66 (ttl 64, id 0, len 576)
0x0000 4500 0240 0000 0000 4011 f4f5 c0a8 0101 E..@….@…….
0x0010 c0a8 0166 0043 0044 022c 2636 0201 0600 …f.C.D.,&6….
0x0020 9087 59f5 0000 0000 c0a8 0166 c0a8 0166 ..Y……..f…f
0x0030 0000 0000 0000 0000 000c 6e8c d461 0000 ……….n..a..
0x0040 0000 0000 0000 0000 0000 0000 0000 0000 …………….(the above packet has been truncated by me for brevity)
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.
If you missed part one of this article series please read Understanding the DHCP Protocol (Part 1).
