Dynamic IP address assignment by the Dynamic Host Configuration Protocol (DHCP) usually performs its service reliably. However, some implementations lack modern interfaces to connect them to existing management systems and databases. Some outdated solutions also lack functions for IPv6. The Kea project, launched in 2014, modernizes the DHCP server.

Kea was designed as a successor to the Internet Systems Consortium's open source DHCP server (ISC DHCP), which has been widely used on enterprise networks since 1999. Version 1.8.1 [1] of the DHCP server was recently released and is available for the Linux, Unix, and macOS operating systems. The service has a modular structure with, for example, separate daemons for DHCPv4 and DHCPv6, as well as for dynamic DNS registration.

The Kea server configuration relies on a JSON-based data structure. Configuration changes do not require a service restart, with the exception of an interface change, and was one of the key criteria for one of the early adopters of the project: Facebook. According to its own statements, the social media company used the predecessor, ISC DHCP, for provisioning the operating systems of bare metal servers and out-of-band management systems.

However, automated mechanisms were complex to implement with static configuration files and required frequent restarts of services to apply the changes. Additionally, extended availability requirements, as well as the dynamic connection to the internal inventory system as a "single point of truth," were additional arguments for establishing Kea as the replacement.

Highly Available and Expandable

Some optional functions can be reloaded with dynamically loaded "hook modules." Hooks written in C++ extend the range of functions, which makes it possible to keep the core of the service small, yet not limit the possible range of functions.

Moreover, the ISC provides a web-based monitoring GUI named Stork [2] that requires agents on the monitored Kea servers. Connecting Kea to SQL databases for DHCP lease data, DHCP reservations, and some configuration data also appears interesting and supports, for example, unified access from clustered DHCP servers to a lease dataset. A RESTful API offers the ability to connect to your own management systems. High availability (HA) is also feasible. In contrast to the ancient ISC DHCP, Kea also offers HA for IPv4 and IPv6. Redundancy for IPv6 is implemented according to RFC8156. In addition to two active servers, you can set up classic 1:1 redundancy and run multiple backup servers.

In the classic ISC DHCP, dividing address pools was a very flexible process. Kea can only do this in a 50/50 distribution.

Added to all these functions, Kea offers integration with RADIUS servers. For example, if a MAC address is known, the RADIUS server can suggest a specific IPv4 or IPv6 address and thus offer a quasi-RADIUS-based DHCP reservation. Alternatively, the RADIUS server can also name a specific address pool, which can be useful if dedicated sets of rules depend on certain IP addresses at other points, such as firewalls.

Installation with Dependencies

Before you install, you need to answer two crucial questions that need to be considered later in the build process: (1) Is redundancy intended? (2) Do you want to use a comma-separated values (CSV) file for the lease data or a database?

After downloading Kea, you need to compile it yourself. However, pre-built packages can be downloaded from the Cloudsmith website [3]. Some Linux distributions offer such packages through their package managers, but the versions usually are not up to date. Starting in Kea 1.6.0, you can generate a build with a Python 3 script called Hammer.py, which is included in the Git repository.

In the example here, you will first install some dependencies, including a MySQL server that uses memfile (the simplest and fastest database back end, which uses an in-memory database and stores DHCP lease data on disk in a CSV file). MySQL, PostgreSQL, and Cassandra are supported as alternative back ends. Afterward, you will be cloning the current GitLab repository and executing the build process (Listing 1). The binaries are then stored under /usr/local/sbin.

sudo apt-get -y install liblog4cplus-dev libboost-all-dev make build-essential autoconf libtool libssl-dev mysql-server libmysqlclient-dev
cd /opt/
sudo git clone https://gitlab.isc.org/isc-projects/kea.git
cd kea
sudo autoreconf -install
sudo ./configure --with-mysql
sudo make
sudo make install

Preparing Logging and the Database

To define globally which modules need to be loaded by Kea and which paths will be used to access the configuration files, edit the keactrl.conf configuration file, where you can disable the dynamic DNS service (e.g., if you do not need dynamic DNS updating on the network).

You can start and stop the service and query the current status with:

keactrl start
keactrl stop
keactrl status

In the respective module configuration, you can define a logging target. For DHCPv4 this would be kea-dhcp4.conf if you do not use a different configuration file as an argument.

Now you need to initialize the MySQL database before using it the first time. The kea-admin binary provides the db-init argument for this purpose. I will not go into detail on the steps for granting the MySQL user permissions here. Listing 2 initializes the MySQL database and shows the created table structure.

pfister@dhcp:~# kea-admin db-init mysql -u dhcpsvc -p t0ps3cr3t -n dhcp
mysql> show tables;
+--------------------------------------------+
| Tables_in_dhcp                             |
+--------------------------------------------+
| dhcp4_audit                                |
| dhcp4_audit_revision                       |
| dhcp4_global_parameter                     |
| dhcp4_global_parameter_server              |
| dhcp4_option_def                           |
| dhcp4_option_def_server                    |
| dhcp4_options                              |
| dhcp4_options_server                       |
| dhcp4_pool                                 |
| dhcp4_server                               |
| dhcp4_shared_network                       |
| dhcp4_shared_network_server                |
| dhcp4_subnet                               |
| dhcp4_subnet_server                        |
| dhcp6_audit                                |
| dhcp6_audit_revision                       |
| dhcp6_global_parameter                     |
| dhcp6_global_parameter_server              |
| dhcp6_option_def                           |
| dhcp6_option_def_server                    |
| dhcp6_options                              |
| dhcp6_options_server                       |
| dhcp6_pd_pool                              |
| dhcp6_pool                                 |
| dhcp6_server                               |
| dhcp6_shared_network                       |
| dhcp6_shared_network_server                |
| dhcp6_subnet                               |
| dhcp6_subnet_server                        |
| dhcp_option_scope                          |
| host_identifier_type                       |
| hosts                                      |
| ipv6_reservations                          |
| lease4                                     |
| lease4_stat                                |
| lease6                                     |
| lease6_stat                                |
| lease6_types                               |
| lease_hwaddr_source                        |
|lease_state                                 |
| logs                                       |
| modification                               |
| parameter_data_type                        |
| schema_version                             |
+--------------------------------------------+