Announcing Kea 3.2, a new stable version

ISC is excited to announce the release of Kea 3.2.0, a new stable version! It marks the removal of the “Control Agent,” a major architectural shift, among other significant changes.

The software and release notes can be downloaded from our website at https://www.isc.org/download/#Kea.

Key New Features

We strongly encourage you to read the release notes; below is only a small subset of all the changes. There are many more, including new statistics, counters, log messages, and API commands.

1. Shared Free Lease Queue (sFLQ) is added
2. Control Agent (CA) is removed
3. Kea’s interface code has been refactored
4. RADIUS security is added
5. Adaptive lease lifetime (ISC DHCP feature) is added
6. New PostgreSQL Backend TLS options are available

1. Shared Free Lease Queue (sFLQ)

What is the Free Lease Queue?

The Free Lease Queue (FLQ) is an “allocator” or algorithm for selecting a lease. The FLQ was added in Kea 2.4. Here is some background:

Lease selection is a complex process in which the allocation engine favors allocation of reservations and address hints. If neither a reserved address nor an address provided as a hint can be offered, the server must find a free lease from within the address pools belonging to the given subnet (or multiple subnets, if the subnets belong to a shared network). In a new installation all addresses in a new pool are initially free. The server iteratively picks addresses from the pool and offers them to clients. This is the least complicated way to select free leases and it is also the fastest when pool utilization is relatively low.

Iterative allocation performance degrades significantly when the pools are nearly exhausted. The server “walks” through the entire pool and for each candidate address it checks whether a lease exists. In an extreme case, the server will walk over the entire pool before it discovers that there are no more addresses available, and then it will try another pool. The FLQ allocator is designed to minimize the number of iterations to find a free lease within an address pool or to learn that the pool is exhausted.

What problem does the sFLQ address?

Users may deploy multiple Kea servers connected to a single database instance or a cluster of databases sharing the lease information for redundancy, as an alternative to using the High Availability feature of Kea. FLQ can work in this setup, but, like the iterative (default) allocator, it is prone to lease allocation conflicts.

Each server maintains its own free lease queue. Because this lease tracking is maintained locally for each Kea server, it cannot be used for shared lease database configurations. In such configurations, when leases are reclaimed, released, or deleted by one server those changes are not propagated to other servers, and thus their local lease state information can very quickly become inaccurate. This means the allocator will sometimes offer leases that are already allocated by the other servers, causing a conflict when the lease is assigned. Multiple repetitions of the lease allocation process slow performance.

The Shared Free Lease Queue feature is intended to improve the performance of a shared lease backend by reducing the number of backend queries needed to find a free lease for a given pool. Kea 3.2 stores the FLQ data centrally in the shared lease database.

Read the whole Shared Free Lease Queue Allocator section in the updated Kea Administrative Reference Manual for more details about how and when to use this feature.

2. Control Agent (CA) Removed

The CA was deprecated in Kea 3.0, but it was still available for use. In Kea 3.2, the CA is removed entirely.

As of Kea 3.0, the kea-dhcp4, kea-dhcp6, and kea-dhcp-ddns daemons have native support for API sockets over HTTP and TLS (HTTP), without the need to use the Control Agent (CA). Role-based Access Control (RBAC) hook users who are upgrading from a configuration that used the CA will have to update their configuration so that the RBAC hook is loaded by the Kea daemon, rather than by the CA.

3. Kea Network Interface Refactored

Since its inception, Kea has used a very simple and reliable approach to traffic reception. This had some disadvantages, especially in more dynamic environments, or when many interfaces were in use. Over the years, the Kea project has accumulated over 30 reports of issues with our interface. These include possible interface starvation, problems with many (500+) interfaces, and mixing VLAN and physical interfaces re-detecting interfaces which were not ready at Kea startup.

The goal of this refactoring was to enhance support for VLANs and external interfaces, and to provide better support for heavy loads. We also added new statistics and some related API calls and closed a number of open issues.

The interface-add, interface-list and interface-redetect API commands were added, which can be used to add interfaces, list currently detected interfaces, and issue a re-detect procedure which updates the interface configuration, respectively.

Other than the new API commands, this feature should be largely invisible to users. For more details, see the original design proposal for the interface refactoring and the Kea 3.2 Release Notes.

4. RADIUS Security

Kea now supports RADIUS over TLS. RADIUS users are strongly encouraged to consider migration to TLS to mitigate the Blast RADIUS vulnerability. RADIUS over UDP is still supported but by default requires a Message-Authenticator attribute in all received messages.

For details, see the new RADIUS/TLS Configuration section in the Kea ARM.

5. Adaptive Lease-time

Kea now implements an adaptive lease-time mechanism that was available in ISC DHCP. If configured, Kea detects situations where pool utilization is high and there are not many addresses left. It then decreases the lease lifetimes to recycle the leases faster and thus delay or avoid running out of addresses.

6. PostgreSQL Configuration Backend Supports Explicit TLS Configuration Options

There are now explicit settings for ssl-mode, cert-file, key-file, trust-anchor, and cipher-list available in Kea. Previously we used the defaults.

The new configuration syntax is described in the Kea ARM in the Database Connectivity chapter. For more information about these settings, see the PostgreSQL documentation.

Users are strongly encouraged to read the Kea 3.2 release notes carefully before upgrading. Some changes will require configuration changes.

Our support team has compiled a list of things to be aware of when upgrading to Kea 3.2.

New or Recently Updated KB Articles

• Kea Significant Features Matrix
• Things to be aware of when upgrading to Kea 3.2
• Using Official ISC Packages for Kea
• Using Kea Config File Includes
• Kea: Use unique databases

Other Helpful References

• Kea Administrator Reference Manual (ARM) - if you access the Kea ARM on the ReadTheDocs site, you may select any of the many available Kea versions.
• ISC Software Support Policy and Version Numbering
• Notes on Building Kea with Meson