Kea Update #3

This is the third status update of the Kea project (the last was published in May 2014). It summarises the current state of the project, the recent release, and outlines our development plans for the next couple of months.


Kea 0.9 has been released on 2014-08-29 and is available here: This is the first stand-alone release (i.e. not part of BIND 10) and features fully-functional DHCPv4 and DHCPv6 servers.

Kea 0.8 was released as part of BIND 10 (now a concluded project). As part of the change, a lot of legacy code that used to be responsible for starting, configuring and managing the servers was removed. Kea 0.9 uses text files containing configuration information specified using JSON notation. By removing the BIND 10 framework, we removed more than 100.000 lines of code. Kea is now smaller, cleaner, compiles faster, takes less space and is much easier to deploy. Being a pure C++ code, it also no longer requires many awkward dependencies such as Python3. Removal of the framework came at a cost though. We temporarily lost the ability to send commands to the servers, although this is something we plan to reintroduce in upcoming releases. Nevertheless, it is still possible to update the Kea configuration without restarting the server by using POSIX signals.

Kea is now able to run on operating systems in addition to Linux. We added support for BSD kernels and have tested in on FreeBSD, NetBSD and OpenBSD. Although not tested beyond unit-tests, it should also work on Mac OS X. Reports about its successful operation (or lack of thereof) are more than welcome. Kea may compile on Solaris 11 and partially work, but will likely experience problems with sending DHCPv4 traffic to clients that do not have IPv4 address assigned yet. Solaris is not yet a supported platform, but we are looking for reports about that system, too. As usual, patches are more than welcome.

Previous releases required Botan, a cryptographic library that is much less popular than its alternatives, like OpenSSL. That was both a blessing (remember recent OpenSSL worries? Kea was not affected) and a curse (several package maintainers frowned upon the need to package yet another cryptographic library that would have to undergo a certification process). Therefore we decided to add support for OpenSSL. Right now only one cryptographic library is required (Botan or OpenSSL), the choice being made at compilation time. Please pick whichever is more appealing for you.

DNS support in Kea is in the form of a separate Dynamic DNS update daemon (abbreviated DHCP-DDNS or D2 for short). It handles the addition and removal of client names from both the forward and reverse DNS zones. It now supports cryptographic signatures (TSIG), handling a variety of algorithms: HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512.

As with previous release, we now support three lease database backends. Memfile, which stores leases in a flat CSV file and in-memory custom developed C++ database, is the default backend. We also optionally support MySQL and PostgreSQL.

Last, but not least, we have significantly improved the Kea documentation. The Kea Reference Administrator Manual is now over 70 pages long and is available in PDF, HTML and text formats. It covers many aspects of Kea: compilation, installation, administration and configuration. A handful of configuration examples is included in the 0.9 release: the number is small for now, but we are expecting it to grow with each release.

If you want to know more details of the 0.9 work, please read release notes that contains pointers to specific tickets or go to our trac site directly:


ISC plans to release Kea 1.0 in 2015 and will start offering commercial support for it at that point. However, before we reach that significant milestone, there are a lot of features that still await implementation. Therefore we have decided to make at least two intermediate releases before we release V1.0.

0.9.1 is expected to be released around end of 2014. It will feature MAC addresses in DHCPv6, host reservation and PXE boot. It will be possible to reserve a specific address and/or prefix for a given host, force an address to be fixed and assign custom options to a given host (e.g. special options for your printer or extra configuration parameters for each of your cable modem customers). Implementing MAC addresses support in DHCPv6 is a bit tricky (there is no kernel API that allows reading that information using UDP sockets), but we will do our best to mitigate the problem. There are also couple things that we need to fix under the hood. Two examples are our configuration parsers and configuration management. This will likely to be invisible to end users, but will make developers' lives much easier.

We are also continuing with the concept of stretch goals. These are features that we'd love to include, but due to various reasons we are not sure if we make it. In some cases these are being written by external contributors, for whom we can't guarantee deliverables. In any case, we are hoping to deliver three extra features: configuration scaling, DHCPv4-over-DHCPv6 and remote management.

Configuration scaling is an interesting problem. Kea now offers reasonably high performance, leases per second wise. We managed to get over 1000 leases/sec for MySQL and 8000 leases/sec for memfile in memory-only mode on one of our high-performance servers. (Your mileage may vary.) However, that was measured for unrealistic scenarios (millions of clients connected to a single subnet). With increased configuration complexity, the performance goes down. This task is about improving configuration scalability, so it will be possible to support thousands of subnets without performance degradation. We haven't made any decisions yet, but it seems likely that we will allow storing subnet configuration in a database. This most likely will be an optional feature, so if you happen to have only five subnets, it will be possible to define them in the configuration file and not need to set up a database.

DHCPv4-over-DHCPv6 is an interesting concept that was recently published by IETF as a proposed standard: RFC 7341. We do have external contributors from Tsinghua University that are working on an implementation. We barely missed our opportunity window to include it in 0.9, but it is very probable that it'll make it for 0.9.1.

We are also in contact with one company that is interested in remote management API and we have had an initial discussion about potential contributions. We can't disclose any details yet, but let's just keep our fingers crossed.

0.9.1 is expected to be released some time in late 2014. In general, we will release the code when it is ready, but we want to be reasonable about it. We're trying to make a release every 3 to 6 months. This is, in our opinion, a reasonable trade off between enduring release pains (release engineering, upgrading) and wait time for new features. You can track our progress towards 0.9.1 here:

Beyond that, release 0.9.2 is tentatively planned for spring 2015. The goals assigned so far are: basic statistics, improved logging and diagnostics, proper lease expiration (with log notification, ddns clean-up, hooks notification), add support for INF-REQUEST and DECLINE and any other technical debt/outstanding items we may carry from earlier release. We will start collecting tickets for it here:, but don't expect to see much activity there in the next couple months. We're focusing on 0.9.1 for now.

Eventually we will get into the 1.0.0 phase. That will cover several new features, the most visible one being the addition of a tool that will help with migration from ISC-DHCP. This tool will not be able to cover 100% cases, as the two servers are simply too different and there will not be feature parity. But we will attempt to develop a tool that will cover more popular cases. It seems likely that subnet configuration and leases information will be migrated. This tool is also expected to be long lived and evolve over time.

There will be many smaller features and additions: a sample hook library, performance optimizations, remote management interface (if we don't manage to implement it earlier) and many other.

One notable feature that will not make it into 1.0 is client classification. We decided that, although highly desirable, that feature is simply too big for 1.0. Had we included client classification into the release, it would most likely slipped into 2016. That is something we are unwilling to do. 1.0 will also not support DHCPv4 failover, DHCPv6 failover, leasequery, DHCP authentication or the DHCP reconfigure message. You can find ticket currently assigned to that milestone here:

All mentioned plans and dates are tentative and subject to change.


With the 0.9 release, we significantly trimmed down our external dependencies. This means that it is a good time to think about Kea packaging. We have started working with several Linux distribution packagers to deliver Kea in a user-friendly, system specific way. So far we are in contact with RedHat (thanks for the patches!) and Debian. We also have plans for !FreeBSD. Unfortunately, we can't dedicate too much time for system specific features. Even worse, sometimes there may be conflicting requirements (e.g. RedHat's systemd scripts are different to Debian's), so keeping the system specific files in Kea repository may not be the best course of action. If you are a system expert and/or a system maintainer and would be willing to help with packaging Kea, please get in touch with us. You can find the usual communication channels (mailing list, trac, jabber chatroom) on the Kea home page.


We are delighted to announce that the number of external contributions to Kea is growing. In the past, we received a patch, us (or the contributor) created a ticket for it and then there was an interval waiting for one of ISC engineers to become free in order to review it. Sometimes it was a bit tricky to find specific code version the patch was made for but we had other issues with the process. To make the story short, the process was working, but it was cumbersome and required a lot of work.

We have therefore decided to try an experiment and use GitHub for external contributions. Although we still maintain our own ISC repository, we also keep a copy on GitHub here: The idea is that prospective contributor will fork the GitHub copy of the repository (this is a one-click operation on GitHub), develop his/her fixes and then send us a "pull" request. We are not sure if this way will work any better than our previous process, but we're willing to try. Please join us in this experiment and send a patch this way. We will soon publish the full details of the contribution process on the Kea web site and on kea-dev mailing list.


All Kea related materials are on the project website:, including links to the code repository, bug tracking system, wiki, mailing lists and jabber chatroom. The Kea project is maintained in a much more open manner than any other ISC product. You are more than welcome to participate - test it, send feedback, test results, bug reports, feature requests, patches and suggestions, comment on existing bugs, tickets and feature requests etc. If you are interested in the details, we frequently discuss designs for our upcoming features on kea-dev mailing list. We'd love to get your feedback. If you are uncomfortable with making your comments public, that fine, too. Just unicast your comments directly to us. You can find ISC's engineers mails on kea-dev mailing list archives here.

Tomek Mrugalski

Kea lead developer

Last modified 5 years ago Last modified on Sep 8, 2014, 12:42:39 PM