[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now


Assistance with understanding packets in a DHCP request

Posted on 2011-05-12
Medium Priority
Last Modified: 2012-05-11
I am working through a book on TCP/IP and I am currently trying to learn how DHCP works via requests/acknowledgements, etc.

I've got a laptop plugged into a D-link router, via cable. The router is the DHCP server.  I am using Microsoft's Network Monitor to capture packets.

I started up the Network Monitor first, and then plugged in the ethernet cable.

I see the initial DHCP request coming from the laptop and I see the acknowledgement from the router.  My question pertains to the router acknowledgement.

On the results presented via Network Monitor, the ACK shows the destination h/w address for the acknowledgement (under the ethernet section of the message) as the broadcast address instead of the h/w address of the laptop (which was provided via the initial request broadcast).

In the DHCP specific portion of the ACK packet, the client h/w address is listed.

Why does the router encode the h/w address on the ACK with a broadcast address instead of the previously-provided client h/w address?  Doesn't this require the other devices on the network to do extra inspection of the packet since it is sent to a broadcast h/w address vs. being sent directly to the client h/w address?  (I understand why the IP portion needs to be broadcast at this point - the laptop doesn't have an IP address just yet).

Sorry if this should be obvious to me.  I am just learning.  Thanks in advance.
Question by:AgeOfEmpires
  • 4
  • 2
LVL 17

Expert Comment

ID: 35749148
You have just jumped off to the end without the beginning. Even before DHCP ack there are Discover/Offer/request action takes place. I am sure you are not looking at the entire sequence of events in the packets, else you would have seen that the client Identifier fields have the physical address of the network card in the requesting client in the ACK packets.

please give a read to the following link. It's nice.



Author Comment

ID: 35750950
Thanks for the response.  It seems that I may not have explained my initial question properly, based on your response to it.  I am talking about the initial handshaking that goes on (Discover, Offer, Response, Acknowledgment).   In Microsoft’s Network Monitor, these are listed as: 1) REQUEST, 2) ACK, 3) INFORM, 4) ACK.  It is the 2nd (and 4th actually) step that I am asking about.

Based on my understanding, the Network level deals with h/w (MAC) addresses and the Internet level handles the IP stuff.

In step 1, I see the initial request for a DHCP server from the laptop.  That packet is coded with the client's MAC address, a source IP of (as expected) and a the destinations of FF:FF:FF:FF:FF:FF (h/w broadcast, as expected) and (IP broadcast, as expected).

In step 2, the Offer from the router is sent back.  It uses both h/w and IP broadcast addresses for the contents of the offer, even though it knows (from step 1) the h/w address of requester.  I know this is “as designed” (your link at Microsoft backs this up).  

My real question is what is the purpose of this design?  This offer packet, if my understanding is correct, is picked up by ever device on the network, and because it is addressed to a h/w broadcast request, each device must then pass the packet up to the next level of TCP/IP before the non-destination devices can determine that the message wasn’t intended for them and discard it.  IS this correct?  If so, why isn’t the offer simply sent back to the h/w address provided initially in step 1 so that every other network device discards the packet at the Network layer?

Hopefully this is a little clearer explanation of my question.  Again, maybe I’m missing something simple here.

Thanks again in advance.
LVL 26

Expert Comment

by:Leon Fester
ID: 35752350
From the MS link above, under DHCPREQUEST:

"The client retains because the client hasn't received verification from the server that it's okay to start using the address offered. The Destination is still broadcast, because more than one DHCP server may have responded and may be holding a reservation for an Offer made to the client. This lets those other DHCP servers know they can release their offered addresses and return them to their available pools."

The same logic applies.

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.


Author Comment

ID: 35754740
I understand the logic behind broadcasting the DHCP Request.  The client is letting any/all DHCP servers know the IP address offer it is accepting.  The message needs to be broadcast so that all DHCP servers will get the packet and see whether their offer has been accepted or not.

But this isn't the step I am questioning.  I am asking about the PRIOR step (see my 2nd post above) - the DHCP Offer.  That is coming from the DHCP server and is intended for the client that sends the initial request for a DHCP server/address (step 1 of the whole process).

Any/all DHCP servers that respond to step #1 of the whole process will know the h/w address of the client asking for an IP address - that MAC address is contained in the initial packet.  However, by design apparently, instead of putting the client's MAC address in the Network portion of the header, the DHCP server puts a broadcast MAC address into the response.

The result?  Based on my understanding, all devices on the network see the broadcast MAC address at the Network layer and (needlessly, in my opinion, based upon my understanding so far of TCP/IP) pass the packet up to the IP layer, where the non-destination devices discover "oh, this is a request for an IP address, and I didn't request an IP address, so I guess this packet isn't for me afterall".

To me, the process would be more efficient if the DHCP server, in building it's response to the initial request, addresses the packet in step #2 to the MAC address of the client that sent the initial request.  That way, every other device would be able to discard the packet at the Network layer - seeing the MAC address wasn't theirs - instead of performing the extra processing of the packet at the IP layer.

Now, I believe the designers of this whole process obviously knew what they were doing and it is designed for optimum efficiency.  I don't see it as optimally efficient based on my understanding so far, so I know there must be something I'm missing.  I am trying to discover what that is.  Nothing I've read so far explains to me why the broadcast MAC address is used in step #2 (initial response from DHCP server back to client) instead of the client's specific MAC address which was provided in step #1 to the DHCP server.  Please note, I perfectly understand why the DHCP server encodes this response at the IP level with the broadcast IP address - the client doesn't yet have an IP address - this make perfect sense.

Author Comment

ID: 35754903
To just sort of summarize, and hopefully clear up any lack of clarity in my more lengthy descriptions, referring back to the Microsoft linke, if you look at the summary table at the first of the article, and just after the statement: "Below is a summary table of the conversation between client and server, which is followed by a packet-level description of the process: ", you will see that in each of the 4 steps, the column labeled "Dest MAC addr" uses the Broadcast address.  I am trying to figure out why the 2 rows for the DHCPsrvr are using the Broadcast MAC address instead of the client's MAC address.

LVL 26

Accepted Solution

Leon Fester earned 1500 total points
ID: 35773405
It's very commendable that you're trying to understand DHCP and TCP/IP but you don't give any indication of your current level of knowledge.

How much do you already know about TCP/IP and Ethernet in general?

Your best option to find really technical information like the kind you're looking for would be to look at the RFC for that specific product.

http://tools.ietf.org/html/rfc2131 - I think section-3 covers this conversation.

Author Closing Comment

ID: 35890172
Although the question wasn't specifically answered by anyone, the RFC's provide a good place for more investigation into why DHCP works the way it does.


Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Ever wondered why you had to use DHCP options (dhcp opt 60, 66 or 67) in order to use PXE? Well, you don't!
Configuring network clients can be a chore, especially if there are a large number of them or a lot of itinerant users.  DHCP dynamically manages this process, much to the relief of users and administrators alike!
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
Screencast - Getting to Know the Pipeline

867 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question