Solved DHCP 4 Step process: All Broadcast, or combo of Broadcast & Unicast? Conflicting accounts

---

Calling all Network gurus! (Broadcast, perhaps?)

I have had conflicting accounts about the progression:

1st step, DISCOVER, is clearly Broadcast, but after that I have seen conflicting accounts. If I remember correctly, the ITPros give the following: Broadcast, Unicast, Broadcast, Unicast. I have seen others, with B,B,B,U

I have heard/read that Request is Broadcast so that the other DHCP servers can cancel there offers, is this correct?

I have also heard/read that Cisco & Microsoft handle the progression differently.

I just checked back, ITPros have it B, B, B, U.
I understand that the client has no IP address until the 4 steps are complete, but why would the MAC address not be the basis for a Unicast in the Offer step (like an ARP reply that is Unicast)?

Anyway, thanks for the help untangling some of the knots of Networking study.

William

@william-fields

"I understand that the client has no IP address until the 4 steps are complete, but why would the MAC address not be the basis for a Unicast in the Offer step (like an ARP reply that is Unicast)?"

Below, I list the confusing links below for others who may not know what you're talking about.

So this comes down to what is the purpose of the MAC address? The MAC address will allow me to get the data to the device. But it's not the basis of how my computer COMMUNICATES. The MAC address provides a location but it doesn't mean that a device with an IP address (DHCP server) and a devices without one (DHCP client) can understand or communicate data. If DHCP were to do anything in this instance related to ARP, it would have to reverse ARP. The DHCP server has the client's MAC but not its IP address. So as you've suggested, if the DHCP server were to take it's MAC and translated to the associated IP address......uh, no IP address to find. So it wouldn't work. So until an IP address is on the device it must be a broadcast.

In this instance, I would have to say something that I can't say very often, the cisco documentation may be wrong in this instance. I'm sticking with that until I know differently.

addedum: I apparently can't answer every question you actually posted. The request is a broadcast because the client doesn't yet have the valid IP address assigned to it. Until it's bound it will have to use broadcast. Since only the first DHCP server is allowed to respond there would not be another offer out there to the original DHCPDiscover.

https://technet.microsoft.com/en-us/library/Cc958935.aspx

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/12-4t/dhcp-12-4t-book/config-dhcp-client.html

Unfortunately, the answer is more complicated! DHCP Discover and DHCP Request messages sent by the client will be broadcast, with a source IP of 0.0.0.0 and a destination IP of 255.255.255.255. These messages contain a "Broadcast Flag", intended as a workaround for clients that are not able to receive unicast IP datagrams before they know their own IP address.

If the Broadcast Flag is set, the DHCP Offer and DHCP Acknowledge messages sent by the server or relay agent will also be broadcast, with the server's or agent's source IP and a destination IP of 255.255.255.255. If it is not set, the server messages will be unicast, with the server's source IP and the offered or assigned destination IP, using the Client MAC address contained in the DHCP Discover or Request message (ARP won't work yet since the client doesn't technically have an IP address until after it receives the DHCP Request message).

So depending on whether the client sets the Broadcast Flag, the communication will be either B, B, B, B or B, U, B, U. Never B, B, B, U!

All modern systems I know of are capable of receiving unicast IP datagrams before they know their IP address, so don't need the Broadcast Flag, and the DHCP standard (RFC 2131) specifies that such clients SHOULD clear the Broadcast Flag. But for some reason, Windows sets it by default. (At least Windows 7 does; I don't know about Windows 8 or Windows 10.) But some DHCP servers/relay agents don't support messages with the Broadcast Flag set, so Windows systems wouldn't work with them. Microsoft addressed this by adding a toggle feature: it tries first with the Broadcast Flag set, and if that doesn't work it tries again with the flag reset. This functionality was introduced in Windows Vista, but disabled by default; then in Windows 7 the toggle function was enabled by default. You can change the DHCP settings in the registry.

Linux DHCP clients clear the Broadcast Flag by default, but can be configured to set it if required for some reason with a command line or configuration file option. I don't know about other systems.

I have no idea how much detail certification exams will get on this, but it might be useful if you are trying to troubleshoot a real-life DHCP issue! Hopefully it explains why a Microsoft link says B, B, B, B and a Cisco link says B, U, B, U.

Note that DHCP renewal messages are all unicast since the client still has a valid IP address. So are DHCP messages between a relay agent and DHCP server.

@Rick-Sidwell ,

I see that I may have in this video said it wrong with the BBBU in other places I'm sure we got it right because in other places, I wasn't the one who said it.

Cordially,
Ronnie Wong
Host, ITProTV

Gentlemen,

Thanks so much for the clarification. I realize now my lack of understanding both of the DHCP and ARP process. This has been very helpful.
The Network knots are steadily getting untied and straightened out.

Onward hoe to Network+ and beyond!!

William

Rick Sidwell said...
"All modern systems I know of are capable of receiving unicast IP datagrams before they know their IP address, so don't need the Broadcast Flag, and the DHCP standard (RFC 2131) specifies that such clients SHOULD clear the Broadcast Flag. But for some reason, Windows sets it by default. (At least Windows 7 does; I don't know about Windows 8 or Windows 10.) But some DHCP servers/relay agents don't support messages with the Broadcast Flag set, so Windows systems wouldn't work with them. Microsoft addressed this by adding a toggle feature: it tries first with the Broadcast Flag set, and if that doesn't work it tries again with the flag reset. This functionality was introduced in Windows Vista, but disabled by default; then in Windows 7 the toggle function was enabled by default. You can change the DHCP settings in the registry."

RANT
I don't understand why Microsoft insists on marching to a different drummer! If they would just follow the standards, like everyone else, life would be so much easier. I remember when Vista first came out. There where several routers from which Vista would not receive a DHCP address. The fix was to edit the registry to set that toggle flag! VERY FRUSTRATING! Microsoft, get a clue!!
/RANT