wiki:KeaRoadmap

Kea DHCP Server - Pre-deployment

Kea will be a new, standards-compliant open-source DHCP server for Linux and UNIX. Kea is designed for dynamic reconfiguration and easy extensibility. Kea is focused on providing a complete implementation for modern networks, with support for both DHCPv4 and DHCPv6 but limited legacy features.

Kea is not designed for an embedded or severely memory-constrained environment. The current project is a DHCP server only, although we may subsequently develop a DHCP client and or DHCP relay.

At this stage in the project, we welcome external collaborators. We are particularly interested in having an external developer attempt an application using the published Hooks API.


Milestones / Roadmap

6. Release 0.9.1 and subsequent releases

... are being planned and tracked here: http://kea.isc.org/roadmap. Note that only currently active milestones are displayed by default. To see completed milestones, please use the "show completed milestones" checkbox on the right mini-panel.


5. Release 0.9 - Beta, August 13, 2014 2014

This is planned to be the last pre-deployment release. With this release we are creating a standalone DHCP server (prior releases required the BIND10 application framework).

GOALS

  • Remove the BIND 10 framework. The BIND 10 framework included many useful features (the current CLI, the REST API and the statistics engine) but since it was a general purpose applications framework we decided it was too much overhead and we don't want the long-term maintenance burden. done
  • Remove any dependency on Python. Much of the BIND 10 framework was written in Python3, which was a barrier for some of the Operating system packagers who did not want to require Python in the base system. done
  • Add the ability to run from a JSON configuration file. In the future, this will enable a migration path from ISC DHCP, which also uses a configuration file. done

Stretch Goals for 0.9

  • OpenSSL as an alternative to Botan for cryptographic services done
  • FreeBSD support (we lack support for sending DHCPv4 responses to clients that don't yet have an IPv4 address, otherwise this is already working) done
  • DHCPv4 over DHCPv6 Tsinghua University prototype
  • Stateless DHCPv6 Information-Request and Confirm messages

4. Release 0.8 (aka BIND 10 release 1.2) - April 2014, Complete

This is the last release of Kea in the BIND 10 framework.

  • Addition of persistent storage for the Memfile backend
  • Addition of PostgreSQL backend
  • Dynamic DNS (DDNS)
  • Prefix delegation
  • DHCP Rebind message support
  • Minimal client classification based on user-class (DHCPv4) or vendor-class (DHCPv6)

3. Through November, 2013 - Complete

  • Hooks API
  • IPv6 Prefix delegation
  • Performance improvements
  • Demonstrate HooksAPI and IPv6 Prefix delegation at IETF 88, Vancouver, BC

2. Pre-production Server - Complete

This work was carried out in 2012 and is now complete. It added functionality to the server such that it could be used in a laboratory environment or in other non-critical networks.

  • Abstract pool and lease storage.
  • SQL-based pool and lease storage.
  • Option definition framework.
  • DHCPv4 server. For this phase, we will probably only focus on the non-embedded version.
  • DHCPv6 server. Again, the non-embedded version is the focus.

1. Skeleton Server - Complete

This work was carried out in 2011 and is now complete.

  • A DHCP packet library, in the same spirit as the DNS message library in BIND 10. This handles the low-level work of assembling and parsing packets.
  • DHCPv4 state machine.
  • DHCPv6 state machine.
  • Hook definitions, describing where in the process flow custom actions can be defined and the parameters of these. (Only relay for this milestone.)
  • Hook definitions, but for the server logic.
  • Hook definitions for the pool interaction and lease storage.
  • DHCP benchmark tools.
  • Option definition framework design.
  • Low-level network layer. This is primarily designed to handle the unique environment for DHCPv4 - sending to an address without using ARP, sending without having an address on an interface. It also includes DHCPv6 packet handling and detects interface changes.

X. Other Features Needed, not yet in the plan

  • Client classification (more elaborate)
  • DDNS GSS-API
  • DHCPv4 failover
  • Multi-threading (placeholder for performance improvements)
  • Reconfigure support
  • Full DOCSIS3.0 support
  • Lease migration.
  • General test utility to send arbitrary DHCP packets and read the response (i.e. a DHCP equivalent of "dig").
  • Statistics module (need requirements)
  • Something to test your class logic (check configuration)
  • SNMP agent

Related Possible Future Projects

  • DHCPv4 relay. We may need both embedded and non-embedded versions of these.
  • DHCPv6 relay. Again, both the embedded and non-embedded versions may be necessary.
  • Client. It seems likely we will build a non-resident client, with minimal functionality by default.
  • Lightweight, embedded server
Last modified 3 years ago Last modified on Mar 31, 2015, 1:39:03 PM