... | ... | @@ -4,28 +4,31 @@ Welcome to Kea 1.9.8, the eighth monthly release of the 1.9 development branch. |
|
|
|
|
|
This release adds new features, improves existing features, clarifies documentation, and fixes a few bugs. The most notable changes introduced in this version are:
|
|
|
|
|
|
1. **Custom forensic logging** - The forensic logging hook library is now able to log custom expressions. The expressions can include any option (such as relay option 82) or sub-option (such as circuit-id or remote-id or any other sub-options), packet fields, network interface names, local or remote IP address and more. It uses the same expressions engine as when defining client classification or flexible identifiers. Evaluating expressions is a relatively expensive operation so more custom logs will have more performance impact than the default log. The more complex the expression is, the more impact it may have.
|
|
|
This feature included several separate tickets: added (+) plus operator [#1824, #1863], custom forensic logging format [#1860], better handling parameter-less operation [#1866], custom logging option 82 contents (and any other option) on renewals [#1576].
|
|
|
1. **Custom forensic logging** - The forensic logging hook library is now able to log custom expressions. The expressions can include any option (such as relay option 82) or sub-option (such as circuit-id, remote-id, or any other sub-option), packet fields, network interface names, local or remote IP address, and more. It uses the same expressions engine as when defining client classification or flexible identifiers. Evaluating expressions is a relatively expensive operation, so more customized logs will have more performance impact than the default log. The more complex the expression is, the more impact it may have.
|
|
|
|
|
|
This feature included several separate tickets: added (+) plus operator [#1824, #1863], custom forensic logging format [#1860], better handling of parameter-less operation [#1866], and custom logging option 82 contents (and any other option) on renewals [#1576].
|
|
|
|
|
|
2. **HA+MT stability** - The multi-threaded (MT) support for High Availability (HA) is now more stable. In particular, the hooks are now notified when Kea enters or leaves a critical state. This eliminates previously observed race conditions when shutting down or reconfiguring Kea with HA+MT enabled [#1876, #1818].
|
|
|
|
|
|
3. **Per device access control** - Kea is now able to drop packets coming from devices that have matching host reservations with class set to DROP (`DROP` class listed in the `client-classes` field in the `reservations`). This effectively allows the operator to selectively drop incoming packets from some devices, such as customers that have overdue payments, misbehaving or unwanted devices [#1815].
|
|
|
3. **Per-device access control** - Kea is now able to drop packets coming from devices that have matching host reservations with class set to DROP (`DROP` class listed in the `client-classes` field in the `reservations`). This effectively allows the operator to selectively drop incoming packets from some devices, such as customers that have overdue payments, and misbehaving or unwanted devices [#1815].
|
|
|
|
|
|
4. **Better vendor options handling in DHCPv6** - Two improvements related to the vendor options made it into this release. First, Kea is now able to process slightly malformed vendor options that have the inner length field set to an incorrect, overly large value. With this improvement, Kea can now be configured (see `lenient-option-parsing` in `compatibility` scope) to process slightly non-conformant options, rather than simply ignoring them. This should improve compatibility with devices such as RAD MiNID [#1860]. The second improvement lets Kea extract the enterprise identifier from the vendor class option in DHCPv6 [#1837].
|
|
|
4. **Better vendor options handling in DHCPv6** - Two improvements related to vendor options are included in this release. First, Kea is now able to process slightly malformed vendor options that have the inner length field set to an incorrect, overly large value. With this improvement, Kea can now be configured (see `lenient-option-parsing` in `compatibility` scope) to process slightly non-conformant options, rather than simply ignore them. This should improve compatibility with devices such as RAD MiNID [#1860]. The second improvement lets Kea extract the enterprise identifier from the vendor class option in DHCPv6 [#1837].
|
|
|
|
|
|
5. **Security** - Kea now obfuscates passwords in debug logs when the whole configuration is printed [#1721]. Authentication information is now logged on a dedicated logger, making it easier to implement security policies, such as logging to a dedicated secure storage [#1590]. TLS support is now functional when building with the Botan library (instead of OpenSSL). While Botan is much less popular than OpenSSL, it may be a viable alternative in cases where OpenSSL cannot be used for whatever reason [#1665].
|
|
|
5. **Security** - Kea now obscures passwords in debug logs when the whole configuration is printed [#1721]. Authentication information is now logged on a dedicated logger, making it easier to implement security policies, such as logging to a dedicated secure storage [#1590]. TLS support is now functional when building with the Botan library instead of OpenSSL. While Botan is much less popular than OpenSSL, it may be a viable alternative in cases where OpenSSL cannot be used [#1665].
|
|
|
|
|
|
6. **Bugfixes** - Corrected a bug in the DHCPv4 subnet selection logic. The server ignored the Subnet Selection option supplied by a client if its query contained a Relay Agent Information (RAI) option without a Link Selection option. After this change, the server respects the Subnet Selection option when RAI lacks the Link Selection option. If RAI includes it, it takes precedence over the Subnet Selection option [#1816]. An assorted collection of smaller issues reported by Coverity Scan has been fixed [#1806, #1854, #1855, #1852, #1850, #1853, #1851, #1805].
|
|
|
6. **Bugfixes** - We fixed a bug in the DHCPv4 subnet selection logic. The server ignored the Subnet Selection option supplied by a client if its query contained a Relay Agent Information (RAI) option without a Link Selection option. After this change, the server respects the Subnet Selection option when RAI lacks the Link Selection option. If RAI includes the Link Selection option, it takes precedence over the Subnet Selection option [#1816]. Assorted smaller issues reported by Coverity Scan have also been fixed [#1806, #1854, #1855, #1852, #1850, #1853, #1851, #1805].
|
|
|
|
|
|
7. **Build improvements** - Unit tests on CentOS 7 [#1888] and the Kea-netconf compilation [#1883] are now fixed, forensic logging unit test no longer fail on FreeBSD [#1879], added support for gcc11, which makes Kea compilation on Fedora 34 viable now [#1834, #1833, #1871, #1839], fixed two problems when generating Sphinx documentation, in particular when using Sphinx 3.3.1 or newer [#1877, #1560].
|
|
|
7. **Build improvements** - Unit tests on CentOS 7 [#1888] and the Kea-netconf compilation [#1883] are now fixed; forensic logging unit tests no longer fail on FreeBSD [#1879]; we have added support for gcc11, which now makes Kea compilation on Fedora 34 viable [#1834, #1833, #1871, #1839]; and we fixed two problems when generating Sphinx documentation, in particular when using Sphinx 3.3.1 or newer [#1877, #1560].
|
|
|
|
|
|
8. **Testing** - Perfdhcp is now able to simulate DHCPv6 traffic coming from multiple subnets. While perfdhcp is not typically used by end users (although they certainly can if they want to stress test their deployment), this tool is used for ISC performance testing. This extended capability will allow testing more complex IPv6 scenarios that more closely replicate actual deployments [#1416].
|
|
|
8. **Testing** - Perfdhcp is now able to simulate DHCPv6 traffic coming from multiple subnets. While perfdhcp is not typically used by end-users (although they certainly can if they want to stress test their deployment), this tool is used for ISC performance testing. This extended capability will allow testing of more complex IPv6 scenarios that more closely replicate actual deployments [#1416].
|
|
|
|
|
|
## Incompatible Changes
|
|
|
|
|
|
1. **Dropping Python 2 support** - Python 2 support was EOLed on 1 Jan 2020. Nowadays most distributions have full native Python 3 support, with the exception of CentOS 7. On CentOS 7, Python 2 is still the default, but Python 3 installation is an easy task. Kea version 1.9.8 dropped support for Python 2 in `kea-shell`. Kea users on CentOS 7 have several options. Users, who want to use `kea-shell` on CentOS 7 should install Python 3 packages. If this is not viable, `kea-shell` will still work with Python 2 for now, but TLS will not be supported. This partial backwards compatibility is expected to disappear when Kea 2.0.0 is released. The third alternative here is to use different tools or environments. `kea-shell` simply sends JSON commands over HTTPS and prints JSON responses. Such capabilities are available using various tools (such as `curl`, `socat`, `postman`) or scripting environments [#1873].
|
|
|
1. **Dropping Python 2 support** - Python 2 support was EOLed on 1 Jan 2020. Most current distributions have full native Python 3 support, with the exception of CentOS 7. On CentOS 7, Python 2 is still the default, but Python 3 installation is an easy task. Kea version 1.9.8 dropped support for Python 2 in `kea-shell`.
|
|
|
|
|
|
Kea users on CentOS 7 have several options. The most direct is for users who want to use `kea-shell` on CentOS 7 to install Python 3 packages. If this is not viable, `kea-shell` still works with Python 2 for now, but TLS is not supported. (This partial backward compatibility is expected to disappear when Kea 2.0.0 is released.) The third alternative is to use different tools or environments. `kea-shell` simply sends JSON commands over HTTPS and prints JSON responses. Such capabilities are available using various tools (such as `curl`, `socat`, `postman`) or scripting environments [#1873].
|
|
|
|
|
|
2. **Kea shell in a separate RPM package** - `Kea-shell` is now available in a separate RPM package. The base Kea package no longer depends on Python 2 package.
|
|
|
2. **Kea shell in a separate RPM package** - `kea-shell` is now available in a separate RPM package. The base Kea package no longer depends on the Python 2 package.
|
|
|
|
|
|
## Known Issues
|
|
|
|
... | ... | @@ -55,7 +58,7 @@ https://kb.isc.org/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 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.
|
|
|
Kea is a DHCP implementation developed by Internet Systems Consortium 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 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:
|
|
|
|
... | ... | |