dhcprequest function
David W. Hankins
David_Hankins at isc.org
Wed Mar 31 00:02:06 UTC 2004
On Mon, Mar 29, 2004 at 10:51:28PM -0500, dhcp.50.CHRIS94561 at spamgourmet.com wrote:
> I dunno about pretty clear. Were I implementing this I'd be inclined to
> ignore the multicast requirement and use the broadcast flag as my
> barrometer but that's just me.
forgive me for butting in. i neither wrote the comment nor do i have
all the state involved in the related function swapped into my brain
here.
but as i understand it, this is for the case where a relayed client is
unicasting a renewal and the dhcpd wants to NAK it. obviously, if
the client is directly attached we can (and do) broadcast back to it
wether it has unicasted the REQUEST or not.
so the broadcast bit doesn't even enter into it...the daemon does not
know of any relay for the client which can be used to produce a
broadcast in the client's local network, over which to deliver a NAK
with said broadcast bit set.
if we did, say, allow the configuration of relays in the subnet scope,
then it might be possible to send NAKs back via the configured relays,
and therefore as broadcasts in the client's network.
hmm, how attractive of a smurf amplifier would that be? anyone know
what percentage of machines return an ICMP port unreachable to directed
udp broadcasts on port 68?
by the way, is there actually a problem here somewhere you're trying to
trace down?
--
David W. Hankins "If you don't do it right the first time,
Operations Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
More information about the dhcp-hackers
mailing list