[kea-dev] Plans for a KEA extensible DHCP client?

Tomek Mrugalski tomasz at isc.org
Wed Dec 16 13:59:49 UTC 2015

On 16.12.2015 12:52, Ray Hunter (v6ops) wrote:
> Are there any plans to (re-)use the KEA libraries to produce an
> extensible client?
There are, but nothing concrete in the near future. We do organize the
code in a way that implementing client will become possible. In
particular, we don't include anything server-specific in libdhcp++,
which will be the core of the client code. When we said that libdhcp++
is general purpose DHCP lib, we really meant that. It can be used to
implement any DHCP-related functionality, including client.

Our highest level roadmap (if you can call it that) assumes that we're
focusing on the server now. Kea 1.0 is around the corner, but there's
still a lot of features that can be added: better host reservations,
leasequery, better command channel support, more flexible and resilient
reconfiguration, multi-core support, maybe failover one day. These are
all features that many deployments could benefit from.

We're receiving lots of requests for new features in Kea server, so
there's a verifiable demand for it. On the other hand, you're the first
one I remember that asked about a client. Yes, it's on our roadmap, but
there's much less demand for it. I can only speculate why. Maybe because
there are many client implementations out there? Maybe because the
client is usually bundled with the OS of your device? Maybe because
existing open source clients are good enough?

Francis mentioned an "embryonic" client code in unit-tests. This is not
something that could evolve into usable client. It's intrinsically
unsafe (it was designed that way to allow negative testing). This is a
very specialized client-like implementation that is useful for testing
and doing weird things for testing purposes.

Some time ago there was one student working on a minimialistic dhcpv6
client implementation using Kea infrastructure. Dominik published his
code here:
Depending on what you need your client to do, you could possibly look at
this. Please keep in mind couple essential things in mind. This is a
student's project and was never reviewed by anyone. It is based on Kea
codebase that is two years old (Kea's pace of development is quite fast,
so it's a huge, huge difference. We also moved away from bind10 python3
framework in the last 2 years, which further impacted the codebase a
lot). IIRC the code was able to request for an address and had the state
machine implemented, but was seriously lacking in almost everything else.

Disclaimer: this is strictly for informational purposes. I or ISC do not
recommend anyone to actually run the code, I'm merely pointing out that
there was a student project of that nature.

> It would save me an awful lot of work if I could write and test my
> libraries once for server and client simultaneously, rather than
> learning a whole new development tree for the client side and also
> re-writing everything that is client specific.
If you're really inclined to have a client in Kea framework, well...
we do accept patches :) Seriously speaking, it is somewhat imaginable
that the client implementation could be developed outside of ISC and
then contributed. But that's an enormous task that would require a lot
of design work, extensive public discussions (it's easy to skew the
design to adhere to only a limited requirements of a single deployment)
and an awful lot of implementation and testing work. If there are people
to work on this (it's not a small feat, think more like year  long
commitment with many rounds of designs, reviews, tickets, etc.), please
do speak up. This is not a task for the faint of heart.

I'm sorry if that's not exactly what you'd like to hear.


More information about the kea-dev mailing list