6 November 2013

Kea Update #1

This is a first of hopefully semi-regular updates about Kea, a project developed by Internet Systems Consortium that features fully functional DHCPv4 and DHCPv6 servers in the BIND10 framework. We are hoping to publish such an update every time something significant changes in the project, e.g. highlighting features of a new release, completing an engineering milestone and looking for volunteer testers, explaining how to use certain functionalities etc.

Basic capability

Kea consists of two servers: DHCPv4 and DHCPv6. DHCPv4 server in Kea is colloquially called Kea4. The same is true for DHCPv6 and Kea6. Both are fully functional. DHCPv6 support is now a first class citizen. In fact, many features appear in the DHCPv6 code earlier than in DHCPv4. DHCPv4 can assign (Discover/Offer/Request/Ack/Nak), renew (Request/Ack) and release (Release) a lease. DHCPv6 can assign leases (Solicit/Advertisement/Request/Reply), renew them (Renew/Reply) and release them (Release/Reply). Both Kea4 and Kea6 support direct traffic (i.e. requests from clients connected directly to the same link) and relayed traffic (i.e. clients connected to remote link, with their packets resent by relay agents).


Both Kea4 and Kea6 support most defined regular (i.e. those requested by clients and sent by the server) options. It is possible to define custom options. The server will use standard logic - an option will be sent if client requested it.

Vendor Options (CableLabs options)

It is possible to specify vendor specific options. Due to the nature of the vendor options (each vendor may define its own logic), it is possible to define any vendor specific option, but the server will not be able to provide it without special code. So far partial support for DOCSIS3.0 options has been implemented. It is minimalistic, but functional. User can specify the subset of options that is necessary to provision cable modems. Further development in this area is planned.

Prefix Delegation (v6)

Kea6 supports regular (non-temporary) addresses (IA_NA/IAADDR options) and prefix delegation (IA_PD/IAPREFIX options). Multiple IA options in every allowed combination (single IA_NA, multiple IA_NAs, single IA_PD, multiple IA_PD, mix of IA_NA + IA_PD) are supported.

On-line reconfiguration

All BIND10 allows configuration change during operation, without a need to restart. In fact, the ability to update configuration is one of the core design principles of the Kea servers. Almost all aspects (address ranges, prefix ranges, options, timers, libraries etc.) can be modified without client interruption. The only current limitation is the inability to switch database backends. This limitation will likely be removed.

Switchable DB backends

Kea supports switchable database backends. Right now we do have two backends. MySQL is the primary backend that is fully supported. It requires MySQL server to operate. Leases are stored in the regular tables. They can be viewed, tweaked, added or removed using your favourite MySQL tools. Care should be taken, though. Kea servers do limited sanity checks on the database in run-time, but it is very possible to break down the database and it will confuse Kea. The second backend is memfile, which is an experimental in-memory database implementation. Its primary benefit is its speed - around 800% faster than MySQL. Unfortunately, it is highly experimental and unusable in most scenarios. In particular, it is not able to write leases to disk, so all leases are lost once the server is shut down. On the other hand, it does not require external database, so it is easier to deploy, e.g. in test labs.


Kea is designed with scalability and performance in mind. Our early engineering examples show that with MySQL, the servers are able to handle over 1000 leases/sec (over 4000 messages/sec). We have tested Kea with over 1 million leases and it behaved properly. We were able to test our experimental memfile backend up to 8000 leases/sec when our test environment had melted. The server was doing fine and its CPU showed around 60% load.

Performance testing tool

To measure performance and stability, we have developed a performance measurement tool called perfdhcp. It is able to simulate thousands of DHCPv4 and DHCPv6 clients (address only, prefix only, or address+prefix) and send queries with specified rate and measure response rate, drop ratio, response time, response variation and other parameters. It is a generic tool that can be used with any DHCP server implementation.


Kea is extensible. It is possible for a third party to develop a library that will be notified or even influence server behavior. Almost every internal operation of the DHCP engine is exposed. Things like adding extra options, selecting different subnets, rejecting clients, picking different leases etc. are possible. Hooks are currently written in C++, so C++ knowledge is required to develop such an extension. Although we have only one example library, the number is expected to grow significantly. This modular capability is considered a big advantage, so unused parts of the code may be disabled - a welcome feature from security standpoint.


ISC DHCP had less than extensive documentation. We have been developing Kea with the goal of it being a long term project, with proper, easy to read and accessible documentation. We have 3 major documentations:

  1. BIND10 User's Guide - that a user guide that help system administrators to compile, install, set up and maintain their Kea installations.
  2. BIND10 Messages - This is a complete list of all messages all BIND10 components (including both Kea servers) can print. Each message is accompanied with a short paragraph explaining its meaning and sometimes recommendation.
  3. BIND10 Developer's Guide - Kea source code is extensively commented. All functions, classes and methods are documented. There are also overview sections that explain certain aspects, e.g. DHCP protocol engine, DHCPv6 servers operation, lease database etc. This includes Hooks Guide that explains how hooks work and how to develop a library that will use that powerful API.

Missing features

Kea is under development, so many features are missing. The notable missing features are:

  • Support for systems other than Linux (Kea4, Kea6) - we fully support Linux only for now. The code builds on FreeBSD, NetBSD, OpenBSD and Solaris 11, but due to lack of network interface detection code, the server will not work there. We do have patches for BSD and Solaris, but they will not offer support for directly connected DHCPv4 clients. We do not support (or plan to) Windows systems.
  • DDNS (Kea4, Kea6) - Dynamic DNS update is being developed, but it is not ready.
  • Host reservation (Kea4, Kea6) - there is no way to reserve an address or prefix for a given client
  • Client classification (Kea4, Kea6) - sometimes it is useful to classify clients to various classes, e.g. VoIP devices and PCs. Often one class gets specific options or addresses/prefixes from specific pool. Such classification is not supported.
  • DHCPINFORM (Kea4) - INFORM message is not supported, so clients that got address through some other means and want options only from DHCPv4 will not be served
  • Information Request message (Kea6) - the same as DHCPINFORM, but for DHCPv6
  • Rebind message (Kea6) - Typically v6 client goes through Renew cycles once it gets its leases. When the original server does not respond, the client will eventually start sending Rebind messages which are addressed to any server. Kea6 does not support that.
  • Decline message (Kea6) - v6 clients may detect that their address is used by some other device in network. They will send DECLINE message in such a case. Kea6 does not handle that.
  • Authentication (Kea4, Kea6) - we do not support any form of authentication yet
  • Temporary addresses (Kea6) - DHCPv6 protocol defines temporary addresses (send in IA_TA option). Kea6 does not support this.
  • Reconfigure mechanism (Kea6) - DHCPv6 allows servers to generate a key and send it to the clients. Then later, server may inform clients that a reconfiguration should be performed immediately, rather than waiting till T1 timer expires. We do not support this optional feature.
  • BOOTP support (Kea4, not planned) - BOOTP is a predecessor of DHCPv4. In the current (2013) world, devices that support BOOTP only and can't do DHCPv4 are obsolete. If you need to support such devices, we recommend using ISC DHCP4.x.
  • Address availability confirmation over ICMP (Kea4) - DHCPv4 server may confirm that an address is indeed not used by trying to send ping (ICMP echo) packet and awaiting response. This is not supported.
  • Leasequery, bulk leasequery (Kea6)

Getting the code

Internet Systems Consortium is committed to development of commercial quality open source software. Kea is a notable example of such strategy. The source code is freely available, the code repository that developers use is public, ticket system that tracks bugs and new features development is public, and so is the mailing list. Parts of the code have been contributed by people who are not employed or have any relationship with ISC, so this is truly an open source collaboration project. Feel free to join!

Tomek Mrugalski
Kea lead developer

Last modified 4 years ago Last modified on Nov 6, 2013, 8:19:18 PM