User check is an example hook application that reads known users list from a file. If the user is not known, it will be assigned a lease from the last subnet defined in the configuration file, e.g. to redirect him into a captive portal. This showcases how externals source of information can be used to influence Kea allocation engine. This hook is part of the Kea sources and is available in src/hooks/dhcp/user_chk directory.
This hook takes the value from different options in a DHCPREQUEST and inserts them into (other) options in a DHCPREPLY. Example usage is to take the value from an Option 82 string, and insert it in an Option 43 sub option, to direct the dhcp client to the correct config file in an auto provisioning scenario.
Kea software provides a way to handle host reservations that include addresses, prefixes, options, client classes and other features. The reservation can be based on hardware address, DUID, circuit-id or client-id in DHCPv4 and using hardware address or DUID in DHCPv6. However, there are sometimes scenario where the reservation is more complex, e.g. uses other options that mentioned above, uses part of specific options or perhaps even a combination of several options and fields to uniquely identify a client. Those scenarios are addressed by the Flexible Identifiers hook application.
This library provides an interface that can manipulate leases in an unified, safe way for all supported backends (memfile, MySQL, PostgreSQL, Cassandra). It allows things previously impossible: manipulate leases in memfile while Kea is running, sanity check changes, check lease existence and remove all leases belonging to specific subnet. It can also catch more obscure errors, like adding a lease with subnet-id that does not exist in the configuration or configuring a lease to use an address that is outside of the subnet to which it is supposed to belong.
Extends remote management (REST API and control channel) to manage subnets and shared networks. Allows listing, getting, adding and deleting subnets and shared networks. Also allows making existing subnet to become a part of shared subnet and remove subnet from shared networks.
Integration with RADIUS for access control and accounting are supported. Kea is able to send Access-Request messages and alter its behavior depending on the responses. Specific IP addresses may be assigned (if Framed-IP-Address or Framed-IPv6-Address is received), client can be assigned to specific pool (if Framed-Pool or Framed-IPv6-Pool is received) or denied service altogether (if Access-Reject is received). Kea can also send accounting messages to RADIUS accounting servers. As with other features, this supports both IPv4 and IPv6.
Two Kea instances can now be configured to run as a pair to provide higher availability. Two modes are supported. In hot standby mode there is a primary instance handling all traffic and sending updates to its secondary partner. The secondary monitors the health of the primary and is able to take over automatically in case the primary fails. In load balancing mode both partners are active and are handling approximately half of the traffic traffic. In case of a failure of either server, the partner is able to take over responding to all traffic directed to both servers. Support for additional backup servers is implemented. The solution supports both IPv4 and IPv6 and can work with any backend, including memfile. Note that this is NOT an implementation of the IETF standard DHCPv4 failover (which does not support DHCPv6)