We would like to recognize and thank the Mozilla Open Source Support and the Comcast Innovation Fund for sponsoring ISC’s work on Kea 1.3. The MOSS award funded the development of the Kea REST API over the past year, and Comcast provided partial sponsorship for rest of the 1.3 release.
The #1 most frequently requested feature on the Kea-users mailing list has been shared networks. This is often cited as a blocker for people trying to migrate to Kea from ISC DHCP, and it is the biggest new feature in Kea 1.3. In designing the feature, we asked both Kea and ISC DHCP users to weigh in on the design, and we ended up with a feature that is very similar to the equivalent feature in ISC DHCP.
This feature allows the administrator to group multiple subnets together. Clients in the shared network may be dynamically assigned any address from any of the included subnets. If necessary, you can specify a parameter on the shared network scope and then override its value in the subnet scope, client class or on a host reservation.
This feature is commonly used to pool addresses from multiple subnets when the network has grown and more addresses are needed than are available on a single subnet. Shared networks are also useful for specifying common parameters such as options for multiple subnets. Shared networks are also used in cable networks, where it is useful to have the CPE devices on one subnet, and the customer devices on other subnets for management purposes.
We also finished the REST API sponsored by the 2016 Mozilla MOSS Award, and added two new hook libraries that build on this API.
REST interface over HTTPS
HTTPS provides authentication, confidentiality and integrity for communications over the REST API. We have tested and provided example config files for securing the REST API using Apache and Nginx. We have also provided example config files for securing client communications using stunnel. The maximum size of control commands and responses via REST API have been expanded, removing the 64K limitation present in Kea 1.2. This makes handling of large configurations possible. With these changes the REST API is now ready for production use. Development of this feature was sponsored by a Mozilla MOSS award.
Two new Kea Hook Libraries
- Lease management via REST API – New API commands enable querying, adding, reporting on current leases, and modifying existing leases while Kea is running. This allows the administrator (or any system that interacts with Kea) to check presence and status of leases and make necessary changes as needed. These commands are implemented in a new Lease Commands hook library included in the main Kea distribution. Development of this feature was sponsored by a Mozilla MOSS award.
- Subnet management via REST API – Add, remove and modify subnets in Kea via the API, without resending the entire Kea configuration. This will make managing subnets via the api more feasible for configurations with a large number of subnets or deployments that want to avoid small interruptions when updating the whole configuration. This feature is implemented in the new Subnet Commands hook library, available only in the Kea Subscription package to encourage financial support for the project.
New hook point – A new hook point command_processed allows hook libraries to interact with command handling. Existing and new libraries have been updated to use that hook point.
We added many smaller features, mostly to facilitate migration from ISC DHCP to Kea for more users.
- New options – This release added support for 21 DHCPv4 and 10 DHCPv6 options. Support for the DHCPv4 vendor specific option (code 43) has been improved, in response to questions raised on the Kea-users mailing list. It is now possible to use vendor-specific syntax for that option.
- Options in pools – It is now possible to define options in DHCPv4 pools. This additional level gives users an ability to fine tune options and option values.
- Conditional expressions – a new expression ifelse is now supported. It allows users to make conditional choices in expressions, e.g. in client classification or flexible identifier.
- Other bug fixes and small improvements – As usual, we fixed many bugs and did other small improvements. In total 126 tickets (74 in beta and 52 in final) were closed. We thank all the users who have made the extra effort to report technical issues with Kea at kea.isc.org!
There are only two remaining significant gaps between ISC DHCP and Kea:
- ISC DHCP supports DHCPv4 failover. We plan to support a high-availability deployment model with Kea, using a shared database cluster backend which will work with DHCPv6 as well as DHCPv4. This is not yet implemented, but it at the top of our priority list going forward. Some of our more sophisticated users have managed to build high availability systems already, but we do not provide any documented, tested way to do that currently.
- There are many scripts, graphical interfaces, and integrations with other systems for ISC DHCP that were developed over the past 21 years by users and other organizations. It will take time to build up a similar ‘ecosystem’ for Kea.
We do have a few such contributions for Kea already however:
A simple script from MGM51.com parses the Kea memfile lease files and produces an easily readable list of current active leases.
This generic hook will call an external script at any/all of the hook points supported by Kea. Written by Baptiste Jonglez.
These were provided by Jiri Popelka, a RedHat maintainer.