Provide capability to specify lease lifetimes at Pool and possibly Reservation level
name: Feature request - Support `valid-lifetime` for pools
about: Management of lease lifetimes in IPv4 and IPv6 pools
(Apologies if I have filled the form in incorrectly. I wasn't sure which fields you wanted updated or replaced.)
Some initial questions
- Are you sure your feature is not already implemented in the latest Kea version?
- I have confirmed it is not implemented in 1.5 and can see no indication in documentation that anything has changed in 1.7.
- Are you sure what you would like to do is not possible using some other mechanisms?
- I do not believe it is possible.
- Have you discussed your idea on kea-users or kea-dev mailing lists?
- I have raised it on kea-users and a similar issue was previously raised in 2017 (https://lists.isc.org/mailman/htdig/kea-users/2017-March/000898.html)
Is your feature request related to a problem? Please describe.
- In our environment we mostly use reservations with long leases so that network problems do not cause a loss of address, but cannot do this with addresses from pools otherwise we would run out of pool addresses. We have pools and reservations in non-overlapping sections of the same subnets, so specifying the lease lifetime on the subnet is not an option. The ability to specify lease lifetimes on individual hosts would also be useful but far less important than being able to have different values for pools versus the rest of the subnet.
Describe the solution you'd like
I would like to see the valid-lifetime
attribute supported for pools and possibly reservations. Given the addition of max-lease-time
and min-lease-time
in 1.6, it would make sense to provide these as well for consistency although we are unlikely to use them.
Describe alternatives you've considered
- Separating pools from reservations using different subnets is not practical as it would require rearchitecting our network which has over 1,000 subnets.
- Having the same lease time for reservations and pools would reduce the reliability/functionality of our network in some areas.
Additional context
- We are currently using this capability with the old ISC dhcpd server.
- Our IPv6 configuration mirrors our IPv4 configuration so we would like the capabilities to be equivalent (where this makes sense) in both.
Funding its development Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs?
- Unfortunately no. :-(
Participating in development Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code?
- I would be interested in participating, but doubt I would have time to get up to speed on how the software currently works in order to develop any code.
- Do you have any pointers to documentation on the structure of the code so I can start to try to understand it even if I can't produce useful code?
- I am definitely willing to be involved in design discussions, test out engineering code and provide feedback on potential solutions or implementations. Contacting you How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
- I can be contacted at John.Gibbins@csiro.au or +61 2 6124 1419.
- Telephone may be problematic due the time difference with Australia (AEDT = GMT+11).