DHCP Broadcast behavior

[Simon Hobson]

King, Michael wrote:
>I tried finding something to answer this in the archives, but the only
>hit I got was back from 2001, so I don't know if it's still standard
>behavior.
>
>I have a wireless Bridging AP, with far end and near end endpoints.
>
>In the Design guide is the following statement.  So does ISC DHCP
>respond broadcast, or unicast?
>
>However, there is an issue with some
>DHCP servers that use a broadcast DHCP response. The RAPs in the network
>accept a broadcast
>response but do not forward to any MAPs that have made a request. By
>default, a Windows DHCP server
>sends its response by an IP broadcast (255.255.255.255). However, it can
>be configured to send DHCP
>responses via unicast

I don't get what you mean by "The RAPs in the network accept a 
broadcast response but do not forward to any MAPs that have made a 
request".

RAP I assume is remote access point, but MAP ?

It is an essential requirement of a network that it properly handles 
broadcasts. If broadcasts are filtered then a number of protocols 
(including DHCP) will NOT work. With DHCP, the first packets in the 
exchange can only be broadcast because the client does not yet have 
an address to use - and because the client doesn't even have a subnet 
either, then the broadcast must be to 255.255.255.255 and not the 
subnet broadcast address. When the client later renews (extends it's 
lease) then it can do so with unicast packets.

If the client and server are in different broadcast domains then you 
need a DHCP Relay Agent (aka BOOTP Helper) on the clients network. 
This picks up the broadcast, adds some information required by the 
server and sends it via unicast to the server. The server sends it a 
response which it then broadcasts on the clients network. In this 
situation, the client and server must be in different IP subnets - ie 
it's not valid to have one IP subnet split by a bridge that filters 
broadcast traffic.

Does this answer the question ?

Simon