DHCP multicast/unicast

[Emsi at gmx.de]

Hi,

I know that the shared-network statement has nothing to do with this directly, but I have read, that the mentioned behaviour is topology-dependent and "shared-network" could influence this. 

"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."

Does this behaviour really only depend on the Broadcast-Flag in the Client-Queries? In that case I couldn't change it, apart from setting Registry-Values manually which is no option for us. What "cheats when it can" means? I read it like "altough it has the Broadcast-Flag set, it sends a unicast-response". And it says that this is not RFC-conform behaviour. 

Any ideas?

Thanks!

Oliver



Glenn Satchell schrieb:

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