Assistance with understanding packets in a DHCP request
I am working through a book on TCP/IP and I am currently trying to learn how DHCP works via requests/acknowledgements,
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.
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.
ASKER
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 0.0.0.0 (as expected) and a the destinations of FF:FF:FF:FF:FF:FF (h/w broadcast, as expected) and 255.255.255.255 (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.
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 0.0.0.0 (as expected) and a the destinations of FF:FF:FF:FF:FF:FF (h/w broadcast, as expected) and 255.255.255.255 (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.
From the MS link above, under DHCPREQUEST:
"The client retains 0.0.0.0 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.
"The client retains 0.0.0.0 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.
ASKER
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.
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.
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
Thanks.
Thanks.
please give a read to the following link. It's nice.
http://support.microsoft.com/kb/169289
Best,