BootP Flags in DHCPOFFER Packet
Glenn.Satchell at uniq.com.au
Tue Aug 28 12:53:28 UTC 2007
>From: "Benjamin Wiechman" <benw at meltel.com>
>To: <dhcp-users at isc.org>
>Subject: BootP Flags in DHCPOFFER Packet
>Date: Mon, 27 Aug 2007 12:16:10 -0500
>I haven't seen this issue in the ISC dhcp server, but since there are many
>people here who are deeply familiar with the RFC and behaviors I was curious
>if someone could explain this to me.
>We are trying to enable NAT on some network devices and I am seeing this
>issue (among others!)
>When the device responds with a DHCPOFFER it isn't consistently setting the
>bootp flags in the bootstrap protocol packet.
>See the two wireshark captures to demonstrate this:
Err, the list software strips attachments. You'll need to post them in
the body of the email.
>In one the bootp flags are set to broadcast - this packet is ignored by the
>client (winxp in this case - running realtek card)
>In the other the bootp flags are set to unicast - this packet is accepted
>and processed by the client.
>Is one of these a violation of the RFC, or is there some other reason the
>first would be ignored by the client while the second is accepted?
I believe this is allowed. There is a flag in the request where the
client indicates whether it wants the response broadcast or unicast.
The reply can be overridden using the always-broadcast statement. This
is from the dhcpd.conf man page:
The always-broadcast statement
The DHCP and BOOTP protocols both require DHCP and BOOTP
clients to set the broadcast bit in the flags field of the
BOOTP message header. Unfortunately, some DHCP and BOOTP
clients do not do this, and therefore may not receive
responses from the DHCP server. The DHCP server can be
made to always broadcast its responses to clients by set-
ting this flag to 'on' for the relevant scope; relevant
scopes would be inside a conditional statement, as a
parameter for a class, or as a parameter for a host
declaration. To avoid creating excess broadcast traffic
on your network, we recommend that you restrict the use of
this option to as few clients as possible. For example,
the Microsoft DHCP client is known not to have this prob-
lem, as are the OpenTransport and ISC DHCP clients.
More information about the dhcp-users