# Kea 1.7.3, December 18th 2019, Release Notes Welcome to Kea 1.7.3, a monthly development release of Kea. This release is the next step towards having fully multi-threaded DHCP servers, which will eventually become available as 1.8.0. This is a development release. Use with caution! Development releases are not recommended for production use. Changes introduced in this version: 1. **Alpine packages**. Native packages for Kea are available for a number of popular Linux distributions. With this release, we are adding Alpine (APK) packages to the list. As usual, we're looking for feedback on them. The packages are available at our [kea-1.7 cloudsmith.io repository](https://cloudsmith.io/~isc/repos/kea-1-7/packages/). (#772). 2. **Status-get command**. It's been brought to our attention that HA status monitoring is an area that could use some enhancements. In this release we managed to do two things to improve the situation. First, the existing ``ha-heartbeat`` command, originally used by each HA partner to ensure the other is still available, can be used to get some insight into the server state; the Kea ARM now has a new section that explains how to use the command. Second, we implemented a new ``status-get`` command that reports a number of run-time Kea parameters, such as process ID, startup time, reconfiguration time, and more. In particular, if the HA hook is loaded, it provides extended information about HA status. (#998, #1041). 3. **Multi-threading**. Our work on enabling multi-threading in Kea continues. Although this month we managed to merge only one ticket (PostgreSQL lease connection pool), several others moved forward and are in various stages of review. We expect much more progress in January. (#1044). 4. **Experimental BOOTP hook**. Up until now, Kea did not support BOOTP. Our initial assumption was that it would be somewhat unlikely to see both a modern, bleeding-edge solution from 2019 and old, legacy devices that can't even do DHCPv4 in the same network. However, with Kea becoming more and more popular, some users have requested BOOTP - so Kea 1.7.3 introduces a new, open source hook that provides support for BOOTP. The Kea team has a limited experience with BOOTP and we don't have any devices that are able to use BOOTP only. Note the hooks library only passed unit-tests and we just started system tests. Very preliminary testing reported issues. See [known issues page](https://gitlab.isc.org/isc-projects/kea/wikis/known-issues-list) or #1064 for details. (#881, #897, #898) 5. **Doc improvements for perfdhcp**. As part of our general focus on performance, we improved perfdhcp documentation. The scenario where perfdhcp sends a certain number of packets per second is the default (*basic*). However, some time ago we implemented another scenario called *avalanche*. When testing performance of any DHCP server, there's always a certain top available performance. Once it is exceeded, devices that didn't get responses back within the given time period assume that the packet was lost and start retransmitting. This can sometimes cause a run-away effect called an avalanche. Perfdhcp was able to simulate such a scenario, but it was not documented and we believe no one outside of ISC used it. That documentation deficiency has been addressed now. (#876) 6. **Doc improvements for Forensic logging**. The ARM section related to Forensic logging now describes in detail how to configure Forensic logging to optionally store logged information in a database. (#943) 7. **CIADDR set in DHCPINFORM**. The Kea DHCPv4 server now sends the client's address (ciaddr) back in its ACK messages when responding to DHCPINFORM. This improves compatibility with some devices. (#992) 8. **DB schema version check**. The database schema version checking has been improved. (#1008) 9. **Build improvements**. Several smaller build improvements have been made. Release tarballs now include documentation and man pages, the recently published Google test 1.10 is now supported, and a compilation failure when using gtest and the --with-error flag has been eliminated. (#982, #954, #1004). ## Changes to Release Model The Kea project has been in development for several years now, and it has a significant production deployment base with users who are looking for stability, rather than a constant stream of new "bleeding-edge" features. At the same time, we want to continue developing the software, including some new powerful, but difficult-to-implement, features. As a result, we decided to change the release cycle. Starting from 1.6.0, there are two series of releases: stable and development. Stable releases are what you would expect: stable, released infrequently, without new features or significant changes, very well-tested. Those can be identified by the middle version number being even. The current stable release is 1.6.1. If we discover important bugs that require fixing, we may release 1.6.2, but that will be determined on a case-by-case basis. The next major stable version will be 1.8.0, followed by 2.0.0 in the future. Our team continues development of new features. In particular, we're tackling the difficult problem of being able to use all available CPU cores simultaneously. The multi-threading implementation is a complex task and it is unknown how long it will take before the solution is stable and ready for a production environment. At the same time, we continue to receive a stream of requests for small features and bug fixes. We don't want to force users to wait half a year or more for the fixes and features that are already done. Therefore, we have decided to start issuing development releases on a monthly basis. Those are slightly less well-tested and may have features that are not complete. It is possible that one of the next releases will provide a configuration knob to specify the number of threads in multi-threading, but the actual code won't be extended yet to spawn those threads. The development releases can be easily identified by the middle version number being odd: for example, 1.7.3 is a development release. In January 2020 we will release 1.7.4, the next development version. Once 1.8.0 is out, we will continue our development work with 1.9.0, then 1.9.1, and so on. Our goal is to make the development release available on the last Wednesday of each month. There may be exceptions (such as during holidays), but that's the general plan. We encourage users to test the development releases and report back their findings. For more details on the plan, see ISC's Software Support Policy at https://kb.isc.org/v1/docs/aa-00896. ## Kea overview Kea is a DHCP implementation developed by Internet Systems Consortium, Inc. that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP and DNS update servers, an example shell client to connect to the CA, a daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance-measurement tool. Both DHCP servers fully support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification, and host reservations. The DHCPv6 server also supports prefix delegation. Lease information is stored in a CSV file by default; it can optionally be stored in a MySQL, PostgreSQL, or Cassandra database instead. Host reservations can be stored in a configuration file, or in a MySQL, PostgreSQL, or Cassandra database. They can also be retrieved from a RADIUS server, although this functionality is somewhat limited. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which are stored in a Sysrepo datastore and can be configured via the NETCONF protocol. This text references issue numbers. For more details, visit the Kea GitLab page at https://gitlab.isc.org/isc-projects/kea/issues. ## License This version of Kea is released under the Mozilla Public License, version 2.0. https://www.mozilla.org/en-US/MPL/2.0 The premium and subscriber-only hook libraries are provided in source code form, under the terms of an End User License Agreement (you will get the source code that you can modify freely, but you are not permitted to redistribute it). ## Download Pre-built ISC packages for current versions of the most popular Linux operating systems are available at: https://cloudsmith.io/~isc/repos/ The Kea source and PGP signature for this release may be downloaded from: https://www.isc.org/download The signature was generated with the ISC code signing key which is available at: https://www.isc.org/pgpkeys ISC provides detailed documentation, including installation instructions and usage tutorials, in the Kea Administrator Reference Manual. Documentation is included with the installation or via https://kb.isc.org/docs/kea-administrator-reference-manual in HTML, plain text, or PDF formats. ISC maintains a public open source code tree, wiki, issue tracking system, milestone planning, and a roadmap at https://gitlab.isc.org//isc-projects/kea. Limitations and known issues with this release can be found at https://gitlab.isc.org/isc-projects/kea/wikis/known-issues-list. We ask users of this software to please let us know how it worked for you and what operating system you tested on. Feel free to share your feedback on the Kea Users mailing list (https://lists.isc.org/mailman/listinfo/kea-users). Also we would like to hear whether the documentation is adequate and accurate. Please open tickets in the Kea GitLab project for bugs, documentation omissions and errors, and enhancement requests. We want to hear from you even if everything worked. ## Support Professional support for Kea is available from ISC. We encourage all professional users to consider this option; Kea development and maintenance are funded with support subscriptions. For more information on ISC's Kea and DHCP software support see https://www.isc.org/support/. Free best-effort support is provided by our user community via a mailing list. Information on all public email lists is available at https://www.isc.org/community/mailing-list. If you have any comments or questions about working with Kea, please share them to the Kea Users List (https://lists.isc.org/mailman/listinfo/kea-users). Bugs and feature requests may be submitted via GitLab at https://gitlab.isc.org/isc-projects/kea/issues. ## Changes The following summarizes changes and important upgrade notes since the previous release (1.7.2). ``` 1699. [func] fdupont, marcin Implemented status-get command which returns general status information about a Kea server status and optionally HA specific information if the HA hooks library is present. (Gitlab #1041) 1698. [doc] wlodek Avalanche scenario for perfdhcp is now documented. (Gitlab #876) 1697. [doc] wlodek Forensic logging documentation now mentions database configuration. (Gitlab #943) 1696. [func] fdupont A new hook library libdhcp_bootp has been implemented. Once loaded, this hook will provide support for BOOTP packets, as defined in RFC1497. Please see the "BOOTP support" Section in the ARM for details. (Gitlab #898) 1695. [func] fdupont Added support of BOOTP leases with infinite valid lifetime. This includes representation of such leases in MySQL and PostgreSQL databases which the expire date can be a 32 bit integer. (Gitlan #897) 1694. [doc] marcin Described the usage of the ha-heartbeat command to check the states of the HA enabled DHCP servers. (Gitlab #998) 1693. [func] fdupont Client supplied ciaddr is now sent back when responding to DHCPINFORM (Gitlab #992) 1692. [build] fdupont Better support for google test 1.10.0. (Gitlab #954) 1691. [build] tomek Google test version detection improved. (Gitlab #206) 1690. [func] fdupont, razvan As a preparation for upcoming multi-threading, the PgSQL connection pool has been implemented. This code is not usable on its own yet, but it will allow all threads to share a pool of connections in the future. This should improve the overall PgSQL lease backend performance. Fixed some log messages that were missing lease type details in DHCPv6 PostgreSQL lease manager actions. (Gitlab #1044) ``` Thank you again to everyone who assisted us in making this release possible. We look forward to receiving your feedback.