Kea Update #2

[Tomek Mrugalski]

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.

PROJECT CHANGES

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: http://kea.isc.org
Bundy website: http://bundy-dns.de

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

Old BIND10 website is still available at http://bind10.isc.org, 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 CODE STATUS

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.

DNS UPDATES

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.

DATABASE BACKENDS

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.

RECENT CHANGES

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 http://kea.isc.org/milestone/Kea0.8 for
details.

NEW RFCs SUPPORTED

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

PLANNED CHANGES

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:
http://kea.isc.org/milestone/Kea0.9

STRETCH AND OPTIONAL GOALS

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.

TESTING KEA

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 http://kea.isc.org/wiki/IscForge.