I'm looking at some DHCP packets through wireshark. I notice that in the bootp section, there is a broadcast flag.
However, the dest IP is 255.255.255.255. Isn't it enough to indicate that it's broadcasted? Why is the flag needed?
Thanks,
lang2
DHCP flag serves a completely different purpose. It is set by a client to indicate to a server how the reply should be sent to back to the client. DHCP client sends its request by broadcast, initially, since it doesn't know the server's IP address. However, since the server knows the client's IP (it just provided it with one), server can send the reply back by unicast even if the request was sent by broadcast. Per RFC2131:
A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0.
These are at different layers in the ISO stack. A destination IP of 255.255.255.255 makes the packet a broadcast IP packet at the IP level. Setting the broadcast flag inside the DHCP packet would not do this.
The flag itself can be considered information to the DHCP server - it is telling the server that it should reply by broadcast. This is most often the case where the client does not yet have an IP address and so requires a broadcast reply as there no IP yet to unicast to. The DHCP server shouldn't need to inspect the packet headers to figure out how to respond, it is up to the dhcp protocol to make this clear.
You could conceivably have a DHCP request sent as a unicast packet, sent directly to the DHCP server - but the broadcast flag could still be set inside the DHCP flags to let the dhcp server know that it needs to reply by broadcast no matter what the headers looked like.
In summary, the IP and UDP headers tell the IP and UDP layers of the stack know what is going on, whereas the DHCP content is application layer, and let the DHCP application know what is going on.
-
DHCP Discovers are always broadcast. If the broadcast bit did what you said, it wouldn't be needed because it would always be set. Please read haimg's answer, which is correct. I think @lang2 accepted the wrong answer. – Spiff Sep 11 '12 at 6:56
-
The DHCP broadcast bit does NOT mean the Discover or Request was sent broadcast. The broadcast bit is to tell the DHCP server that the reply needs to be sent broadcast regardless (which is not usually necessary). Your clause "it is telling the server that the packet was broadcast" is not correct. – Spiff Sep 11 '12 at 15:37
-
Actually the broadcast bit is usually not set on Discovers and Requests even when the client does not have an IP address, because most client implementations can still receive unicasts even if they don't have an IP address yet. In this most common case, Offers and Acks are unicasted to the IP that they're Offering/Acking (even though in a sense no one really owns it yet). This bit exists for the sake of a few rare/lame client implementations that can't receive unicasts unless they have an IP address already. Exactly as haimg cited from the spec. – Spiff Sep 11 '12 at 23:15
-
@Spiff how do you unicast to a client that doesn't have an IP address? You are talking about layer 2 unicast rather than layer 3 unicast? – Paul Sep 11 '12 at 23:41
-
"How" is touched on in RFC 2131 in the paragraph immediately before the one haimg quoted. And it's unicast at both layer 2 and layer 3. – Spiff Sep 12 '12 at 11:52
