| Date: | Tue, 25 Sep 2018 15:50:16 +0000 |
| From: | cathya@isc.org |
| Subject: | [ISC-support #13390] Improve documentation of the operational algorithms underlying dhcp-cache-threshold |
| To: | dhcp-public@isc.org |
From a corner case investigation of constantly decreasing lease times being offered to clients on renewal, we uncovered a situation where unusual configuration settings for:
preferred-lifetime
default-lease-time
dhcp-cache-threshold
.. In combination with clients that renew prematurely, could lead to a situation where a client could be offered ever-decreasing lease lifetimes (spiralling down to ridiculously low values).
This, when understanding how the settings are applied, was not unexpected - but would not have been realised as a drawback by administrators because we don't clearly document the operating parameters.
We considered the possibility of adding checks to curtail this behaviour, but trying to cater for it in code would entail adding a run-time check on each client packet, as the lease times depends upon server configuration and what the client actually sends, and then taking some action based upon that. (And one would also have to then decide upon an appropriate action).
This appears to be the first and only significant report of such a problem, and ISC DHCP is mature software in which we're investing only minimal engineering effort at this stage in its lifecycle, so we're reluctant to attempt to deal with this at a code level.
So, rather than trying to guess what admins intend, we think that it is better to add some additional verbiage to the documentation describing possible pitfalls of various values. The man page currently says it is based on the "total lease time" - which is not terribly helpful or informative.
Could 'do better'....