Re: NT 3.51 and broadcast bit

[John Kemp <[e-mail]>]

I was mildly interested in this, as I have seen some of those
funky NT dhcp log errors on the client too.   It looks like the 
ISC DHCP Server (4.6B) probably handles this correctly.   Haven't
tried it yet though, so this is purely FYI...

John Kemp ([e-mail])

>From isc dhcp server 4.6B "dhcpd.c":

        /* If this was gatewayed, send it back to the gateway... */
        if (raw.giaddr.s_addr) {
                to.sin_addr = raw.giaddr;
                to.sin_port = server_port;
                if (outgoing.packet_length < BOOTP_MIN_LEN)
                        outgoing.packet_length = BOOTP_MIN_LEN;
..
 
        /* If it comes from a client who already knows its address and
           is not requesting a broadcast response, sent it directly to
           that client. */
        } else if (raw.ciaddr.s_addr && offer == DHCPACK &&
                   !(raw.flags & BOOTP_BROADCAST)) {
                to.sin_addr = packet -> raw -> ciaddr;
                to.sin_port = htons (ntohs (server_port) + 1); /* XXX */
..
        /* Otherwise, broadcast it on the local network. */
        } else {
                to.sin_addr.s_addr = htonl (INADDR_BROADCAST);
                to.sin_port = htons (ntohs (server_port) + 1); /* XXX */
        }

The DHCP RFC (1541) says:

   Normally, DHCP servers and BOOTP relay agents attempt to deliver
   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
   unicast delivery.  The IP destination address (in the IP header) is
   set to the DHCP 'yiaddr' address and the link-layer destination
   address is set to the DHCP 'chaddr' address.  Unfortunately, some
   client implementations are unable to receive such unicast IP
   datagrams until the implementation has been configured with a valid
   IP address (leading to a deadlock in which the client's IP address
   cannot be delivered until the client has been configured with an IP
   address).

   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.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].

   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably
   255.255.255.255) as the IP destination address and the link-layer
   broadcast address as the link-layer destination address.  If the
   BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP
   unicast to the IP address specified in the 'yiaddr' field and the
   link-layer address specified in the 'chaddr' field.  If unicasting is
   not possible, the message MAY be sent as an IP broadcast using an IP
   broadcast address (preferably 255.255.255.255) as the IP destination
   address and the link-layer broadcast address as the link-layer
   destination address.