Kea Update #3

Tomek Mrugalski tomasz at
Mon Sep 8 12:49:11 UTC 2014

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 other 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

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 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 tickets 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.

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 engineers' mails on kea-dev list archives

Tomek Mrugalski
Kea lead developer

More information about the kea-dev mailing list