DHCP multicast/unicast

[Glenn Satchell]

>Date: Sun, 27 Apr 2008 16:47:08 +0200
>From: Emsi at gmx.de
>Subject: DHCP multicast/unicast
>To: dhcp-users at isc.org
>X-Authenticated: #678488
>X-Flags: 0001
>X-Provags-ID: V01U2FsdGVkX1/0rA1cu6P0+CLRVorA40lpvyN6NjUx/SJpdnsgXM 
ztqDkZnex90Bj6UT+vyb1mcDOT33Ub59tjSA== 
>X-GMX-UID: 26kieY17YmYBbm5tb3c356pCWkZTQdST
>X-archive-position: 6182
>X-ecartis-version: Ecartis v1.0.0
>X-original-sender: Emsi at gmx.de
>List-software: Ecartis version 1.0.0
>X-List-ID: <dhcp-users.isc.org>
>X-list: dhcp-users
>
>Hi,
>
>I'm running a large switched network, where we separate each port via a 
>3com feature called port isolation, which puts every single port in a 
>"vlan" for security purposes. Unfortunately I have seen with a sniffer on 
>a users end-port, that you can see DHCPOFFERs which belong to other users on 
other ports, cause isc-dhcpd-V3.0.4 is sending the offers as link layer 
broadcast to ff:ff:ff:ff:ff:ff.  I read following in a book about that topic:
>
>Note: The Internet Software Consortium (ISC) DHCP server cheats when it
>can by setting the IP destination address to 255.255.255.255 and the
>link layer destination address to the client's link-layer address. This
>is technically incorrect, but it works well and reduces the amount of
>broadcast traffic generated by the DHCP server."
>
>Under which conditions does ISC-DHCPD answer with unicast offers? Does 
>the parameter "shared-network" influences this behaviour? How can I force 
>ISC DHPC to answer with unicast (link layer)?
>
>thanks!
>Oliver
>

"shared-network" has nothing to do about whether or not to broadcast
replies to a client.

The dhcpd.conf man page outlines the "always-broadcast" command,
however the default is not to broadcast unless the client indicates
that it wants a broadcast reply.

     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.

The bit about using 255.255.255.255 occurs early in the
DHCPDISCOVER/DHCPREPLY phase where the client does not yet have an IP
address to unicast to. There are details of this conversation in the
files doc/References.{html,txt,xml} that comes with the source
distribution:

   There are a few things that DHCP servers, relays, and clients all
   need to do in order to speak the DHCP protocol in strict compliance
   with RFC2131 [8].

   1.  Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to
       IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP
       address yet) interface.

   2.  Receive a UDP packet from IP:remote-system LinkLayer:remote-
       system, destined to IP:255.255.255.255 LinkLayer:Broadcast, again
       on an unconfigured interface.

   3.  Transmit a UDP packet from IP:Self, Ethernet:Seelf, destined to
       IP:remote-system LinkLayer:remote-system, without transmitting a
       single ARP.

   4.  And of course the simple case, a regular IP unicast that is
       routed via the usual means (so it may be direct to a local
       system, with ARP providing the glue, or it may be to a remote
       system via one or more routers as normal).  In this case, the
       interfaces are always configured.

RFC2131 is also worth reading to cover this area. It is the definitive
reference for how DHCP is meant to work.

regards,
-glenn