Kea Update #1

Tue Nov 12 17:07:42 UTC 2013

    Kea Update #1

This is a first of hopefully semi-regular updates about Kea, a project
being 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.

Before we go into details, please keep in mind that this is a status for
engineering code that has not been released yet. In many cases the
software is very stable, but in others it may fail miserably. Consider
it an alpha quality, unreleased code.

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

      Options

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 yet 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. Currently it is not possible to switch backends (or
migrate data) during operation. Server has to be shutdown. This
temporary limitation will be removed in a near future.

      Performance

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. More details about perfdhcp:
http://bind10.isc.org/wiki/DhcpBenchmarking

      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. Although
distributed with BIND10 sources, it is a generic, standalone tool that
can be used with any DHCP server implementation.

      Hooks

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.

      Documentation

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 still missing. Most of
them are planned, but we do not have firm dates for their expected
availability. 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)
  * Trimming down dependencies and decrease footprint
  * DHCPv4 Failover (Kea4)
  * DHCPv6 Failover (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!

  * Source: Getting the sources from GIT repo
    <http://bind10.isc.org/wiki/GitGuidelines>
  * Homepage: http://bind10.isc.org/ or http://bind10.isc.org/wiki/Kea
  * Bug tracking system: http://bind10.isc.org <http://bind10.isc.org/>
  * Mailing list:  https://lists.isc.org/mailman/listinfo/bind10-dhcp
  * Jabber room: xmpp://dhcp@conference.jabber.isc.org

/Tomek Mrugalski/
Kea lead developer
ISC