DHCP client response to an offer with invalid parameters

[David W. Hankins]

On Tue, Aug 07, 2007 at 04:13:35PM +1200, mark mckinstry wrote:
> My reading of RFC2131 is that DHCPDECLINE is intended to indicate the
> client has detected the offered address is already in use - which would
> normally cause the server to offer a different address next time - so it
> shouldn't really be used to reject an offer containing invalid
> parameters?

That's correct - you shouldn't use DHCPDECLINE for this.

> My conclusion is that the client's "offer selection" code should really
> be doing at least some basic parameter validity checks, and that ideally
> this should be done via dhclient-script via a new state (SELECTING?).

The client already implements SELECTING internally (although most
people disable it by setting the timeout to zero), and we do perform
one check if configured by the user - an ACL can be applied to the
server identifier.  So the structure is already there.

I'm also not sure how to pass the full contents of multiple leases
down to dhclient-script in selecting state.  I don't think I'd like
how that would wind up looking.

So it's not a bad idea to add some sanity and judgement calls within
dhclient.  I left an RT ticket open on this actually I think.  Bogus
stuff like servers that offer the loopback address.  We can do that
in the client pretty easily.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins