DHCP client response to an offer with invalid parameters

[mark mckinstry]

What should a DHCP client do when it receives multiple offers, some of
which contain invalid parameters (e.g. IP address = 255.255.255.255 or
subnet mask = 255.255.255.254)?

I'm guessing that ideally it should evaluate all the offers for
validity and select one that is valid (by sending a DHCPREQUEST) - e.g.
the first valid one received. This is not what the ISC client code does,
however, - it simply selects the first offer regardless of validity
(despite what the commenting in the code says! - looks like a hangover
from v2.0).

A possible workaround might be to wait till the ACK is received back
from the server, then send a DECLINE if the offer/ACK contained invalid
parameters - which would then restart the whole DISCOVER/OFFER/.. cycle.
This could be achieved by adding some validity checking to
dhclient-script, for the BOUND/RENEW etc states, so it returns a
non-zero value if any of the parameters is invalid. However, it seems to
me this approach is inefficient and could result in some serious issues
- e.g. a bad (misconfigured) server could keep being the first to make
an offer - resulting in an infinite loop!

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?


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?).

Has anyone come across this issue - or even better come up with a fix?

Thanks
Mark McKinstry