BootP Flags in DHCPOFFER Packet

Glenn Satchell 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

       always-broadcast flag;

       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.

regards,
-glenn


More information about the dhcp-users mailing list