Kea Update #2

This is the second update for Kea project. A lot has happened since Kea Update #1 was published in Nov. 2013. This memo tries to summarize project changes, current code development status and our intermediate plans.


Kea was part of the BIND10 project, which contained both DNS and DHCP components. ISC decided to stop developing BIND10 project in April 2014. The code development will continue in 2 separate projects: Kea (which is now a stand-alone project and is focused on DHCP only) and Bundy (which is focused on DNS components and the decision whether it will include DHCP components is yet to be made). It should be noted that ISC is supporting Kea project, while Bundy is being run outside of ISC guidance. Both projects are open-source, with publicly available source code, source code repositories, bug tracking, mailing lists and external contributors or participants are welcome in both projects.

See the following links for more details about respective projects:

Kea website:

Bundy website:

Note that git repository location has changed. Please visit respective projects websites for details.

Old BIND10 website is still available at, but please do not use it, as it is not maintained anymore and will disappear some time in the future.

The BIND10 1.2.0 is the last release of BIND10 project. It contains Kea 0.8. The upcoming Kea 0.9 will be released on its own. ISC continues to develop BIND9 (named).


Kea features functional DHCPv4 and DHCPv6 servers, that support both direct and relayed traffic. Prefix Delegation for DHCPv6 is supported. Most standard options are supported. Those that are not out-of-box, can be easily defined as custom options. Vendor options (in particular many necessary CableLabs? options) are also supported. Kea was successfully used to provide cable modems both in v4 and v6 mode. Kea project also features perfdhcp - a performance measurement tool that can be used to assess performance of any DHCP server. Currently the only officially supported OS is Linux. The code compiles and most unit-tests pass on many other OSes: FreeBSD, NetBSD, OpenBSD, Mac OS X and Solaris 11, but we do not run any system, functional or conformance tests on those OSes.


Kea now supports DNS updates. There is a separate DHCP-DDNS module (nicknamed D2) that can be used by either DHCPv4 or DHCPv6, or both. It is capable of inserting, updating and removing A, AAAA, PTR and DHCID records, which means that it can manage both forward and reverse records for IPv4 and IPv6.


Kea features switchable database backends. We have recently implemented two additional backends and now have a selection of three:

  • memfile: it has been around for a long time, but it lacked disk operation. That deficiency has been eliminated recently. This is the default backend as it does not have any external dependencies. The leases are kept in memory (which make it very fast), but are also written to disk using CSV file. The disk operation is configurable. It can be disabled, so the database becomes in-memory only. That may be useful if you need extra speed, but don't care about leases being lost after server is shut down. This backend is always available.
  • MySQL: This is the backend that we supported for a while. It uses MySQL database to store leases. Its stability has been confirmed with many tests. It is disabled by default. To enable it, you need to pass --with-dhcp-mysql parameter to ./configure script.
  • PostgreSQL: This is the second recently added backend. It is similar to MySQL as it follows the same approach: leases are stored in PostgreSQL database. We managed to run only limited tests on this backend. It is disabled by default, too. To enable it, you need to pass --with-dhcp-pgsql parameter to ./configure script.


DDNS module has been added.

Memfile and PostgreSQL database backends and now functional, but more thorough testing is still pending.

Rebind messages in DHCPv6 are now supported.

We have added support for minimalistic client classification. For now, we interpret content of the user-class (DHCPv4) or vendor-class (DHCPv6) options as class and can allow or reject clients in a given subnet. Full featured client classication is planned for Kea 1.0.

Numerous bugs were fixed. See for details.


  • RFC6842 - DHCPv4 server now sends back client-id. For backward compatibility (we discovered that some cable modems don't like their client-id being sent back) this support can be disabled.
  • RFC4701 - DHCID Resource Record for DNS
  • RFC4702 - FQDN option for DHCPv4
  • RFC4703 - Resolution of conflicts between DHCP clients
  • RFC4704 - FQDN option for DHCPv6

Some listed RFCs are partially supported.


We plan to release Kea 0.9 in summer 2014. The major change will be to remove dependency on BIND10 framework. Right now Kea requires big Python3 based framework. It was useful to manage multiple DNS instances, but is considered too big for just DHCP components. We received several complaints about required dependency on Python3, so we decided to remove it. We are planning to keep configuration in JSON file that will be read from disk. Please bear that planned change in mind and do not develop anything around Kea that uses current bindctl interface, as it will go away.

That decision will bring in several changes. Kea will be much smaller, as we'll get rid of lots of Python3 code. It will look more like traditional unix daemon, with config file, rather than interactive CLI configuration. Kea will retain on-line configuration, i.e. configuration changes will not require server restarts. Remote reconfiguration capability using RESTful API will be gone, but as we consider it useful, the plan is to reintroduce it in the future.

DDNS module development continues. The biggest planned addition is support for TSIG, transaction signatures that protect the DNS Updates.

For more details about planned changes, see:


We have several stretch goals that we'd like to pursue, but are lacking manpower for it. Depending on various factors, the following may or may be not included in the next release. We welcome external contributions. In particular, we'd like to:

  • provide alternative to Botan. Currently Kea requires Botan as cryptographic services provider. Using relatively uncommon library as Botan helps in many cases (e.g. recent Heartbleed problem did not affect Kea), but is a problem in others (package maintainers need to add another crypto library, which sometimes require going through difficult and costly audit procedures). Therefore we plan to add support for OpenSSL. We would then require just one crypto library (either Botan or OpenSSL) and use whatever is available in the system.
  • FreeBSD support. We'd like to start supporting FreeBSD as first BSD system. The code compiles and passes all unit-tests, so it should work in most cases, but we lack manpower to verify that. Also, we don't have the code to send DHCPv4 responses to clients that don't have an IPv4 address yet, so support for directly connected DHCPv4 clients is likely to be lacking.
  • DHCPv4-over-DHCPv6: This is a new proposal being designed in IETF. It allows configuration of IPv4 nodes in IPv6-only networks. We have established cooperation with Tsinghua University team, who developed prototype using Kea. We are working together to enhance that prototype and merge it into Kea main tree.
  • Support for stateless DHCPv6 (Information-Request) and Confirm messages in DHCPv6. We'll attempt to implement support for those if time permits.


ISC develops a suite of conformance tests called ISC Forge. This is an open-source validation framework that is designed as universal DHCPv4 and DHCPv6 protocol conformance validator. Currently it fully supports Kea (both DHCPv4 and DHCPv6 components) and have partial support for other implementations (ISC-DHCP and Dibbler). Currently we have 235 conformance tests for DHCPv6 and 148 tests for DHCPv4. This project has started as a cooperation with Gdansk University of Technology. For more information about ISC Forge, see

Last modified 4 years ago Last modified on May 7, 2014, 3:06:29 PM