diff -pruN 2.0.2-3/AUTHORS 2.2.0-1/AUTHORS --- 2.0.2-3/AUTHORS 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/AUTHORS 2022-07-26 06:08:02.000000000 +0000 @@ -6,25 +6,31 @@ Primary developers: memfile, database interface, core libdhcp++, host reservation, MAC extraction in DHCPv6, statistics manager, kea-shell, netconf, flex/bison - parsers, flex-id, documentation) + parsers, flex-id, documentation, config backend, + ddns_tuning) - Marcin Siodelski (DHCPv4, DHCPv6 components, options handling, perfdhcp, host reservation, lease file cleanup, lease expiration, control agent, shared networks, high availability, config backend) - Thomas Markwalder (DDNS, user_chk, global host reservations, stat commands, congestion handling, config backend, multi-threading mode - of high availability, forensic logging, leasequery) - - Wlodek Wencel (testing, release engineering) + of high availability, forensic logging, leasequery, + ddns_tuning) + - Wlodek Wencel (testing, release engineering, hammer, perfdhcp) - Francis Dupont (crypto, flex/bison parsers, perfdhcp, control agent, - radius, netconf, config backend, multi-threading) + radius, netconf, config backend, multi-threading, + GSS-TSIG) - Razvan Becheriu (cassandra, netconf, multi-threading, forensic logging, - run script hook, multi-threading mode of high availability) + run script hook, multi-threading mode of high availability, + GSS-TSIG) - Vicky Risk (documentation) - Suzanne Goldlust (documentation) - Andrei Pavel (build system, documentation, hammer, netconf, perfdhcp, - release engineering, shell scripts, testing) + release engineering, shell scripts, testing, limits) - Peter Davies (documentation) - Slawek Figiel (documentation) + - Dan Theisen (documentation, option handling, shell scripts) + - Marcin Godzina (documentation, release engineering, testing) Former developers who are no longer active: - Stephen Morris (Hooks, MySQL) @@ -110,6 +116,7 @@ We have received the following contribut - Jinmei Tatuya 2015-10: Pkt4o6 class improvements 2015-11: split Dhcpv4Srv::run() into run() and processPacket() + 2021-02: Fix keactrl exit code when netconf is not build - Sebastien Couture, Ubity Inc 2015-12: Fixes to MySQL schema creation @@ -232,3 +239,14 @@ We have received the following contribut - Brad Smith 2021-08: compilation fix for upcoming boost 1.77 + + - John Dickinson + 2021-11: Patch that adds support for v6 DUIDs to be embedded in v4 client + identifiers per RFC 4361. This allows Kea to support DDNS for + dual-stack clients per RFC 4703. + + - Peter Tirsek + 2022-01: Patch that adds new parameter "timestamp-format" in forensic log + hook library to be able to configure the timestamp format for log + file. Also adds the '%Q' extra format which adds the microseconds + subunits. diff -pruN 2.0.2-3/ChangeLog 2.2.0-1/ChangeLog --- 2.0.2-3/ChangeLog 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/ChangeLog 2022-07-26 06:08:02.000000000 +0000 @@ -1,31 +1,616 @@ -Kea 2.0.2 (stable) released on March 2, 2022 +Kea 2.2.0 (stable) released on July 27, 2022 -1957. [build] razvan - Library version numbers bumped for Kea 2.0.2 stable version. - (Gitlab #2327) +2045. [build] tmark + Bumped library version numbers for the Kea 2.2.0 stable release. + (Gitlab #2504) + +2044. [func] tmark + Modified indexes on the hosts table in the postgresql + schema to improve performance on host reservation searches. + Thanks to Paul Kutzer for suggesting these changes. + (Gitlab #2452) + +2043. [func] andrei + The status-get command now shows the status of the sockets being + opened to receive DHCP requests, and a list of errors for the + sockets that were not successfully created. + (Gitlab #2434) + +2042. [func] razvan + Added missing parameters to YANG modules, including TLS + parameters for database connections. + (Gitlab #2224) + +2041. [bug] tmark + HA now applies load balancing and scoping only to inbound + client packet types that apply to client lease fulfillment, + e.g. DHCPDISCOVER, DHCPREQUEST, DHCPV6_SOLICIT, DHCPV6_REQUEST, + etc. Previously, HA indiscriminately balanced and + scoped all inbound packets, including those related to lease + query. + (Gitlab #1781) + +2040. [func] djt + Added support for Alpine 3.16 in hammer.py. + (Gitlab #2491) + +2039. [doc] andrei + Updated the limits hook library ARM documentation to reflect + support for lease limits. + (Gitlab #2481) + +2038. [func] djt + Added a new statistic to kea-dhcp4 that counts host + reservation conflicts. They are now tracked at both + the global and subnet levels, as v4-reservation-conflicts + and subnet[id].v4-reservation-conflicts, respectively. + (Gitlab #2419) + +2037. [bug] razvan, marcin + Fixed a crash in the HA+MT scenario caused by a race condition + which occurred between resetting the CalloutHandle state and + accessing the hook point parameters, from different threads, + when unparking packets. + (Gitlab #2473) + +2036. [build] andrei + Added a tool that checks whether there are any missing REST + commands from the API Reference section of the ARM. + See tools/check-for-missing-api-commands.sh. + It has been integrated into the Gitlab CI and runs on every + push. + (Gitlab #2379) + +2035. [doc] Daniel Bjors + The Developer's Guide now correctly uses the Lease4CollectionPtr + and Lease6CollectionPtr types. Thanks to Daniel Bjors for + reporting this typo. + (Gitlab #2447) + +2034. [func] andrei + The PostgreSQL schema has been changed to provide initial support + for the lease-limiting feature, part of the limits hook library. + (Gitlab #2445) + +2033. [func] tmark + Functionality needed to support the lease-limiting feature of + of the limits hook library has been added to Memfile_LeaseMgr. + (Gitlab #2436) + +Kea 2.1.7 (development) released on June 29, 2022 + +2032. [build] razvan + The library version numbers have been bumped for the Kea 2.1.7 + development release. + (Gitlab #2455) + +2031. [func] fdupont + Improved compatibility with OpenSSL 3.0.x, in particular + recover system error messages. + (Gitlab #1614) + +2030. [doc] fdupont, tomek + GSS-TSIG examples updated. The recommendation to not use + client-keytab and credentials-cache at the same time added. + (Gitlab #2247) + +2029. [bug] fdupont + The check of the subnet id in configuration is stricter: + values outside the 0..4294967295 are rejected. Note that + the value 0 means to leave Kea to assign itself the id. + (Gitlab #2086) + +2028. [build] orbea, fdupont + Compatibility with LibreSSL 3.5.2 improved. + (Github #121, Gitlab #2411) + +2027. [func] fdupont + The TLS is now supported with Multi-Threaded HA (HA+MT) scenario. + Additional parameters (trust-anchor, cert-file, key-file, + require-client-certs) are now supported in the HA configuration. + (Gitlab #1706) + +2026. [func] andrei + The MySQL schema has been changed to provide initial support for + the lease limiting feature, part of the limits hook library. + (Gitlab #2438) + +2025. [bug] tmark + Added missing support for client-class user-context to + both MySQL and PostgreSQL CB hook libraries. + (Gitlab #2430) + +2024. [func] djt + The ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET log message format has been + slightly modified, so that when it is emitted for a subnet that + is not within a shared network, it emits "(none)" for the value + of the shared network. The ARM documentation for this parameter + has been updated to reflect that subnets within shared networks + will in fact display which shared network the subnet belongs to. + The ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET log message format has + changed to be consistent with the format of + ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET. + (Gitlab #2395) + +2023. [bug] tmark + Corrected a MySQL CB issue that caused subnets to be + updated without having audit entries created when the + affiliated shared-network is deleted. This can cause + the subnets to be excluded from subsequent CB refresh + cycles. + (Gitlab #2299) + +Kea 2.1.6 (development) released on May 25 2022 + +2022. [func] andrei, djt + kea-admin lease-upload now calls the lease file cleanup (LFC) + process to clean up entries with duplicate addresses in the input + CSV file, to avoid a conflict error when inserting the leases in + the database. kea-admin also no longer asks for input on + non-interactive shells. A new -y|--yes flag has been added that + enables automatic overwriting of any file that kea-admin writes + to, when dumping or uploading leases. + (Gitlab #2293) + +2021. [build] razvan + The library version numbers have been bumped for the Kea 2.1.6 + development release. + (Gitlab #2421) + +2020. [doc] andrei + The rate-limiting feature of the new limits hook library has been + documented. It can apply a specified limit of a certain number of + packets per time unit to a given client class or subnet. + (Gitlab #562, #1650) + +2019. [func] tmark + A new built-in class, "SKIP_DDNS", was added, which can be used + in conjunction with the ddns-tuning hook library to skip + performing DDNS updates for a given client. + (Gitlab #2354) + +2018. [func] razvan + The kea-dhcp4 server now supports portions of RFC 3396, allowing + it to send and receive DHCP options longer than 255 bytes. + (Gitlab #2227) + +2017. [bug] marcin + A bug in the allocation engine, which caused it to write an + allocated lease under the wrong subnet ID within a shared + network, has been corrected. This was occurring when multiple + clients matched the same fixed address reservation. The first + client is now assigned the fixed address, while a subsequent + client is then given a dynamically allocated address from a + different subnet in the shared network. + (Gitlab #2409) + +2016. [doc] fdupont + Documentation for the role-based access control (RBAC) + premium hook library was added to the ARM. + (Gitlab #1263) + +Kea 2.1.5 (development) released on Apr 27, 2022 + +2015. [bug] tmark + Fixed an issue in kea-dhcp6 that was causing the server + not to update the FQDN option in outbound responses when + the ddns-tuning hook lib calculates a new host name. + (Gitlab #2392) + +2014. [bug] tmark + Correct an issue that was causing reconfigure to fail + in kea-dhcp4 and kea-dhcp6 when using ddns-tuning hook + library. + (Gitlab #2390) -1956. [bug] tmark +2013. [build] razvan + Library version numbers bumped for Kea 2.1.5 development + version. + (Gitlab #2385) + +2012. [doc] andrei + Documented whether it's OK or not to have overlapping pools, + including PD pools in IPv6. + (Gitlab #1842) + +2011. [func] djt + Added CTRL_AGENT_COMMAND_RECEIVED log line with command and + source address to the kea-ctrl-agent for commands which + are not forwarded on to another daemon. Added client + remote-address to CTRL_AGENT_COMMAND_FORWARDED log message if + it is available. + (Gitlab #687) + +2010. [func] razvan + Several extra log messages now detail the subnet selection + process. The messages are available on debuglevel 40. + (Gitlab #2352) + +2009. [func] tmark + Added new hook callout points: ddns4_update to Kea DHCPv4 + server and ddns6_update to Kea DHCPv6 server. This enables + use of the ddns-tuning hook library. + (Gitlab #1548) + +2008. [func]* tomek + The support for benchmarks have been removed. + (Gitlab #2372) + +2007. [func] tmark + Added split() function to classification expression + language. + (GitLab #2272) + +2006. [func] slawek + Added ``service-sockets-require-all`` parameter to specify + mandatory successfully binding all needed service sockets to + initialize DHCP services (defaults to false). If any socket is + unavailable, then the service fails to start. Added + ``service-sockets-max-retries`` parameter (defaults to 0) to + specify the number of retries to open unavailable sockets and + ``service-sockets-retry-wait-time`` parameter to specify a time + interval to wait between attempts. + (Gitlab #1716) + +2005. [func]* razvan + The support for Cassandra database backend has been removed. + (Gitlab #2116) + +Kea 2.1.4 (development) released on March 30, 2022 + +2004. [build] razvan + Library version numbers bumped for Kea 2.1.4 development + version. + (Gitlab #2363) + +2003. [func] fdupont + Added the support of sub-options in the flex_option + hook library. + (GitLab #2314) + +2002. [bug] tmark + Fixed a bug in MySql config backend that caused it to + store unspecified, client-class valid and preferred life + time values as zero in the database. + (Gitlab #2344) + +2001. [bug] razvan + Fixed a bug which causes client classes with empty test + expressions to fail class evaluation when those classes are + retrieved from config backend. + (Gitlab #2336) + +2000. [func] fdupont + Added the ``early-global-reservations-lookup`` configuration + parameter which allows to perform a search for global host + reservations and set client classes before the subnet + selection. This is achieved when explicitly configured to + ``true`` and it defaults to ``false`` if not configured. + (Gitlab #2249) + +1999. [func] tmark, razvan + The kea-dhcp6 server fully supports using PostgreSQL for config + backend. This should be considered an experimental feature. + (Gitlab #2355, #2356) + +1998. [func] tmark, razvan + With the addition of support for client classes, the kea-dhcp4 + server now fully supports using PostgreSQL for config backend. + (Gitlab #2322) + +1997. [bug] tmark + The obsolete log message, DHCP4_NCR_CREATE, has been + removed from kea-dhcp4. + (GitLab #2301) + +Kea 2.1.3 (development) released on Feb 23, 2022 + +1996. [build] razvan + Library version numbers bumped for Kea 2.1.3 development + version. + (Gitlab #2317) + +1995. [func] tmark + kea-dhcp4 now supports using PostgreSQL for config + backend for everything except client classes. The + new hook library is libdhcp_pgsql_cb.so. This should + be considered an experimental feature. + (Gitlab #95) + +1994. [func] razvan + Added support for Server Identifier Override RAI sub-option + (RFC 5107). The implementation is not complete according to the + RFC, because the server does not store the RAI, but the + functionality handles expected use cases. + (Gitlab #1695) + +1993. [func] razvan + Added global and per subnet counters for allocation failures: + ``v4-allocation-fail``, ``v4-allocation-fail-shared-network``, + ``v4-allocation-fail-subnet``, ``v4-allocation-fail-no-pools``, + ``v4-allocation-fail-classes``, ``subnet[X].v4-allocation-fail``, + ``subnet[X].v4-allocation-fail-shared-network``, + ``subnet[X].v4-allocation-fail-subnet``, + ``subnet[X].v4-allocation-fail-no-pools``, + ``subnet[X].v4-allocation-fail-classes``, + ``v6-allocation-fail``, ``v6-allocation-fail-shared-network``, + ``v6-allocation-fail-subnet``, ``v6-allocation-fail-no-pools``, + ``v6-allocation-fail-classes``, ``subnet[X].v6-allocation-fail``, + ``subnet[X].v6-allocation-fail-shared-network``, + ``subnet[X].v6-allocation-fail-subnet``, + ``subnet[X].v6-allocation-fail-no-pools``, + ``subnet[X].v6-allocation-fail-classes``. + There is a warning log message emitted in the logs each time one + of the allocation failure counters is incremented. + (Gitlab #2054) + +1992. [bug] razvan + The ``maxver`` and ``maxsize`` logger parameters are excluded + from ``config-get`` command response if the logger output is + ``stdout``, ``stderr`` or ``syslog``. + (Gitlab #2288) + +1991. [bug] jinmei, razvan + Fixed keactrl exit code when netconf is not build. + (Gitlab #2262) + +1990. [func] razvan + Added the ``reservations-lookup-first`` configuration parameter + which controls whether host reservations lookup should be + performed before lease lookup. This parameter has effect only + when multi-threading is disabled. When multi-threading is + enabled, host reservations lookup is always performed first. The + ``reservations-lookup-first`` parameter defaults to ``false`` + when multi-threading is disabled. + (Gitlab #2036) + +Kea 2.1.2 (development) released on Jan 26, 2022 + +1989. [build] razvan + Library version numbers bumped for Kea 2.1.2 development + version. + (Gitlab #2281) + +1988. [bug] tmark Kea core logic now ensures options belonging to client classes are properly created when classes are read from configuration backends. - (Gitlab #2301) + (Gitlab #2246) + +1987. [bug] tmark + Fixed an issue in PostgreSQL support code that caused + asserts when compiled with: -Wp,-D_GLIBCXX_ASSERTIONS. + (Gitlab #2284) + +1986. [func] fdupont + The kea-admin command now accepts extra arguments which + are passed to the database command tool, e.g. '--ssl' to + 'mysql' with `kea-admin ... -x --ssl'. Quotes are not + preserved but multiple arguments can be given. + (Gitlab #2225) + +1985. [func] fdupont + Added support for using files to configure basic HTTP + credentials. Instead of configuring a value, it is taken from + the content of a file. The new parameters of the Control Agent + configuration are: + - 'user-file' pointing to a file vs 'user' + - 'password-file' pointing to a file vs 'password' + - 'password-file' pointing to a file with the secret + (which is :) vs 'user' and 'password'. + For the High Availability hook library the new parameter + is 'basic-auth-password-file' which can be used as an + alternative to 'basic-auth-password'. + (Gitlab #2006) + +1984. [func] andrei + Introduced the lease-upload command to kea-admin which can upload + leases from a memfile CSV file to a database backend. + (Gitlab #2039) + +1983. [bug] fdupont + Minimum and maximum values of lifetimes are no longer + skipped when the configuration is retrieved even when + they are the same as the default value. + (Gitlab #2222) -1955. [bug] andrei +1982. [bug] andrei The config for an HA peer now accepts an IPv6 address as a valid value for the "url" entry. - (Gitlab #2302) + (Gitlab #2264) + +1981. [func] tomek + The default-url DHCPv4 option has been replaced with + v4-captive-portal, as defined in RFC8910. + (Gitlab #1684) + +1980. [func]* andrei + The kea-admin lease-dump command now outputs a CSV file that is + compatible with the memfile backend. This is useful when + migrating from database to memfile. The generated output is + backwards incompatible. Any tools that depend on it would need + to adapt. + (Gitlab #2038) + +1979. [bug] fdupont + Update and delete operations on leases no longer raise + an error with infinite valid lifetime (used by BOOTP) + and MySQL or PostgreSQL backends where timestamps can + be limited to 32 bits. + (Gitlab 897) + +1978. [doc] tomek + The Kea Administrator Reference Manual now correctly states that + DHCPv6 authentication option has code 11, not 10. + (Gitlab #2207) + +1977. [bug] razvan + Use only MAX_HWADDR_LEN (20) bytes from remote-id when extracting + the MAC from relay options. + (Gitlab #2201) + +1976. [func] andrei + Added hwtype and hwaddr_source columns to v6 memfile. + (Gitlab #2236) + +1975. [func] tmark + Additional changes and corrections relating to Config Backend + were made to the PostgreSQL database schema. In addition, the + upgrade scripts were renamed to ensure proper file name ordering. + Note that PostgreSQL CB is not yet functional. + (Gitlab #2183, #2244, #2245) + +1974. [func] fdupont + The global parameter lookup has been refactored to provide better + performance. Proper return error code (CONTROL_RESULT_ERROR) has + been fixed in some cases when trying to apply the new + configuration. Old code was using wrong hardcoded '2' value + (CONTROL_RESULT_COMMAND_UNSUPPORTED). + (Gitlab #1082) + +1973. [func] fdupont + MySQL backends now can be configured to use the SSL/TLS + support to protect connections to the server. New + database parameters are "cert-file", "key-file", + "trust-anchor" and "cipher-list". The negotiated cipher + name is logged so the MySQL service configuration can + be checked. PostgreSQL accepts the same parameters + but they only trigger the call to the OpenSSL generic + initialization in the Pq C-API. + (Gitlab #34) + +1972. [func] andrei + Kea servers now can accept trailing commas in file + configurations. While parsing, a warning is printed with the + location of the comma to give the user the ability to correct + a mistake. + (Gitlab #2084) + +1971. [func] tmark, jad + Added support for embedded DHCPv6 DUIDs within DHCPv4 + Client Identifier options per RFC 4361. This allows + Kea to support DDNS in dual stack environments per + RFC 4703(Sec 5.2). Thanks to John Dickinson for + contributing the patch! + (Gitlab #1934) + +Kea 2.1.1 (development) released on Nov 24, 2021 + +1970. [build] razvan + Library version numbers bumped for Kea 2.1.1 development + version. + (Gitlab #2195) + +1969. [build] andrei + Fixed "make check -j N" running tests in parallel in src/lib/log. + (Gitlab #2172) + +1968. [build] andrei + Fixed make check failing when googletest support was disabled. + (Gitlab #2167) + +1967. [bug] andrei + Fixed a bug where keactrl did not color the active status code + for kea-dhcp-ddns as it did for the other servers. + (Gitlab #2117) + +1966. [func] djt + Allow Kea to pack opaque data tuples within options with zero + length to accommodate some DHCP clients who have been observed + to send DHCPv4 option 124 with zero length tuples. + (Gitlab #2021) + +1965. [func] andrei + Increase the value that "maxsize" can take from 2GB to 2PB. + (Gitlab #2130) + +1964. [func] wlodek + Added support for Debian 11 in hammer.py. + (Gitlab #2042, #2193) + +1963. [func] andrei + hammer.py has had several improvements. + NETCONF and PostgreSQL will be properly configured when running + prepare-system on Fedora and FreeBSD. + vagrant will be automatically upgraded if it is too outdated. + Error messages are more clear when running on unsupported + systems. + hammer.py is now able to detect Arch Linux distributions and + offers limited support for it, being able to prepare-system with + freeradius and netconf support. + (Gitlab #2111, #2112) + +1962. [func] andrei + kea-netconf updates: fixed store-extended-info, it was an + operational node instead of a config node. Added several + containers and leaves: compatibility, lenient-option-parsing, + multi-threading, enable-multi-threading, packet-queue-size, + thread-pool-size, valid-lifetime, min-valid-lifetime, + max-valid-lifetime, preferred-lifetime, min-preferred-lifetime, + max-preferred-lifetime, cache-max-age, cache-threshold, + ddns-generated-prefix, ddns-override-client-update, + ddns-override-no-update, ddns-qualifying-suffix, + ddns-replace-client-name, ddns-send-updates, + ddns-update-on-renew, ddns-use-conflict-resolution, + ip-reservations-unique, parked-packet-limit, reservations-global, + reservations-in-subnet, reservations-out-of-pool, + statistic-default-sample-age, statistic-default-sample-count, + store-extended-info, on-fail. + (Gitlab #2136) + +1961. [func] tomek, tmark + The initial, stubbed version of the PostgreSQL CB hook + library has been created. The library is not yet functional + and does not installed. + (Gitlab #1848) + +1960. [build] andrei + Froze sphinx dependency versions used to build documentation. + Added the update-python-dependencies Makefile rule to bump the + versions. + (Gitlab #2161) + +1959. [doc] djt + Move documentation for acceptable format strings into the Kea + ARM. The relevant section of the ARM was previously referring + to a dead link in the Log4cpp documentation. + (Gitlab #2134) + +1958. [func] tomek, tmark + PostgreSQL database schema has been extended with tables for + Config Backend (CB). This is the first step towards PostgreSQL + CB. However, as there is no code yet to use those new tables, + they're not not functional yet. + (Gitlab #90, #2166) -Kea 2.0.1 (stable) released on December 15, 2021 +Kea 2.1.0 (development) released on Oct 27, 2021 -1954. [build] razvan - Library version numbers bumped for Kea 2.0.1 stable version. - (Gitlab #2234) - -1953. [func] razvan, fdupont - Finish the GSS-TSIG hook library implementation. - (Gitlab #2228, #2122, #2173, #2175, #2177, #2138, #2174, #2121, - #2127, #2170, #2128, #2082, #2088, #2125, #2124, #2129, #2113, - #2089, #2056, #2120, #2095, #2092, #2109, #2114, #2115) +1957. [build] razvan + Library version numbers bumped for Kea 2.1.0 development + version. + (Gitlab #2141) + +1956. [bug] tmark + Modified stat_cmds hook library to omit statistics + for non-existent subnets from results returned by + stat-lease4-get and stat-lease6-get commands. + (Gitlab #2033) + +1955. [bug] tmark + kea-dhcp4 no longer sends DHCPNAKs in response to + DHCPREQUESTs for addresses for which it has no knowledge. + (Gitlab #1584) + +1954. [doc] fdupont + Updated the Developer's Guide to explain what to do when + GSS-TSIG hook unit tests fail from a system Kerberos + incompatible configuration. + (Gitlab #2056) + +1953. [build] fdupont + Changed the name of the GSS-TSIG hook library object to + libddns_gss_tsig.so. + (Gitlab #2115) Kea 2.0.0 (stable) released on September 29, 2021 @@ -1108,7 +1693,7 @@ Kea 1.8.0 (stable) released on Aug 26, 2 1792. [doc] tmark Added the Database Connectivity section to the ARM which explains - how Kea servers respond to back end database connectivity issues. + how Kea servers respond to backend database connectivity issues. (Gitlab #1284) 1791. [doc] tmark @@ -1677,7 +2262,7 @@ Kea 1.7.4 (development) released on Jan (Gitlab #1080) 1702. [func] razvan - Update and delete operations on database back-ends use lease old + Update and delete operations on database backends use lease old expire value (internal storage) to detect concurrent actions on the same lease. (Gitlab #1040) @@ -2521,7 +3106,7 @@ Kea 1.6.0-beta (development) released on 1554. [func] tmark kea-dhcp6 now uses globals, option definitions, options, - share-networks, and subnets from configuration back ends. + share-networks, and subnets from configuration backends. (Gitlab #413,!288, git ff367e273ed8763b354db272c5955a78203d865e) 1553. [func] marcin @@ -2548,7 +3133,7 @@ Kea 1.6.0-beta (development) released on 1549. [func] tmark kea-dhcp6 can now be configured to fetch data from configuration - back ends. It does not yet utilize the data fetched. + backends. It does not yet utilize the data fetched. (Gitlab #104,!290, git d8a25c1ecd17ad24bdce6af19e7a42ce66d4c4f2) 1548. [func] razvan @@ -3360,7 +3945,7 @@ Kea 1.4.0 released on June 15, 2018 1415. [bug] tmark kea-dhcp4 and kea-dhcp6 now validate the schema version - of lease and host back ends after establishing a connection. + of lease and host backends after establishing a connection. If a schema version does not match the version the server expects, the server will emit an error log and close the connection. This applies to MySQL, PostgreSQL, and Cassandra. @@ -3459,7 +4044,7 @@ Kea 1.4.0-beta released on May 18, 2018 1399. [func] tmark Support for fetching lease allocation statistics by subnet-id - or subnet-id range has been added to the Cassandra back end. This + or subnet-id range has been added to the Cassandra backend. This allows it to be used in conjunction with the Stat Cmds hooks library commands for fetching shared lease statistics. (Trac #5588, git 3fcfefdea5ac838936c2109ecbbbc32eabc8fdba) @@ -4870,7 +5455,7 @@ Kea 1.1.0-beta released on August 31, 20 1156. [bug] tmark Lease statistics are now recalculated during server startup and after each successful reconfiguration for Memfile, MySQL, and PostgreSQL - back ends. This addresses issues caused by accumulated values being lost + backends. This addresses issues caused by accumulated values being lost across restarts and reconfigurations making rendering values incorrect. (Trac #4294 git 0abdcf15f85861ffcb67d50fa4ce3965d25e4a9f) diff -pruN 2.0.2-3/config.h 2.2.0-1/config.h --- 2.0.2-3/config.h 2022-02-27 22:12:18.000000000 +0000 +++ 2.2.0-1/config.h 2022-07-26 06:09:05.000000000 +0000 @@ -73,15 +73,30 @@ /* Define to 1 if getsockopt(IPV6_USE_MIN_MTU) does not work */ /* #undef HAVE_BROKEN_GET_IPV6_USE_MIN_MTU */ -/* CQL is present */ -/* #undef HAVE_CQL */ - /* Define to 1 if gtest defines edit_distance::CreateUnifiedDiff */ /* #undef HAVE_CREATE_UNIFIED_DIFF */ /* Define to 1 if you have the header file. */ #define HAVE_DLFCN_H 1 +/* Define to 1 if you have the `EVP_MD_CTX_create' function. */ +/* #undef HAVE_EVP_MD_CTX_CREATE */ + +/* Define to 1 if you have the `EVP_MD_CTX_destroy' function. */ +/* #undef HAVE_EVP_MD_CTX_DESTROY */ + +/* Define to 1 if you have the `EVP_MD_CTX_free' function. */ +#define HAVE_EVP_MD_CTX_FREE 1 + +/* Define to 1 if you have the `EVP_MD_CTX_new' function. */ +#define HAVE_EVP_MD_CTX_NEW 1 + +/* Define to 1 if you have the `EVP_PKEY_new_mac_key' function. */ +/* #undef HAVE_EVP_PKEY_NEW_MAC_KEY */ + +/* Define to 1 if you have the `EVP_PKEY_new_raw_private_key' function. */ +#define HAVE_EVP_PKEY_NEW_RAW_PRIVATE_KEY 1 + /* Define to 1 if boost::asio::ssl::context::tls is available */ #define HAVE_GENERIC_TLS_METHOD 1 @@ -124,6 +139,9 @@ /* PostgreSQL is present */ /* #undef HAVE_PGSQL */ +/* PostgreSQL was built with OpenSSL support */ +/* #undef HAVE_PGSQL_SSL */ + /* Define to 1 if you have the `pselect' function. */ #define HAVE_PSELECT 1 @@ -222,7 +240,7 @@ #define PACKAGE_NAME "kea" /* Define to the full name and version of this package. */ -#define PACKAGE_STRING "kea 2.0.2" +#define PACKAGE_STRING "kea 2.2.0" /* Define to the one symbol short name of this package. */ #define PACKAGE_TARNAME "kea" @@ -231,7 +249,7 @@ #define PACKAGE_URL "" /* Define to the version of this package. */ -#define PACKAGE_VERSION "2.0.2" +#define PACKAGE_VERSION "2.2.0" /* Define to 1 if you have the ANSI C header files. */ #define STDC_HEADERS 1 @@ -243,7 +261,7 @@ /* #undef USE_STATIC_LINK */ /* Version number of package */ -#define VERSION "2.0.2" +#define VERSION "2.2.0" /* Compile with Botan crypto */ /* #undef WITH_BOTAN */ diff -pruN 2.0.2-3/config.h.in 2.2.0-1/config.h.in --- 2.0.2-3/config.h.in 2022-02-27 22:11:10.000000000 +0000 +++ 2.2.0-1/config.h.in 2022-07-26 06:08:13.000000000 +0000 @@ -72,15 +72,30 @@ /* Define to 1 if getsockopt(IPV6_USE_MIN_MTU) does not work */ #undef HAVE_BROKEN_GET_IPV6_USE_MIN_MTU -/* CQL is present */ -#undef HAVE_CQL - /* Define to 1 if gtest defines edit_distance::CreateUnifiedDiff */ #undef HAVE_CREATE_UNIFIED_DIFF /* Define to 1 if you have the header file. */ #undef HAVE_DLFCN_H +/* Define to 1 if you have the `EVP_MD_CTX_create' function. */ +#undef HAVE_EVP_MD_CTX_CREATE + +/* Define to 1 if you have the `EVP_MD_CTX_destroy' function. */ +#undef HAVE_EVP_MD_CTX_DESTROY + +/* Define to 1 if you have the `EVP_MD_CTX_free' function. */ +#undef HAVE_EVP_MD_CTX_FREE + +/* Define to 1 if you have the `EVP_MD_CTX_new' function. */ +#undef HAVE_EVP_MD_CTX_NEW + +/* Define to 1 if you have the `EVP_PKEY_new_mac_key' function. */ +#undef HAVE_EVP_PKEY_NEW_MAC_KEY + +/* Define to 1 if you have the `EVP_PKEY_new_raw_private_key' function. */ +#undef HAVE_EVP_PKEY_NEW_RAW_PRIVATE_KEY + /* Define to 1 if boost::asio::ssl::context::tls is available */ #undef HAVE_GENERIC_TLS_METHOD @@ -123,6 +138,9 @@ /* PostgreSQL is present */ #undef HAVE_PGSQL +/* PostgreSQL was built with OpenSSL support */ +#undef HAVE_PGSQL_SSL + /* Define to 1 if you have the `pselect' function. */ #undef HAVE_PSELECT diff -pruN 2.0.2-3/configure 2.2.0-1/configure --- 2.0.2-3/configure 2022-02-27 22:11:10.000000000 +0000 +++ 2.2.0-1/configure 2022-07-26 06:08:12.000000000 +0000 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.69 for kea 2.0.2. +# Generated by GNU Autoconf 2.69 for kea 2.2.0. # # Report bugs to . # @@ -590,8 +590,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE_NAME='kea' PACKAGE_TARNAME='kea' -PACKAGE_VERSION='2.0.2' -PACKAGE_STRING='kea 2.0.2' +PACKAGE_VERSION='2.2.0' +PACKAGE_STRING='kea 2.2.0' PACKAGE_BUGREPORT='kea-dev@lists.isc.org' PACKAGE_URL='' @@ -690,16 +690,6 @@ LEX GENERATE_MESSAGES_FALSE GENERATE_MESSAGES_TRUE PERL -BENCHMARK_SOURCE -BENCHMARK_LDADD -BENCHMARK_LDFLAGS -BENCHMARK_INCLUDES -BENCHMARK_CPPFLAGS -DISTCHECK_BENCHMARK_CONFIGURE_FLAG -HAVE_BENCHMARK_SOURCE_FALSE -HAVE_BENCHMARK_SOURCE_TRUE -HAVE_BENCHMARK_FALSE -HAVE_BENCHMARK_TRUE HAVE_BOTAN_BOOST_FALSE HAVE_BOTAN_BOOST_TRUE DISTCHECK_BOOST_CONFIGURE_FLAG @@ -718,12 +708,6 @@ HAVE_SYSREPO_TRUE SYSREPO_LIBS SYSREPO_INCLUDEDIR SYSREPO_CPPFLAGS -HAVE_CQL_FALSE -HAVE_CQL_TRUE -CQL_LIBS -CQL_CPPFLAGS -USE_CQL_STATIC_LIB_FALSE -USE_CQL_STATIC_LIB_TRUE HAVE_PGSQL_FALSE HAVE_PGSQL_TRUE PGSQL_LIBS @@ -934,15 +918,13 @@ enable_perfdhcp with_gtest_source with_gtest with_lcov -with_benchmark_source -with_benchmark with_openssl with_botan_config with_mysql with_dhcp_mysql with_pgsql with_dhcp_pgsql -enable_cql_static_lib +enable_pgsql_ssl with_cql with_libyang with_sysrepo @@ -1529,7 +1511,7 @@ if test "$ac_init_help" = "long"; then # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures kea 2.0.2 to adapt to many kinds of systems. +\`configure' configures kea 2.2.0 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1600,7 +1582,7 @@ fi if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of kea 2.0.2:";; + short | recursive ) echo "Configuration of kea 2.2.0:";; esac cat <<\_ACEOF @@ -1624,8 +1606,7 @@ Optional Features: --enable-static-link build programs with static link [[default=no]] --enable-perfdhcp enable perfdhcp, a DHCP benchmarking tool [default=no] - --enable-cql-static-lib build programs with cassandra cpp driver static - library [[default=no]] + --enable-pgsql-ssl enable OpenSSL support in PostgreSQL [default=yes] --enable-boost-headers-only Build with boost headers only rather than link with boost_system library. This is NOT recommended as it @@ -1660,25 +1641,21 @@ Optional Packages: --with-sysroot[=DIR] Search for dependent libraries within DIR (or the compiler's sysroot if not specified). --with-werror Compile using -Werror (default=no) - --with-gtest-source=PATH + --with-gtest-source[=PATH] location of the Googletest source - --with-gtest=PATH specify a path to gtest header files (PATH/include) + --with-gtest[=PATH] specify a path to gtest header files (PATH/include) and library (PATH/lib) - --with-lcov=PROGRAM enable gtest and coverage target using the specified + --with-lcov[=PROGRAM] enable gtest and coverage target using the specified lcov - --with-benchmark-source=PATH - location of the benchmark source - --with-benchmark=PATH specify a path to benchmark header files - (PATH/include) and library (PATH/lib) --with-openssl[=PATH] Enables OpenSSL, location can be specified optionally --with-botan-config=PATH specify the path to the botan-config script - --with-mysql=PATH path to the MySQL 'mysql_config' script (MySQL is + --with-mysql[=PATH] path to the MySQL 'mysql_config' script (MySQL is used for the DHCP database) - --with-pgsql=PATH path to the PostgreSQL 'pg_config' script - --with-cql=PATH path to pkg-config or the Cassandra CQL 'cql_config' + --with-pgsql[=PATH] path to the PostgreSQL 'pg_config' script + --with-cql[=PATH] path to pkg-config or the Cassandra CQL 'cql_config' script (deprecated) --with-libyang[=PATH] optional path to the libyang installation directory --with-sysrepo[=PATH] optional path to the sysrepo installation directory @@ -1778,7 +1755,7 @@ fi test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -kea configure 2.0.2 +kea configure 2.2.0 generated by GNU Autoconf 2.69 Copyright (C) 2012 Free Software Foundation, Inc. @@ -2477,7 +2454,7 @@ cat >config.log <<_ACEOF This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by kea $as_me 2.0.2, which was +It was created by kea $as_me 2.2.0, which was generated by GNU Autoconf 2.69. Invocation command line was $ $0 $@ @@ -3347,7 +3324,7 @@ fi # Define the identity of the package. PACKAGE='kea' - VERSION='2.0.2' + VERSION='2.2.0' cat >>confdefs.h <<_ACEOF @@ -17140,10 +17117,10 @@ $as_echo "no" >&6; } fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext - { $as_echo "$as_me:${as_lineno-$LINENO}: checking chrono support" >&5 + { $as_echo "$as_me:${as_lineno-$LINENO}: checking chrono support" >&5 $as_echo_n "checking chrono support... " >&6; } - feature="chrono" - cat confdefs.h - <<_ACEOF >conftest.$ac_ext + feature="chrono" + cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include using namespace std::chrono; @@ -17158,14 +17135,13 @@ _ACEOF if ac_fn_cxx_try_compile "$LINENO"; then : { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 $as_echo "yes" >&6; } - break else { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 $as_echo "no" >&6; } continue fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext - + break done @@ -18598,25 +18574,6 @@ fi -enable_benchmark="no" -BENCHMARK_INCLUDES= - - -# Check whether --with-benchmark-source was given. -if test "${with_benchmark_source+set}" = set; then : - withval=$with_benchmark_source; enable_benchmark="yes" ; BENCHMARK_SOURCE="$withval" -fi - - - -# Check whether --with-benchmark was given. -if test "${with_benchmark+set}" = set; then : - withval=$with_benchmark; benchmark_path="$withval"; enable_benchmark="yes" -else - benchmark_path="no" -fi - - # Sets up for use of botan unless openssl is specified # sets variables CRYPTO_* @@ -19156,64 +19113,106 @@ $as_echo "$CRYPTO_VERSION" >&6; } #CRYPTO_LDFLAGS="-ldl" CRYPTO_LDFLAGS="" CRYPTO_RPATH="" - { $as_echo "$as_me:${as_lineno-$LINENO}: checking support of SHA-2" >&5 + { $as_echo "$as_me:${as_lineno-$LINENO}: checking support of SHA-2" >&5 $as_echo_n "checking support of SHA-2... " >&6; } LIBS_SAVED=${LIBS} LIBS="$LIBS $CRYPTO_LIBS" CPPFLAGS_SAVED=${CPPFLAGS} CPPFLAGS="$CRYPTO_INCLUDES $CPPFLAGS" - cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h. */ -#include -int -main () -{ -const EVP_MD* h224 = EVP_sha224(); - const EVP_MD* h256 = EVP_sha256(); - const EVP_MD* h384 = EVP_sha384(); - const EVP_MD* h512 = EVP_sha512(); + ac_fn_cxx_check_func "$LINENO" "EVP_md5" "ac_cv_func_EVP_md5" +if test "x$ac_cv_func_EVP_md5" = xyes; then : - ; - return 0; -} +else + missing EVP entry for MD5 +fi + + ac_fn_cxx_check_func "$LINENO" "EVP_sha1" "ac_cv_func_EVP_sha1" +if test "x$ac_cv_func_EVP_sha1" = xyes; then : + +else + missing EVP entry for SHA1 +fi + + ac_fn_cxx_check_func "$LINENO" "EVP_sha224" "ac_cv_func_EVP_sha224" +if test "x$ac_cv_func_EVP_sha224" = xyes; then : + +else + missing EVP entry for SHA224 +fi + + ac_fn_cxx_check_func "$LINENO" "EVP_sha256" "ac_cv_func_EVP_sha256" +if test "x$ac_cv_func_EVP_sha256" = xyes; then : + +else + missing EVP entry for SHA256 +fi + + ac_fn_cxx_check_func "$LINENO" "EVP_sha384" "ac_cv_func_EVP_sha384" +if test "x$ac_cv_func_EVP_sha384" = xyes; then : + +else + missing EVP entry for SHA384 +fi + + ac_fn_cxx_check_func "$LINENO" "EVP_sha512" "ac_cv_func_EVP_sha512" +if test "x$ac_cv_func_EVP_sha512" = xyes; then : + +else + missing EVP entry for SHA512 +fi + + for ac_func in EVP_MD_CTX_new EVP_MD_CTX_free +do : + as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` +ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var" +if eval test \"x\$"$as_ac_var"\" = x"yes"; then : + cat >>confdefs.h <<_ACEOF +#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 _ACEOF -if ac_fn_cxx_try_link "$LINENO"; then : - { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 -$as_echo "yes" >&6; } + else - as_fn_error $? "missing EVP entry for SHA-2" "$LINENO" 5 + for ac_func in EVP_MD_CTX_create EVP_MD_CTX_destroy +do : + as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` +ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var" +if eval test \"x\$"$as_ac_var"\" = x"yes"; then : + cat >>confdefs.h <<_ACEOF +#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 +_ACEOF + +else + as_fn_error $? "missing EVP MD CTX functions" "$LINENO" 5 fi -rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext - { $as_echo "$as_me:${as_lineno-$LINENO}: checking HMAC functions returning ints" >&5 -$as_echo_n "checking HMAC functions returning ints... " >&6; } - cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h. */ -#include - #include -int -main () -{ -#if OPENSSL_VERSION_NUMBER < 0x10100000L - HMAC_CTX ctx, tmp; - int n = HMAC_Init(&ctx, NULL, 0, NULL); - n += HMAC_Update(&ctx, NULL, 0); - n += HMAC_CTX_copy(&tmp, &ctx); - n += HMAC_Final(&tmp, NULL, NULL); - #endif +done - ; - return 0; -} +fi +done + + for ac_func in EVP_PKEY_new_raw_private_key +do : + ac_fn_cxx_check_func "$LINENO" "EVP_PKEY_new_raw_private_key" "ac_cv_func_EVP_PKEY_new_raw_private_key" +if test "x$ac_cv_func_EVP_PKEY_new_raw_private_key" = xyes; then : + cat >>confdefs.h <<_ACEOF +#define HAVE_EVP_PKEY_NEW_RAW_PRIVATE_KEY 1 _ACEOF -if ac_fn_cxx_try_link "$LINENO"; then : - { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 -$as_echo "yes" >&6; } + +else + for ac_func in EVP_PKEY_new_mac_key +do : + ac_fn_cxx_check_func "$LINENO" "EVP_PKEY_new_mac_key" "ac_cv_func_EVP_PKEY_new_mac_key" +if test "x$ac_cv_func_EVP_PKEY_new_mac_key" = xyes; then : + cat >>confdefs.h <<_ACEOF +#define HAVE_EVP_PKEY_NEW_MAC_KEY 1 +_ACEOF + else - as_fn_error $? "HMAC functions return void: please use OpenSSL version 1.0.1 or later" "$LINENO" 5 + as_fn_error $? "missing EVP PKEY new key function" "$LINENO" 5 fi -rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext +done + +fi +done + LIBS=${LIBS_SAVED} CPPFLAGS=${CPPFLAGS_SAVED} fi @@ -19505,27 +19504,18 @@ else fi -# allow building kea programs with static link to cassandra cpp-driver. -# Check whether --enable-cql-static-lib was given. -if test "${enable_cql_static_lib+set}" = set; then : - enableval=$enable_cql_static_lib; enable_cql_static_lib=yes +# allow building kea programs with a PostgreSQL without OpenSSL. +# Check whether --enable-pgsql-ssl was given. +if test "${enable_pgsql_ssl+set}" = set; then : + enableval=$enable_pgsql_ssl; pgsql_ssl=$enableval else - enable_cql_static_lib=no + pgsql_ssl=no fi - if test "$enable_cql_static_lib" = yes; then - USE_CQL_STATIC_LIB_TRUE= - USE_CQL_STATIC_LIB_FALSE='#' -else - USE_CQL_STATIC_LIB_TRUE='#' - USE_CQL_STATIC_LIB_FALSE= -fi +if test "${pgsql_ssl}" = "yes"; then -#AC_DEFINE USE_CQL_STATIC_LIB? (unused) +$as_echo "#define HAVE_PGSQL_SSL 1" >>confdefs.h -cql_lib="cassandra" -if test "${enable_cql_static_lib}" = "yes" ; then - cql_lib="${cql_lib}_static" fi cql_config="no" @@ -19536,81 +19526,10 @@ if test "${with_cql+set}" = set; then : fi -if test "${cql_config}" = "yes" ; then - CQL_CONFIG="$PKG_CONFIG" -elif test "${cql_config}" != "no" ; then - CQL_CONFIG="${cql_config}" +if test "${cql_config}" != "no" ; then + as_fn_error $? "$CQL_CONFIG Cassandra is no longer supported" "$LINENO" 5 fi -if test "$CQL_CONFIG" != "" ; then - if test -d "$CQL_CONFIG" -o ! -x "$CQL_CONFIG" ; then - as_fn_error $? "--with-cql should point to a pkg-config or cql_config program" "$LINENO" 5 - fi - - $CQL_CONFIG --print-errors $cql_lib - if test $? -ne 0; then - as_fn_error $? "$CQL_CONFIG $cql_lib failed" "$LINENO" 5 - fi - - CQL_INCLUDEDIR=`$CQL_CONFIG --cflags-only-I $cql_lib` - CQL_CPPFLAGS=`$CQL_CONFIG --cflags-only-other $cql_lib` - CQL_LIBS=`$CQL_CONFIG --libs $cql_lib` - CQL_LIBS="$CQL_LIBS $CRYPTO_LIBS" - CQL_VERSION=`$CQL_CONFIG --modversion $cql_lib` - - CQL_CPPFLAGS="${CQL_CPPFLAGS} ${CQL_INCLUDEDIR}" - - - - # Check that a simple program using CQL functions can compile and link. - CPPFLAGS_SAVED="$CPPFLAGS" - LIBS_SAVED="$LIBS" - - CPPFLAGS="$CQL_CPPFLAGS $CPPFLAGS" - LIBS="$CQL_LIBS $LIBS" - - cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h. */ -#include -int -main () -{ -CassCluster* cluster = cass_cluster_new(); - cass_cluster_free(cluster); - ; - return 0; -} -_ACEOF -if ac_fn_cxx_try_link "$LINENO"; then : - { $as_echo "$as_me:${as_lineno-$LINENO}: result: checking for Cassandra CQL headers and library... yes" >&5 -$as_echo "checking for Cassandra CQL headers and library... yes" >&6; } -else - { $as_echo "$as_me:${as_lineno-$LINENO}: result: checking for Cassandra CQL headers and library... no" >&5 -$as_echo "checking for Cassandra CQL headers and library... no" >&6; } - as_fn_error $? "Needs Cassandra CQL library" "$LINENO" 5 - -fi -rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext - CPPFLAGS=$CPPFLAGS_SAVED - LIBS=$LIBS_SAVED - - # Note that CQL is present in the config.h file - -$as_echo "#define HAVE_CQL 1" >>confdefs.h - -fi - -# ... and at the shell level, so Makefile.am can take action depending on this. - if test "$CQL_CONFIG" != ""; then - HAVE_CQL_TRUE= - HAVE_CQL_FALSE='#' -else - HAVE_CQL_TRUE='#' - HAVE_CQL_FALSE= -fi - - # Check for sysrepo. @@ -19978,7 +19897,9 @@ $as_echo "$as_me: WARNING: ${line}" >&2; # Add to the runtime search path if the flag is not already added. if test -n "${ISC_RPATH_FLAG}" && test "$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Fc -e "${ISC_RPATH_FLAG}")" = 0; then library_location=$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Eo '\-L.*\b' | sed 's/-L//g') - LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + if test -n "${library_location}"; then + LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + fi fi fi @@ -20350,7 +20271,9 @@ $as_echo "$as_me: WARNING: ${line}" >&2; # Add to the runtime search path if the flag is not already added. if test -n "${ISC_RPATH_FLAG}" && test "$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Fc -e "${ISC_RPATH_FLAG}")" = 0; then library_location=$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Eo '\-L.*\b' | sed 's/-L//g') - LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + if test -n "${library_location}"; then + LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + fi fi fi @@ -20737,7 +20660,9 @@ $as_echo "$as_me: WARNING: ${line}" >&2; # Add to the runtime search path if the flag is not already added. if test -n "${ISC_RPATH_FLAG}" && test "$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Fc -e "${ISC_RPATH_FLAG}")" = 0; then library_location=$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Eo '\-L.*\b' | sed 's/-L//g') - LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + if test -n "${library_location}"; then + LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + fi fi fi @@ -21161,7 +21086,9 @@ $as_echo "$as_me: WARNING: ${line}" >&2; # Add to the runtime search path if the flag is not already added. if test -n "${ISC_RPATH_FLAG}" && test "$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Fc -e "${ISC_RPATH_FLAG}")" = 0; then library_location=$(printf '%s\n' "${LIBRARY_LIBS}" | grep -Eo '\-L.*\b' | sed 's/-L//g') - LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + if test -n "${library_location}"; then + LIBRARY_LIBS="${LIBRARY_LIBS} ${ISC_RPATH_FLAG}${library_location}" + fi fi fi @@ -21327,7 +21254,7 @@ $as_echo "$as_me: WARNING: ${line}" >&2; done fi - as_fn_error $? "Count not integrate with Sysrepo C++ bindings. Make sure that the sysrepo-cpp/Session.hpp header and the libsysrepo-cpp.so library can be found." "$LINENO" 5 + as_fn_error $? "Could not integrate with Sysrepo C++ bindings. Make sure that the sysrepo-cpp/Session.hpp header and the libsysrepo-cpp.so library can be found." "$LINENO" 5 fi rm -f core conftest.err conftest.$ac_objext \ @@ -22179,115 +22106,6 @@ fi # -# Check availability of benchmark. -# -BENCHMARK_CPPFLAGS= -BENCHMARK_LDFLAGS= -BENCHMARK_LDADD= -DISTCHECK_BENCHMARK_CONFIGURE_FLAG= -BENCHMARK_VERSION="unknown" - -if test "x$enable_benchmark" = "xyes" ; then - - DISTCHECK_BENCHMARK_CONFIGURE_FLAG="--with-benchmark=$benchmark_path" - - if test -n "$with_benchmark_source" ; then - - if test "x$BENCHMARK_SOURCE" = "xyes" ; then - - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for benchmark source" >&5 -$as_echo_n "checking for benchmark source... " >&6; } - # If not specified, try some common paths. - BENCHMARK_SOURCE= - for d in /usr/src/benchmark /usr/local /usr/pkg /opt /opt/local ; do - if test -f $d/src/benchmark.cc; then - BENCHMARK_SOURCE=$d - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $BENCHMARK_SOURCE" >&5 -$as_echo "$BENCHMARK_SOURCE" >&6; } - break - fi - done - if test -z $BENCHMARK_SOURCE ; then - as_fn_error $? "no benchmark source but it was selected" "$LINENO" 5 - fi - else - if test ! -d $BENCHMARK_SOURCE/src; then - BENCHMARK_SOURCE=$BENCHMARK_SOURCE/benchmark - fi - if test -f $BENCHMARK_SOURCE/src/benchmark.cc; then - have_benchmark_source=yes - else - as_fn_error $? "no benchmark source at $BENCHMARK_SOURCE" "$LINENO" 5 - fi - fi - have_benchmark_source=yes - BENCHMARK_CPPFLAGS=`cat \${BENCHMARK_SOURCE}/build/src/CMakeFiles/benchmark.dir/flags.make | grep CXX_DEFINES | cut -d "=" -f 2` - BENCHMARK_LDADD="\$(BENCHMARK_SOURCE)/build/src/libbenchmark.a" - DISTCHECK_BENCHMARK_CONFIGURE_FLAG="--with-benchmark-source=$BENCHMARK_SOURCE" - BENCHMARK_INCLUDES="-I$BENCHMARK_SOURCE \ - -I$BENCHMARK_SOURCE/src \ - -I$BENCHMARK_SOURCE/include \ - -I$BENCHMARK_SOURCE/include/benchmark" - BENCHMARK_VERSION="$(basename $BENCHMARK_SOURCE)" - fi - - if test "$benchmark_path" != "no" ; then - if test "$benchmark_path" != "yes"; then - BENCHMARK_PATHS=$benchmark_path - fi - if test -z "${BENCHMARK_PATHS}" ; then - BENCHMARK_PATHS="/usr /usr/local" - fi - BENCHMARK_FOUND="false" - for dir in ${BENCHMARK_PATHS}; do - if test -f "$dir/include/benchmark/benchmark.h"; then - if ! test -f "$dir/lib/libbenchmark.a"; then - { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Found Google Benchmark include but not the library in $dir." >&5 -$as_echo "$as_me: WARNING: Found Google Benchmark include but not the library in $dir." >&2;} - continue - fi - BENCHMARK_INCLUDES="-I$dir/include" - BENCHMARK_LDFLAGS="-L$dir/lib" - BENCHMARK_LDADD="$dir/lib/libbenchmark.a " - BENCHMARK_FOUND="true" - break - fi - done - if test "${BENCHMARK_FOUND}" != "true"; then - as_fn_error $? "Cannot find benchmark in: $BENCHMARK_PATHS" "$LINENO" 5 - fi - - fi - - if test $enable_gtest = no; then - as_fn_error $? "--with-benchmark and --with-benchmark-source require --with-gtest or --with-gtest-source" "$LINENO" 5 - fi - -fi - if test $enable_benchmark != "no"; then - HAVE_BENCHMARK_TRUE= - HAVE_BENCHMARK_FALSE='#' -else - HAVE_BENCHMARK_TRUE='#' - HAVE_BENCHMARK_FALSE= -fi - - if test "X$have_benchmark_source" = "Xyes"; then - HAVE_BENCHMARK_SOURCE_TRUE= - HAVE_BENCHMARK_SOURCE_FALSE='#' -else - HAVE_BENCHMARK_SOURCE_TRUE='#' - HAVE_BENCHMARK_SOURCE_FALSE= -fi - - - - - - - - -# # Some Googletest versions bug with C++11 compilers # if test $enable_gtest != "no"; then @@ -23949,8 +23767,6 @@ ac_config_files="$ac_config_files src/bi ac_config_files="$ac_config_files src/bin/admin/tests/Makefile" -ac_config_files="$ac_config_files src/bin/admin/tests/cql_tests.sh" - ac_config_files="$ac_config_files src/bin/admin/tests/data/Makefile" ac_config_files="$ac_config_files src/bin/admin/tests/admin_tests.sh" @@ -24083,6 +23899,10 @@ ac_config_files="$ac_config_files src/ho ac_config_files="$ac_config_files src/hooks/dhcp/mysql_cb/tests/Makefile" +ac_config_files="$ac_config_files src/hooks/dhcp/pgsql_cb/Makefile" + +ac_config_files="$ac_config_files src/hooks/dhcp/pgsql_cb/tests/Makefile" + ac_config_files="$ac_config_files src/hooks/dhcp/run_script/Makefile" ac_config_files="$ac_config_files src/hooks/dhcp/run_script/libloadtests/Makefile" @@ -24161,8 +23981,6 @@ ac_config_files="$ac_config_files src/li ac_config_files="$ac_config_files src/lib/dhcpsrv/Makefile" -ac_config_files="$ac_config_files src/lib/dhcpsrv/benchmarks/Makefile" - ac_config_files="$ac_config_files src/lib/dhcpsrv/tests/Makefile" ac_config_files="$ac_config_files src/lib/dhcpsrv/tests/test_libraries.h" @@ -24235,12 +24053,6 @@ ac_config_files="$ac_config_files src/li ac_config_files="$ac_config_files src/lib/pgsql/testutils/Makefile" -ac_config_files="$ac_config_files src/lib/cql/Makefile" - -ac_config_files="$ac_config_files src/lib/cql/tests/Makefile" - -ac_config_files="$ac_config_files src/lib/cql/testutils/Makefile" - ac_config_files="$ac_config_files src/lib/process/Makefile" ac_config_files="$ac_config_files src/lib/process/tests/Makefile" @@ -24287,18 +24099,6 @@ ac_config_files="$ac_config_files src/sh ac_config_files="$ac_config_files src/share/database/scripts/Makefile" -ac_config_files="$ac_config_files src/share/database/scripts/cql/Makefile" - -ac_config_files="$ac_config_files src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh" - -ac_config_files="$ac_config_files src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh" - -ac_config_files="$ac_config_files src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh" - -ac_config_files="$ac_config_files src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh" - -ac_config_files="$ac_config_files src/share/database/scripts/cql/wipe_data.sh" - ac_config_files="$ac_config_files src/share/database/scripts/mysql/Makefile" ac_config_files="$ac_config_files src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh" @@ -24345,31 +24145,49 @@ ac_config_files="$ac_config_files src/sh ac_config_files="$ac_config_files src/share/database/scripts/mysql/upgrade_011_to_012.sh" +ac_config_files="$ac_config_files src/share/database/scripts/mysql/upgrade_012_to_013.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/mysql/upgrade_013_to_014.sh" + ac_config_files="$ac_config_files src/share/database/scripts/mysql/wipe_data.sh" ac_config_files="$ac_config_files src/share/database/scripts/pgsql/Makefile" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh" + +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_007_to_008.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_008_to_009.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_009_to_010.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_010_to_011.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_011_to_012.sh" -ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh" +ac_config_files="$ac_config_files src/share/database/scripts/pgsql/upgrade_012_to_013.sh" ac_config_files="$ac_config_files src/share/database/scripts/pgsql/wipe_data.sh" @@ -24598,14 +24416,6 @@ if test -z "${HAVE_PGSQL_TRUE}" && test as_fn_error $? "conditional \"HAVE_PGSQL\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi -if test -z "${USE_CQL_STATIC_LIB_TRUE}" && test -z "${USE_CQL_STATIC_LIB_FALSE}"; then - as_fn_error $? "conditional \"USE_CQL_STATIC_LIB\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi -if test -z "${HAVE_CQL_TRUE}" && test -z "${HAVE_CQL_FALSE}"; then - as_fn_error $? "conditional \"HAVE_CQL\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi if test -z "${HAVE_SYSREPO_TRUE}" && test -z "${HAVE_SYSREPO_FALSE}"; then as_fn_error $? "conditional \"HAVE_SYSREPO\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 @@ -24614,14 +24424,6 @@ if test -z "${HAVE_BOTAN_BOOST_TRUE}" && as_fn_error $? "conditional \"HAVE_BOTAN_BOOST\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi -if test -z "${HAVE_BENCHMARK_TRUE}" && test -z "${HAVE_BENCHMARK_FALSE}"; then - as_fn_error $? "conditional \"HAVE_BENCHMARK\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi -if test -z "${HAVE_BENCHMARK_SOURCE_TRUE}" && test -z "${HAVE_BENCHMARK_SOURCE_FALSE}"; then - as_fn_error $? "conditional \"HAVE_BENCHMARK_SOURCE\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi if test -z "${GENERATE_MESSAGES_TRUE}" && test -z "${GENERATE_MESSAGES_FALSE}"; then as_fn_error $? "conditional \"GENERATE_MESSAGES\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 @@ -25079,7 +24881,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by kea $as_me 2.0.2, which was +This file was extended by kea $as_me 2.2.0, which was generated by GNU Autoconf 2.69. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -25145,7 +24947,7 @@ _ACEOF cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`" ac_cs_version="\\ -kea config.status 2.0.2 +kea config.status 2.2.0 configured by $0, generated by GNU Autoconf 2.69, with options \\"\$ac_cs_config\\" @@ -25672,7 +25474,6 @@ do "src/bin/admin/Makefile") CONFIG_FILES="$CONFIG_FILES src/bin/admin/Makefile" ;; "src/bin/admin/kea-admin") CONFIG_FILES="$CONFIG_FILES src/bin/admin/kea-admin" ;; "src/bin/admin/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/bin/admin/tests/Makefile" ;; - "src/bin/admin/tests/cql_tests.sh") CONFIG_FILES="$CONFIG_FILES src/bin/admin/tests/cql_tests.sh" ;; "src/bin/admin/tests/data/Makefile") CONFIG_FILES="$CONFIG_FILES src/bin/admin/tests/data/Makefile" ;; "src/bin/admin/tests/admin_tests.sh") CONFIG_FILES="$CONFIG_FILES src/bin/admin/tests/admin_tests.sh" ;; "src/bin/admin/tests/memfile_tests.sh") CONFIG_FILES="$CONFIG_FILES src/bin/admin/tests/memfile_tests.sh" ;; @@ -25739,6 +25540,8 @@ do "src/hooks/dhcp/lease_cmds/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/lease_cmds/tests/Makefile" ;; "src/hooks/dhcp/mysql_cb/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/mysql_cb/Makefile" ;; "src/hooks/dhcp/mysql_cb/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/mysql_cb/tests/Makefile" ;; + "src/hooks/dhcp/pgsql_cb/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/pgsql_cb/Makefile" ;; + "src/hooks/dhcp/pgsql_cb/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/pgsql_cb/tests/Makefile" ;; "src/hooks/dhcp/run_script/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/run_script/Makefile" ;; "src/hooks/dhcp/run_script/libloadtests/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/run_script/libloadtests/Makefile" ;; "src/hooks/dhcp/run_script/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/hooks/dhcp/run_script/tests/Makefile" ;; @@ -25778,7 +25581,6 @@ do "src/lib/dhcp_ddns/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcp_ddns/Makefile" ;; "src/lib/dhcp_ddns/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcp_ddns/tests/Makefile" ;; "src/lib/dhcpsrv/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcpsrv/Makefile" ;; - "src/lib/dhcpsrv/benchmarks/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcpsrv/benchmarks/Makefile" ;; "src/lib/dhcpsrv/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcpsrv/tests/Makefile" ;; "src/lib/dhcpsrv/tests/test_libraries.h") CONFIG_FILES="$CONFIG_FILES src/lib/dhcpsrv/tests/test_libraries.h" ;; "src/lib/dhcpsrv/testutils/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/dhcpsrv/testutils/Makefile" ;; @@ -25815,9 +25617,6 @@ do "src/lib/pgsql/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/pgsql/Makefile" ;; "src/lib/pgsql/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/pgsql/tests/Makefile" ;; "src/lib/pgsql/testutils/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/pgsql/testutils/Makefile" ;; - "src/lib/cql/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/cql/Makefile" ;; - "src/lib/cql/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/cql/tests/Makefile" ;; - "src/lib/cql/testutils/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/cql/testutils/Makefile" ;; "src/lib/process/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/process/Makefile" ;; "src/lib/process/tests/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/process/tests/Makefile" ;; "src/lib/process/testutils/Makefile") CONFIG_FILES="$CONFIG_FILES src/lib/process/testutils/Makefile" ;; @@ -25841,12 +25640,6 @@ do "src/share/api/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/api/Makefile" ;; "src/share/database/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/database/Makefile" ;; "src/share/database/scripts/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/Makefile" ;; - "src/share/database/scripts/cql/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/Makefile" ;; - "src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh" ;; - "src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh" ;; - "src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh" ;; - "src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh" ;; - "src/share/database/scripts/cql/wipe_data.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/cql/wipe_data.sh" ;; "src/share/database/scripts/mysql/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/Makefile" ;; "src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh" ;; "src/share/database/scripts/mysql/upgrade_002.0_to_003.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_002.0_to_003.0.sh" ;; @@ -25870,19 +25663,28 @@ do "src/share/database/scripts/mysql/upgrade_009.6_to_010.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_009.6_to_010.0.sh" ;; "src/share/database/scripts/mysql/upgrade_010_to_011.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_010_to_011.sh" ;; "src/share/database/scripts/mysql/upgrade_011_to_012.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_011_to_012.sh" ;; + "src/share/database/scripts/mysql/upgrade_012_to_013.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_012_to_013.sh" ;; + "src/share/database/scripts/mysql/upgrade_013_to_014.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/upgrade_013_to_014.sh" ;; "src/share/database/scripts/mysql/wipe_data.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/mysql/wipe_data.sh" ;; "src/share/database/scripts/pgsql/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/Makefile" ;; - "src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh" ;; - "src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh" ;; - "src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh" ;; - "src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh" ;; - "src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh" ;; - "src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh" ;; - "src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh" ;; - "src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh" ;; - "src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh" ;; - "src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh" ;; - "src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh" ;; + "src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh" ;; + "src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh" ;; + "src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh" ;; + "src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh" ;; + "src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh" ;; + "src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh" ;; + "src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh" ;; + "src/share/database/scripts/pgsql/upgrade_007_to_008.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_007_to_008.sh" ;; + "src/share/database/scripts/pgsql/upgrade_008_to_009.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_008_to_009.sh" ;; + "src/share/database/scripts/pgsql/upgrade_009_to_010.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_009_to_010.sh" ;; + "src/share/database/scripts/pgsql/upgrade_010_to_011.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_010_to_011.sh" ;; + "src/share/database/scripts/pgsql/upgrade_011_to_012.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_011_to_012.sh" ;; + "src/share/database/scripts/pgsql/upgrade_012_to_013.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/upgrade_012_to_013.sh" ;; "src/share/database/scripts/pgsql/wipe_data.sh") CONFIG_FILES="$CONFIG_FILES src/share/database/scripts/pgsql/wipe_data.sh" ;; "src/share/yang/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/yang/Makefile" ;; "src/share/yang/modules/Makefile") CONFIG_FILES="$CONFIG_FILES src/share/yang/modules/Makefile" ;; @@ -27290,7 +27092,6 @@ _LT_EOF ;; "src/bin/admin/kea-admin":F) chmod +x src/bin/admin/kea-admin ;; - "src/bin/admin/tests/cql_tests.sh":F) chmod +x src/bin/admin/tests/cql_tests.sh ;; "src/bin/admin/tests/admin_tests.sh":F) chmod +x src/bin/admin/tests/admin_tests.sh ;; "src/bin/admin/tests/memfile_tests.sh":F) chmod +x src/bin/admin/tests/memfile_tests.sh ;; "src/bin/admin/tests/mysql_tests.sh":F) chmod +x src/bin/admin/tests/mysql_tests.sh ;; @@ -27320,11 +27121,6 @@ _LT_EOF "src/lib/testutils/dhcp_test_lib.sh":F) chmod +x src/lib/testutils/dhcp_test_lib.sh ;; "src/lib/testutils/xml_reporting_test_lib.sh":F) chmod +x src/lib/testutils/xml_reporting_test_lib.sh ;; "src/lib/util/python/gen_wiredata.py":F) chmod +x src/lib/util/python/gen_wiredata.py ;; - "src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh":F) chmod +x src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh ;; - "src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh":F) chmod +x src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh ;; - "src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh":F) chmod +x src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh ;; - "src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh":F) chmod +x src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh ;; - "src/share/database/scripts/cql/wipe_data.sh":F) chmod +x src/share/database/scripts/cql/wipe_data.sh ;; "src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh ;; "src/share/database/scripts/mysql/upgrade_002.0_to_003.0.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_002.0_to_003.0.sh ;; "src/share/database/scripts/mysql/upgrade_003.0_to_004.0.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_003.0_to_004.0.sh ;; @@ -27347,18 +27143,27 @@ _LT_EOF "src/share/database/scripts/mysql/upgrade_009.6_to_010.0.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_009.6_to_010.0.sh ;; "src/share/database/scripts/mysql/upgrade_010_to_011.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_010_to_011.sh ;; "src/share/database/scripts/mysql/upgrade_011_to_012.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_011_to_012.sh ;; + "src/share/database/scripts/mysql/upgrade_012_to_013.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_012_to_013.sh ;; + "src/share/database/scripts/mysql/upgrade_013_to_014.sh":F) chmod +x src/share/database/scripts/mysql/upgrade_013_to_014.sh ;; "src/share/database/scripts/mysql/wipe_data.sh":F) chmod +x src/share/database/scripts/mysql/wipe_data.sh ;; - "src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh ;; - "src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh ;; - "src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh ;; - "src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh ;; - "src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh ;; - "src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh ;; - "src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh ;; - "src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh ;; - "src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh ;; - "src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh ;; - "src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh ;; + "src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh ;; + "src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh ;; + "src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh ;; + "src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh ;; + "src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh ;; + "src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh ;; + "src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh ;; + "src/share/database/scripts/pgsql/upgrade_007_to_008.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_007_to_008.sh ;; + "src/share/database/scripts/pgsql/upgrade_008_to_009.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_008_to_009.sh ;; + "src/share/database/scripts/pgsql/upgrade_009_to_010.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_009_to_010.sh ;; + "src/share/database/scripts/pgsql/upgrade_010_to_011.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_010_to_011.sh ;; + "src/share/database/scripts/pgsql/upgrade_011_to_012.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_011_to_012.sh ;; + "src/share/database/scripts/pgsql/upgrade_012_to_013.sh":F) chmod +x src/share/database/scripts/pgsql/upgrade_012_to_013.sh ;; "src/share/database/scripts/pgsql/wipe_data.sh":F) chmod +x src/share/database/scripts/pgsql/wipe_data.sh ;; "src/share/yang/modules/utils/reinstall.sh":F) chmod +x src/share/yang/modules/utils/reinstall.sh ;; "tools/path_replacer.sh":F) chmod +x tools/path_replacer.sh ;; @@ -27558,22 +27363,6 @@ PostgreSQL: END fi -if test "$CQL_CPPFLAGS" != "" ; then -cat >> config.report << END - -Cassandra CQL (deprecated): - CQL_VERSION: ${CQL_VERSION} - CQL_CPPFLAGS: ${CQL_CPPFLAGS} - CQL_LIBS: ${CQL_LIBS} -END -else -cat >> config.report << END - -Cassandra CQL: - no -END -fi - if "${HAVE_SYSREPO}"; then cat >> config.report << END @@ -27627,25 +27416,6 @@ Google Test: END fi -if test "$enable_benchmark" != "no"; then -cat >> config.report << END - -Google Benchmark: - BENCHMARK_VERSION: ${BENCHMARK_VERSION} - BENCHMARK_CPPFLAGS: ${BENCHMARK_CPPFLAGS} - BENCHMARK_INCLUDES: ${BENCHMARK_INCLUDES} - BENCHMARK_LDFLAGS: ${BENCHMARK_LDFLAGS} - BENCHMARK_LDADD: ${BENCHMARK_LDADD} - BENCHMARK_SOURCE: ${BENCHMARK_SOURCE} -END -else -cat >> config.report << END - -Google Benchmark: - no -END -fi - if test "$FREERADIUS_INCLUDE" != ""; then cat >> config.report << END @@ -27670,7 +27440,6 @@ cat >> config.report << END Developer: Enable Debugging: $debug_enabled Google Tests: $enable_gtest - Google Benchmark: $enable_benchmark Valgrind: $found_valgrind C++ Code Coverage: $USE_LCOV Logger checks: $enable_logger_checks diff -pruN 2.0.2-3/configure.ac 2.2.0-1/configure.ac --- 2.0.2-3/configure.ac 2022-02-27 22:11:02.000000000 +0000 +++ 2.2.0-1/configure.ac 2022-07-26 06:08:05.000000000 +0000 @@ -6,7 +6,7 @@ AC_PREREQ([2.69]) # For released versions, this is in x.y.z format. # For GIT versions, this is x.y.z-git, where x.y.z denotes the next development # version that is worked on and that is to be released. -AC_INIT(kea,2.0.2, kea-dev@lists.isc.org) +AC_INIT(kea,2.2.0, kea-dev@lists.isc.org) AC_CONFIG_SRCDIR(README) # serial-tests is not available in automake version before 1.13, so @@ -339,7 +339,7 @@ esac werror_extras= AC_ARG_WITH(werror, - AS_HELP_STRING([--with-werror],[Compile using -Werror (default=no)]), + [AS_HELP_STRING([--with-werror],[Compile using -Werror (default=no)])], [ case "${withval}" in yes) with_werror=1 ;; @@ -639,19 +639,6 @@ fi # variables. AX_ISC_GTEST -enable_benchmark="no" -BENCHMARK_INCLUDES= - -AC_ARG_WITH([benchmark-source], - [AS_HELP_STRING([--with-benchmark-source=PATH], - [location of the benchmark source])], - [enable_benchmark="yes" ; BENCHMARK_SOURCE="$withval"]) - -AC_ARG_WITH([benchmark], - [AS_HELP_STRING([--with-benchmark=PATH], - [specify a path to benchmark header files (PATH/include) and library (PATH/lib)])], - [benchmark_path="$withval"; enable_benchmark="yes"], [benchmark_path="no"]) - # Sets up for use of botan unless openssl is specified # sets variables CRYPTO_* AX_CRYPTO @@ -665,8 +652,8 @@ defaultdirs="/usr /usr/local /usr/pkg /o # the software is not built with MySQL support enabled. mysql_config="no" AC_ARG_WITH([mysql], - AS_HELP_STRING([--with-mysql=PATH], - [path to the MySQL 'mysql_config' script (MySQL is used for the DHCP database)]), + [AS_HELP_STRING([--with-mysql[[=PATH]]], + [path to the MySQL 'mysql_config' script (MySQL is used for the DHCP database)])], [mysql_config="$withval"]) deprec_msg="no" @@ -745,8 +732,8 @@ AM_CONDITIONAL(HAVE_MYSQL, test "$MYSQL_ pg_config="no" AC_ARG_WITH([pgsql], - AS_HELP_STRING([--with-pgsql=PATH], - [path to the PostgreSQL 'pg_config' script]), + [AS_HELP_STRING([--with-pgsql[[=PATH]]], + [path to the PostgreSQL 'pg_config' script])], [pg_config="$withval"]) deprec_msg="no" @@ -815,76 +802,25 @@ fi # ... and at the shell level, so Makefile.am can take action depending on this. AM_CONDITIONAL(HAVE_PGSQL, test "$PG_CONFIG" != "") -# allow building kea programs with static link to cassandra cpp-driver. -AC_ARG_ENABLE([cql-static-lib], - [AS_HELP_STRING([--enable-cql-static-lib], - [build programs with cassandra cpp driver static library [[default=no]]])], - [enable_cql_static_lib=yes], [enable_cql_static_lib=no]) -AM_CONDITIONAL(USE_CQL_STATIC_LIB, test "$enable_cql_static_lib" = yes) -#AC_DEFINE USE_CQL_STATIC_LIB? (unused) - -cql_lib="cassandra" -if test "${enable_cql_static_lib}" = "yes" ; then - cql_lib="${cql_lib}_static" +# allow building kea programs with a PostgreSQL without OpenSSL. +AC_ARG_ENABLE([pgsql-ssl], + [AS_HELP_STRING([--enable-pgsql-ssl], + [enable OpenSSL support in PostgreSQL [default=yes]])], + [pgsql_ssl=$enableval], [pgsql_ssl=no], [pgsql_ssl=yes]) +if test "${pgsql_ssl}" = "yes"; then + AC_DEFINE([HAVE_PGSQL_SSL], [1], [PostgreSQL was built with OpenSSL support]) fi cql_config="no" AC_ARG_WITH([cql], - AS_HELP_STRING([--with-cql=PATH], - [path to pkg-config or the Cassandra CQL 'cql_config' script (deprecated)]), + [AS_HELP_STRING([--with-cql[[=PATH]]], + [path to pkg-config or the Cassandra CQL 'cql_config' script (deprecated)])], [cql_config="$withval"]) -if test "${cql_config}" = "yes" ; then - CQL_CONFIG="$PKG_CONFIG" -elif test "${cql_config}" != "no" ; then - CQL_CONFIG="${cql_config}" +if test "${cql_config}" != "no" ; then + AC_MSG_ERROR([$CQL_CONFIG Cassandra is no longer supported]) fi -if test "$CQL_CONFIG" != "" ; then - if test -d "$CQL_CONFIG" -o ! -x "$CQL_CONFIG" ; then - AC_MSG_ERROR([--with-cql should point to a pkg-config or cql_config program]) - fi - - $CQL_CONFIG --print-errors $cql_lib - if test $? -ne 0; then - AC_MSG_ERROR([$CQL_CONFIG $cql_lib failed]) - fi - - CQL_INCLUDEDIR=`$CQL_CONFIG --cflags-only-I $cql_lib` - CQL_CPPFLAGS=`$CQL_CONFIG --cflags-only-other $cql_lib` - CQL_LIBS=`$CQL_CONFIG --libs $cql_lib` - CQL_LIBS="$CQL_LIBS $CRYPTO_LIBS" - CQL_VERSION=`$CQL_CONFIG --modversion $cql_lib` - - CQL_CPPFLAGS="${CQL_CPPFLAGS} ${CQL_INCLUDEDIR}" - AC_SUBST(CQL_CPPFLAGS) - AC_SUBST(CQL_LIBS) - - # Check that a simple program using CQL functions can compile and link. - CPPFLAGS_SAVED="$CPPFLAGS" - LIBS_SAVED="$LIBS" - - CPPFLAGS="$CQL_CPPFLAGS $CPPFLAGS" - LIBS="$CQL_LIBS $LIBS" - - AC_LINK_IFELSE( - [AC_LANG_PROGRAM([#include ], - [CassCluster* cluster = cass_cluster_new(); - cass_cluster_free(cluster);])], - [AC_MSG_RESULT([checking for Cassandra CQL headers and library... yes])], - [AC_MSG_RESULT([checking for Cassandra CQL headers and library... no]) - AC_MSG_ERROR([Needs Cassandra CQL library])] - ) - CPPFLAGS=$CPPFLAGS_SAVED - LIBS=$LIBS_SAVED - - # Note that CQL is present in the config.h file - AC_DEFINE([HAVE_CQL], [1], [CQL is present]) -fi - -# ... and at the shell level, so Makefile.am can take action depending on this. -AM_CONDITIONAL(HAVE_CQL, test "$CQL_CONFIG" != "") - # Check for sysrepo. AX_SYSREPO @@ -1009,98 +945,6 @@ AC_CHECK_LIB(pthread, pthread_create,[ L AX_TLS # -# Check availability of benchmark. -# -BENCHMARK_CPPFLAGS= -BENCHMARK_LDFLAGS= -BENCHMARK_LDADD= -DISTCHECK_BENCHMARK_CONFIGURE_FLAG= -BENCHMARK_VERSION="unknown" - -if test "x$enable_benchmark" = "xyes" ; then - - DISTCHECK_BENCHMARK_CONFIGURE_FLAG="--with-benchmark=$benchmark_path" - - if test -n "$with_benchmark_source" ; then - - if test "x$BENCHMARK_SOURCE" = "xyes" ; then - - AC_MSG_CHECKING([for benchmark source]) - # If not specified, try some common paths. - BENCHMARK_SOURCE= - for d in /usr/src/benchmark /usr/local /usr/pkg /opt /opt/local ; do - if test -f $d/src/benchmark.cc; then - BENCHMARK_SOURCE=$d - AC_MSG_RESULT([$BENCHMARK_SOURCE]) - break - fi - done - if test -z $BENCHMARK_SOURCE ; then - AC_MSG_ERROR([no benchmark source but it was selected]) - fi - else - if test ! -d $BENCHMARK_SOURCE/src; then - BENCHMARK_SOURCE=$BENCHMARK_SOURCE/benchmark - fi - if test -f $BENCHMARK_SOURCE/src/benchmark.cc; then - have_benchmark_source=yes - else - AC_MSG_ERROR([no benchmark source at $BENCHMARK_SOURCE]) - fi - fi - have_benchmark_source=yes - BENCHMARK_CPPFLAGS=`cat \${BENCHMARK_SOURCE}/build/src/CMakeFiles/benchmark.dir/flags.make | grep CXX_DEFINES | cut -d "=" -f 2` - BENCHMARK_LDADD="\$(BENCHMARK_SOURCE)/build/src/libbenchmark.a" - DISTCHECK_BENCHMARK_CONFIGURE_FLAG="--with-benchmark-source=$BENCHMARK_SOURCE" - BENCHMARK_INCLUDES="-I$BENCHMARK_SOURCE \ - -I$BENCHMARK_SOURCE/src \ - -I$BENCHMARK_SOURCE/include \ - -I$BENCHMARK_SOURCE/include/benchmark" - BENCHMARK_VERSION="$(basename $BENCHMARK_SOURCE)" - fi - - if test "$benchmark_path" != "no" ; then - if test "$benchmark_path" != "yes"; then - BENCHMARK_PATHS=$benchmark_path - fi - if test -z "${BENCHMARK_PATHS}" ; then - BENCHMARK_PATHS="/usr /usr/local" - fi - BENCHMARK_FOUND="false" - for dir in ${BENCHMARK_PATHS}; do - if test -f "$dir/include/benchmark/benchmark.h"; then - if ! test -f "$dir/lib/libbenchmark.a"; then - AC_MSG_WARN([Found Google Benchmark include but not the library in $dir.]) - continue - fi - BENCHMARK_INCLUDES="-I$dir/include" - BENCHMARK_LDFLAGS="-L$dir/lib" - BENCHMARK_LDADD="$dir/lib/libbenchmark.a " - BENCHMARK_FOUND="true" - break - fi - done - if test "${BENCHMARK_FOUND}" != "true"; then - AC_MSG_ERROR([Cannot find benchmark in: $BENCHMARK_PATHS]) - fi - - fi - - if test $enable_gtest = no; then - AC_MSG_ERROR([--with-benchmark and --with-benchmark-source require --with-gtest or --with-gtest-source]) - fi - -fi -AM_CONDITIONAL(HAVE_BENCHMARK, test $enable_benchmark != "no") -AM_CONDITIONAL(HAVE_BENCHMARK_SOURCE, test "X$have_benchmark_source" = "Xyes") -AC_SUBST(DISTCHECK_BENCHMARK_CONFIGURE_FLAG) -AC_SUBST(BENCHMARK_CPPFLAGS) -AC_SUBST(BENCHMARK_INCLUDES) -AC_SUBST(BENCHMARK_LDFLAGS) -AC_SUBST(BENCHMARK_LDADD) -AC_SUBST(BENCHMARK_SOURCE) - -# # Some Googletest versions bug with C++11 compilers # if test $enable_gtest != "no"; then @@ -1283,8 +1127,8 @@ if test "x$enable_shell" != xno -o "x$en AM_PATH_PYTHON([2.7]) AC_ARG_WITH(site-packages, - AS_HELP_STRING([--with-site-packages], - [place to install Kea Python module]), + [AS_HELP_STRING([--with-site-packages], + [place to install Kea Python module])], [pythondir=$withval; pkgpythondir=${pythondir}/$PACKAGE_NAME]) if test "$pythondir" = "yes"; then @@ -1337,11 +1181,11 @@ fi AM_CONDITIONAL(CA_TLS_TEST, test x$ca_tls_test != xno) AC_ARG_WITH([sphinx], - AS_HELP_STRING([--with-sphinx=PATH],[path to sphinx-build tool]), + [AS_HELP_STRING([--with-sphinx=PATH],[path to sphinx-build tool])], [sphinx_path="$withval"]) AC_ARG_WITH([pdflatex], - AS_HELP_STRING([--with-pdflatex=PATH],[path to pdflatex tool]), + [AS_HELP_STRING([--with-pdflatex=PATH],[path to pdflatex tool])], [pdflatex_path="$withval"]) PDFLATEX=no @@ -1545,8 +1389,6 @@ AC_CONFIG_FILES([src/bin/admin/Makefile] AC_CONFIG_FILES([src/bin/admin/kea-admin], [chmod +x src/bin/admin/kea-admin]) AC_CONFIG_FILES([src/bin/admin/tests/Makefile]) -AC_CONFIG_FILES([src/bin/admin/tests/cql_tests.sh], - [chmod +x src/bin/admin/tests/cql_tests.sh]) AC_CONFIG_FILES([src/bin/admin/tests/data/Makefile]) AC_CONFIG_FILES([src/bin/admin/tests/admin_tests.sh], [chmod +x src/bin/admin/tests/admin_tests.sh]) @@ -1629,6 +1471,8 @@ AC_CONFIG_FILES([src/hooks/dhcp/lease_cm AC_CONFIG_FILES([src/hooks/dhcp/lease_cmds/tests/Makefile]) AC_CONFIG_FILES([src/hooks/dhcp/mysql_cb/Makefile]) AC_CONFIG_FILES([src/hooks/dhcp/mysql_cb/tests/Makefile]) +AC_CONFIG_FILES([src/hooks/dhcp/pgsql_cb/Makefile]) +AC_CONFIG_FILES([src/hooks/dhcp/pgsql_cb/tests/Makefile]) AC_CONFIG_FILES([src/hooks/dhcp/run_script/Makefile]) AC_CONFIG_FILES([src/hooks/dhcp/run_script/libloadtests/Makefile]) AC_CONFIG_FILES([src/hooks/dhcp/run_script/tests/Makefile]) @@ -1670,7 +1514,6 @@ AC_CONFIG_FILES([src/lib/dhcp/tests/Make AC_CONFIG_FILES([src/lib/dhcp_ddns/Makefile]) AC_CONFIG_FILES([src/lib/dhcp_ddns/tests/Makefile]) AC_CONFIG_FILES([src/lib/dhcpsrv/Makefile]) -AC_CONFIG_FILES([src/lib/dhcpsrv/benchmarks/Makefile]) AC_CONFIG_FILES([src/lib/dhcpsrv/tests/Makefile]) AC_CONFIG_FILES([src/lib/dhcpsrv/tests/test_libraries.h]) AC_CONFIG_FILES([src/lib/dhcpsrv/testutils/Makefile]) @@ -1715,9 +1558,6 @@ AC_CONFIG_FILES([src/lib/mysql/tests/Mak AC_CONFIG_FILES([src/lib/pgsql/Makefile]) AC_CONFIG_FILES([src/lib/pgsql/tests/Makefile]) AC_CONFIG_FILES([src/lib/pgsql/testutils/Makefile]) -AC_CONFIG_FILES([src/lib/cql/Makefile]) -AC_CONFIG_FILES([src/lib/cql/tests/Makefile]) -AC_CONFIG_FILES([src/lib/cql/testutils/Makefile]) AC_CONFIG_FILES([src/lib/process/Makefile]) AC_CONFIG_FILES([src/lib/process/tests/Makefile]) AC_CONFIG_FILES([src/lib/process/testutils/Makefile]) @@ -1744,17 +1584,6 @@ AC_CONFIG_FILES([src/share/Makefile]) AC_CONFIG_FILES([src/share/api/Makefile]) AC_CONFIG_FILES([src/share/database/Makefile]) AC_CONFIG_FILES([src/share/database/scripts/Makefile]) -AC_CONFIG_FILES([src/share/database/scripts/cql/Makefile]) -AC_CONFIG_FILES([src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh], - [chmod +x src/share/database/scripts/cql/upgrade_1.0_to_2.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh], - [chmod +x src/share/database/scripts/cql/upgrade_2.0_to_3.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh], - [chmod +x src/share/database/scripts/cql/upgrade_3.0_to_4.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh], - [chmod +x src/share/database/scripts/cql/upgrade_4.0_to_5.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/cql/wipe_data.sh], - [chmod +x src/share/database/scripts/cql/wipe_data.sh]) AC_CONFIG_FILES([src/share/database/scripts/mysql/Makefile]) AC_CONFIG_FILES([src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh], [chmod +x src/share/database/scripts/mysql/upgrade_001.0_to_002.0.sh]) @@ -1800,31 +1629,49 @@ AC_CONFIG_FILES([src/share/database/scri [chmod +x src/share/database/scripts/mysql/upgrade_010_to_011.sh]) AC_CONFIG_FILES([src/share/database/scripts/mysql/upgrade_011_to_012.sh], [chmod +x src/share/database/scripts/mysql/upgrade_011_to_012.sh]) +AC_CONFIG_FILES([src/share/database/scripts/mysql/upgrade_012_to_013.sh], + [chmod +x src/share/database/scripts/mysql/upgrade_012_to_013.sh]) +AC_CONFIG_FILES([src/share/database/scripts/mysql/upgrade_013_to_014.sh], + [chmod +x src/share/database/scripts/mysql/upgrade_013_to_014.sh]) AC_CONFIG_FILES([src/share/database/scripts/mysql/wipe_data.sh], [chmod +x src/share/database/scripts/mysql/wipe_data.sh]) AC_CONFIG_FILES([src/share/database/scripts/pgsql/Makefile]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_1.0_to_2.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_2.0_to_3.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_3.0_to_3.1.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_3.1_to_3.2.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_3.2_to_3.3.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_3.3_to_4.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_4.0_to_5.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_5.0_to_5.1.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_5.1_to_6.0.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_6.0_to_6.1.sh]) -AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh], - [chmod +x src/share/database/scripts/pgsql/upgrade_6.1_to_6.2.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_001.0_to_002.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_002.0_to_003.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_003.0_to_003.1.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_003.1_to_003.2.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_003.2_to_003.3.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_003.3_to_004.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_004.0_to_005.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_005.0_to_005.1.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_005.1_to_006.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_006.0_to_006.1.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_006.1_to_006.2.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_006.2_to_007.0.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_007_to_008.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_007_to_008.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_008_to_009.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_008_to_009.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_009_to_010.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_009_to_010.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_010_to_011.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_010_to_011.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_011_to_012.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_011_to_012.sh]) +AC_CONFIG_FILES([src/share/database/scripts/pgsql/upgrade_012_to_013.sh], + [chmod +x src/share/database/scripts/pgsql/upgrade_012_to_013.sh]) AC_CONFIG_FILES([src/share/database/scripts/pgsql/wipe_data.sh], [chmod +x src/share/database/scripts/pgsql/wipe_data.sh]) AC_CONFIG_FILES([src/share/yang/Makefile]) @@ -1999,22 +1846,6 @@ PostgreSQL: END fi -if test "$CQL_CPPFLAGS" != "" ; then -cat >> config.report << END - -Cassandra CQL (deprecated): - CQL_VERSION: ${CQL_VERSION} - CQL_CPPFLAGS: ${CQL_CPPFLAGS} - CQL_LIBS: ${CQL_LIBS} -END -else -cat >> config.report << END - -Cassandra CQL: - no -END -fi - if "${HAVE_SYSREPO}"; then cat >> config.report << END @@ -2068,25 +1899,6 @@ Google Test: END fi -if test "$enable_benchmark" != "no"; then -cat >> config.report << END - -Google Benchmark: - BENCHMARK_VERSION: ${BENCHMARK_VERSION} - BENCHMARK_CPPFLAGS: ${BENCHMARK_CPPFLAGS} - BENCHMARK_INCLUDES: ${BENCHMARK_INCLUDES} - BENCHMARK_LDFLAGS: ${BENCHMARK_LDFLAGS} - BENCHMARK_LDADD: ${BENCHMARK_LDADD} - BENCHMARK_SOURCE: ${BENCHMARK_SOURCE} -END -else -cat >> config.report << END - -Google Benchmark: - no -END -fi - if test "$FREERADIUS_INCLUDE" != ""; then cat >> config.report << END @@ -2111,7 +1923,6 @@ cat >> config.report << END Developer: Enable Debugging: $debug_enabled Google Tests: $enable_gtest - Google Benchmark: $enable_benchmark Valgrind: $found_valgrind C++ Code Coverage: $USE_LCOV Logger checks: $enable_logger_checks diff -pruN 2.0.2-3/CONTRIBUTING.md 2.2.0-1/CONTRIBUTING.md --- 2.0.2-3/CONTRIBUTING.md 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/CONTRIBUTING.md 2022-07-26 06:08:02.000000000 +0000 @@ -175,9 +175,9 @@ such long periods, code tends to be refa some other change or by the code that hasn't been written yet. See Building Kea with Unit Tests for instructions on how to run unit-tests. If you happen to touch -any database related code, make sure you compile your code with –with-mysql, –with-pgsql and/or -–with-cql as needed. For example, if you change something substantial, make sure the other -compilation options still work. +any database related code, make sure you compile your code with –with-mysql and/or –with-pgsql as +needed. For example, if you change something substantial, make sure the other compilation options +still work. If you happen to add new files or have modified any Makefile.am files, it is also a good idea to check if you haven't broken the distribution process: @@ -192,8 +192,8 @@ enable various additional consistency ch you happen to modify anything in the documentation, use `–-enable-generate-docs`. If you are modifying DHCP code, you are likely to be interested in enabling a non-default database backends for DHCP. Note that if the backend is not enabled, the database-specific unit-tests are skipped. To -enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use `–with-pgsql` and for -Cassandra use `--with-cql`. A complete list of all switches can be obtained with the command: +enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use `–with-pgsql`. +A complete list of all switches can be obtained with the command: ```bash ./configure --help diff -pruN 2.0.2-3/COPYING 2.2.0-1/COPYING --- 2.0.2-3/COPYING 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/COPYING 2022-07-26 06:08:02.000000000 +0000 @@ -5,18 +5,6 @@ License, v. 2.0. If a copy of the MPL wa file, You can obtain one at http://mozilla.org/MPL/2.0/. Full text is also included below. ------------------------------------------------------------------------------ - -The Cassandra backend code and support for Google benchmark is distributed under -the Apache License, Version 2.0. The text is available at -http://www.apache.org/licenses/LICENSE-2.0. Full text is also included below in -this file. Both features are optional and are disabled by default. - ------------------------------------------------------------------------------ - -For your convenience, full text of MPL 2.0 and Apache 2.0 licenses is available -below: - --- MPL 2.0 license --------------------------------------------------------- Mozilla Public License Version 2.0 @@ -395,212 +383,6 @@ Exhibit B - "Incompatible With Secondary ---end of MPL 2.0 license --------------------------------------------------- ---- Apache 2.0 license ------------------------------------------------------ - - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. - - END OF TERMS AND CONDITIONS - - APPENDIX: How to apply the Apache License to your work. - - To apply the Apache License to your work, attach the following - boilerplate notice, with the fields enclosed by brackets "[]" - replaced with your own identifying information. (Don't include - the brackets!) The text should be enclosed in the appropriate - comment syntax for the file format. We also recommend that a - file or class name and description of purpose be included on the - same "printed page" as the copyright notice for easier - identification within third-party archives. - - Copyright [yyyy] [name of copyright owner] - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - ---- end of Apache 2.0 license ----------------------------------------------- - The ext/coroutine code is externally maintained and distributed under the Boost Software License, Version 1.0. (See its accompanying file LICENSE_1_0.txt.) diff -pruN 2.0.2-3/debian/changelog 2.2.0-1/debian/changelog --- 2.0.2-3/debian/changelog 2022-07-20 16:03:19.000000000 +0000 +++ 2.2.0-1/debian/changelog 2022-08-02 12:16:45.000000000 +0000 @@ -1,3 +1,25 @@ +isc-kea (2.2.0-1) unstable; urgency=medium + + * New upstream version 2.2.0. + Thanks to Daniel Baumann (Closes: #1016109) + * debian/patches: + - 0002-kea_admin_fix.patch: refresh patch + - 0007-keyctrl-colored-ddns-status.patch: drop patch (fixed upstream) + - 0009-disable-database-tests.patch: refresh patch + - 0010-build-libco-when-gtest-is-not-enabled: drop patch (fixed upstream) + - 0011-sphinx-set-language.patch: drop patch (fixed upstream) + * d/kea-doc.doc-base: register documentation to doc-base + * Lintian overrides: + - *.lintian-overrides: adapt to "pointed hints" syntax + - kea-admin.l-o: bash-term-in-posix-shell (false positives) + - d/kea-doc.l-o: add overrides for sphinx installed fonts. + + font-in-non-font-package [usr/share/doc/kea/html/_static/fonts/*] + + font-outside-font-dir [usr/share/doc/kea/html/_static/fonts/*] + * d/copyright: remove file patterns made unnecessary by new release + * d/salsa-ci.yml: add salsa CI + + -- Paride Legovini Tue, 02 Aug 2022 12:16:45 +0000 + isc-kea (2.0.2-3) unstable; urgency=medium * d/rules: configure: specify the Python site packages location. diff -pruN 2.0.2-3/debian/copyright 2.2.0-1/debian/copyright --- 2.0.2-3/debian/copyright 2022-07-16 14:46:24.000000000 +0000 +++ 2.2.0-1/debian/copyright 2022-07-31 22:32:30.000000000 +0000 @@ -11,18 +11,6 @@ Copyright: 2016-2018, Adam Majer -Last-Update: 2022-01-25 - ---- a/src/bin/keactrl/keactrl.in -+++ b/src/bin/keactrl/keactrl.in -@@ -541,7 +541,7 @@ - d2_status=$inactive - check_running "$(basename -- "${dhcp_ddns_srv}")" - if [ "${_running}" -eq 1 ]; then -- d2_status="active" -+ d2_status="$active" - fi - printf "DHCP DDNS: %b\n" "${d2_status}" - diff -pruN 2.0.2-3/debian/patches/0009-disable-database-tests.patch 2.2.0-1/debian/patches/0009-disable-database-tests.patch --- 2.0.2-3/debian/patches/0009-disable-database-tests.patch 2022-07-16 14:46:24.000000000 +0000 +++ 2.2.0-1/debian/patches/0009-disable-database-tests.patch 2022-07-31 22:32:30.000000000 +0000 @@ -13,7 +13,7 @@ Last-Update: 2020-12-03 +echo "SKIPPING MYSQL TEST" +exit 0 - # Copyright (C) 2014-2021 Internet Systems Consortium, Inc. ("ISC") + # Copyright (C) 2014-2022 Internet Systems Consortium, Inc. ("ISC") # --- a/src/bin/admin/tests/pgsql_tests.sh.in +++ b/src/bin/admin/tests/pgsql_tests.sh.in @@ -22,5 +22,5 @@ Last-Update: 2020-12-03 +echo "SKIPPING POSTGRESQL TEST" +exit 0 - # Copyright (C) 2015-2021 Internet Systems Consortium, Inc. ("ISC") + # Copyright (C) 2015-2022 Internet Systems Consortium, Inc. ("ISC") # diff -pruN 2.0.2-3/debian/patches/0010-build-libco-when-gtest-is-not-enabled.patch 2.2.0-1/debian/patches/0010-build-libco-when-gtest-is-not-enabled.patch --- 2.0.2-3/debian/patches/0010-build-libco-when-gtest-is-not-enabled.patch 2022-07-16 14:46:24.000000000 +0000 +++ 2.2.0-1/debian/patches/0010-build-libco-when-gtest-is-not-enabled.patch 1970-01-01 00:00:00.000000000 +0000 @@ -1,147 +0,0 @@ -From: Andrei Pavel -Subject: [PATCH] [#2167] build libco when gtest is not enabled -Origin: backport, https://gitlab.isc.org/isc-projects/kea/-/commit/6b6620aabdd6c4997a6c5ccb0011a9d938409b3f -Bug: https://gitlab.isc.org/isc-projects/kea/-/issues/2167 -Last-Update: 2022-01-12 - -diff --git a/src/bin/agent/tests/Makefile.am b/src/bin/agent/tests/Makefile.am -index 1bc1681..0a77ff8 100644 ---- a/src/bin/agent/tests/Makefile.am -+++ b/src/bin/agent/tests/Makefile.am -@@ -15,7 +15,10 @@ TESTS = $(SHTESTS) - - # As with every file generated by ./configure, clean them up when running - # "make distclean", but not on "make clean". --DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES += test_basic_auth_libraries.h -+DISTCLEANFILES += test_callout_libraries.h -+DISTCLEANFILES += test_data_files_config.h - - # Don't install shell tests. - noinst_SCRIPTS = $(SHTESTS) -@@ -105,12 +108,6 @@ nodist_ca_unittests_SOURCES += test_callout_libraries.h - # Run C++ tests on "make check". - TESTS += $(PROGRAM_TESTS) - --# As with every file generated by ./configure, clean them up when running --# "make distclean", but not on "make clean". --DISTCLEANFILES += test_basic_auth_libraries.h --DISTCLEANFILES += test_callout_libraries.h --DISTCLEANFILES += test_data_files_config.h -- - # Don't install test libraries. - noinst_LTLIBRARIES = libcallout.la libbasicauth.la - -diff --git a/src/bin/dhcp4/tests/Makefile.am b/src/bin/dhcp4/tests/Makefile.am -index a4aedbc..cba5c96 100644 ---- a/src/bin/dhcp4/tests/Makefile.am -+++ b/src/bin/dhcp4/tests/Makefile.am -@@ -15,16 +15,14 @@ TESTS = $(SHTESTS) - - # As with every file generated by ./configure, clean them up when running - # "make distclean", but not on "make clean". --DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES += marker_file.h -+DISTCLEANFILES += test_data_files_config.h -+DISTCLEANFILES += test_libraries.h - - # Don't install tests. - noinst_SCRIPTS = $(SHTESTS) - --if HAVE_GTEST -- --# C++ tests --PROGRAM_TESTS = dhcp4_unittests -- - AM_CPPFLAGS = -I$(top_srcdir)/src/lib -I$(top_builddir)/src/lib - AM_CPPFLAGS += -I$(top_srcdir)/src -I$(top_builddir)/src - AM_CPPFLAGS += -I$(top_srcdir)/src/bin -I$(top_builddir)/src/bin -@@ -72,6 +70,14 @@ libco3_la_CXXFLAGS = $(AM_CXXFLAGS) - libco3_la_CPPFLAGS = $(AM_CPPFLAGS) - libco3_la_LDFLAGS = -avoid-version -export-dynamic -module -rpath /nowhere - -+# Don't install test libraries. -+noinst_LTLIBRARIES = libco1.la libco2.la libco3.la -+ -+if HAVE_GTEST -+ -+# C++ tests -+PROGRAM_TESTS = dhcp4_unittests -+ - dhcp4_unittests_SOURCES = d2_unittest.h d2_unittest.cc - dhcp4_unittests_SOURCES += dhcp4_unittests.cc - dhcp4_unittests_SOURCES += dhcp4_srv_unittest.cc -@@ -163,15 +169,6 @@ dhcp4_unittests_LDADD += $(BOOST_LIBS) $(GTEST_LDADD) - # Run C++ tests on "make check". - TESTS += $(PROGRAM_TESTS) - --# As with every file generated by ./configure, clean them up when running --# "make distclean", but not on "make clean". --DISTCLEANFILES += marker_file.h --DISTCLEANFILES += test_data_files_config.h --DISTCLEANFILES += test_libraries.h -- --# Don't install test libraries. --noinst_LTLIBRARIES = libco1.la libco2.la libco3.la -- - # Don't install C++ tests. - noinst_PROGRAMS = $(PROGRAM_TESTS) - -diff --git a/src/bin/dhcp6/tests/Makefile.am b/src/bin/dhcp6/tests/Makefile.am -index 9c39eda..bb07e73 100644 ---- a/src/bin/dhcp6/tests/Makefile.am -+++ b/src/bin/dhcp6/tests/Makefile.am -@@ -15,16 +15,14 @@ TESTS = $(SHTESTS) - - # As with every file generated by ./configure, clean them up when running - # "make distclean", but not on "make clean". --DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES = $(SHTESTS) -+DISTCLEANFILES += marker_file.h -+DISTCLEANFILES += test_data_files_config.h -+DISTCLEANFILES += test_libraries.h - - # Don't install shell tests. - noinst_SCRIPTS = $(SHTESTS) - --if HAVE_GTEST -- --# C++ tests --PROGRAM_TESTS = dhcp6_unittests -- - AM_CPPFLAGS = -I$(top_srcdir)/src/lib -I$(top_builddir)/src/lib - AM_CPPFLAGS += -I$(top_srcdir)/src/bin -I$(top_builddir)/src/bin - AM_CPPFLAGS += -I$(top_srcdir)/src -I$(top_builddir)/src -@@ -73,6 +71,14 @@ libco3_la_CXXFLAGS = $(AM_CXXFLAGS) - libco3_la_CPPFLAGS = $(AM_CPPFLAGS) - libco3_la_LDFLAGS = -avoid-version -export-dynamic -module -rpath /nowhere - -+# Don't install test libraries. -+noinst_LTLIBRARIES = libco1.la libco2.la libco3.la -+ -+if HAVE_GTEST -+ -+# C++ tests -+PROGRAM_TESTS = dhcp6_unittests -+ - # This list is ordered alphabetically. When adding new files, please maintain - # this order. - dhcp6_unittests_SOURCES = classify_unittests.cc -@@ -163,15 +169,6 @@ dhcp6_unittests_LDADD += $(BOOST_LIBS) $(GTEST_LDADD) - # Run C++ tests on "make check". - TESTS += $(PROGRAM_TESTS) - --# As with every file generated by ./configure, clean them up when running --# "make distclean", but not on "make clean". --DISTCLEANFILES += marker_file.h --DISTCLEANFILES += test_data_files_config.h --DISTCLEANFILES += test_libraries.h -- --# Don't install test libraries. --noinst_LTLIBRARIES = libco1.la libco2.la libco3.la -- - # Don't install C++ tests. - noinst_PROGRAMS = $(PROGRAM_TESTS) - diff -pruN 2.0.2-3/debian/patches/0011-sphinx-set-language.patch 2.2.0-1/debian/patches/0011-sphinx-set-language.patch --- 2.0.2-3/debian/patches/0011-sphinx-set-language.patch 2022-07-16 14:46:24.000000000 +0000 +++ 2.2.0-1/debian/patches/0011-sphinx-set-language.patch 1970-01-01 00:00:00.000000000 +0000 @@ -1,20 +0,0 @@ -Description: doc: sphinx: explicitly set the doc language - Needed for Sphinx 5.0 compatibility. -Author: Paride Legovini -Origin: vendor -Bug: https://gitlab.isc.org/isc-projects/kea/-/issues/2451 -Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013407 -Last-Update: 2022-06-26 ---- -This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ ---- a/doc/sphinx/conf.py -+++ b/doc/sphinx/conf.py -@@ -77,7 +77,7 @@ - # - # This is also used if you do content translation via gettext catalogs. - # Usually you set "language" from the command line for these cases. --language = None -+language = 'en' - - # List of patterns, relative to source directory, that match files and - # directories to ignore when looking for source files. diff -pruN 2.0.2-3/debian/patches/series 2.2.0-1/debian/patches/series --- 2.0.2-3/debian/patches/series 2022-07-20 16:00:59.000000000 +0000 +++ 2.2.0-1/debian/patches/series 2022-07-31 22:32:30.000000000 +0000 @@ -1,6 +1,3 @@ 0001-support_kfreebsd.patch 0002-kea_admin_fix.patch -0007-keyctrl-colored-ddns-status.patch 0009-disable-database-tests.patch -0010-build-libco-when-gtest-is-not-enabled.patch -0011-sphinx-set-language.patch diff -pruN 2.0.2-3/debian/salsa-ci.yml 2.2.0-1/debian/salsa-ci.yml --- 2.0.2-3/debian/salsa-ci.yml 1970-01-01 00:00:00.000000000 +0000 +++ 2.2.0-1/debian/salsa-ci.yml 2022-08-01 23:07:11.000000000 +0000 @@ -0,0 +1,10 @@ +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml + +variables: + # We don't have autopkgtests for now, and the autodep8 auto-generated + # ones fail. Let's just disable the autopkgtest run. + SALSA_CI_DISABLE_AUTOPKGTEST: 1 + # The package isn't near to be reproducible. + SALSA_CI_DISABLE_REPROTEST: 1 diff -pruN 2.0.2-3/doc/devel/cross-compile.dox 2.2.0-1/doc/devel/cross-compile.dox --- 2.0.2-3/doc/devel/cross-compile.dox 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/devel/cross-compile.dox 2022-07-26 06:08:02.000000000 +0000 @@ -1,4 +1,4 @@ -// Copyright (C) 2020-2021 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2020-2022 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this @@ -102,7 +102,6 @@ a native (i.e. not cross-compiled) Kea b Required and optional Kea dependencies, usually available as packages: - Python (built-in) - - Cassandra (skipped here) - libssl-dev (built-in in the full image) - liblog4cplus-dev (in liblog4cplus package, load both the library and the development part) diff -pruN 2.0.2-3/doc/devel/Doxyfile 2.2.0-1/doc/devel/Doxyfile --- 2.0.2-3/doc/devel/Doxyfile 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/devel/Doxyfile 2022-07-26 06:08:02.000000000 +0000 @@ -873,7 +873,6 @@ INPUT = ../../src/bin/a ../../src/lib/cfgrpt \ ../../src/lib/config \ ../../src/lib/config_backend \ - ../../src/lib/cql \ ../../src/lib/cryptolink \ ../../src/lib/d2srv \ ../../src/lib/database \ @@ -881,7 +880,6 @@ INPUT = ../../src/bin/a ../../src/lib/dhcp_ddns \ ../../src/lib/dhcpsrv \ ../../src/lib/dhcpsrv/parsers \ - ../../src/lib/dhcpsrv/benchmarks \ ../../src/lib/dns \ ../../src/lib/eval \ ../../src/lib/exceptions \ diff -pruN 2.0.2-3/doc/devel/mainpage.dox 2.2.0-1/doc/devel/mainpage.dox --- 2.0.2-3/doc/devel/mainpage.dox 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/devel/mainpage.dox 2022-07-26 06:08:02.000000000 +0000 @@ -1,4 +1,4 @@ -// Copyright (C) 2012-2021 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2012-2022 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this @@ -45,7 +45,7 @@ * - @subpage writingShellScriptsAndTests * * @section performance Performance - * - @subpage benchmarks + * - @subpage perfdhcpInternals * * @section hooksFramework Hooks Framework * - @subpage hooksdgDevelopersGuide @@ -107,7 +107,6 @@ * - @subpage dhcpDatabaseBackends * - @subpage configBackend * - @subpage configBackendJSONDesign - * - @subpage perfdhcpInternals * * @section libraries Kea libraries * - @subpage libutil diff -pruN 2.0.2-3/doc/devel/Makefile.in 2.2.0-1/doc/devel/Makefile.in --- 2.0.2-3/doc/devel/Makefile.in 2022-02-27 22:11:11.000000000 +0000 +++ 2.2.0-1/doc/devel/Makefile.in 2022-07-26 06:08:14.000000000 +0000 @@ -141,11 +141,6 @@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ -BENCHMARK_CPPFLAGS = @BENCHMARK_CPPFLAGS@ -BENCHMARK_INCLUDES = @BENCHMARK_INCLUDES@ -BENCHMARK_LDADD = @BENCHMARK_LDADD@ -BENCHMARK_LDFLAGS = @BENCHMARK_LDFLAGS@ -BENCHMARK_SOURCE = @BENCHMARK_SOURCE@ BOOST_INCLUDES = @BOOST_INCLUDES@ BOOST_LIBS = @BOOST_LIBS@ BOTAN_TOOL = @BOTAN_TOOL@ @@ -155,8 +150,6 @@ CFLAGS = @CFLAGS@ CONTRIB_DIR = @CONTRIB_DIR@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ -CQL_CPPFLAGS = @CQL_CPPFLAGS@ -CQL_LIBS = @CQL_LIBS@ CRYPTO_CFLAGS = @CRYPTO_CFLAGS@ CRYPTO_INCLUDES = @CRYPTO_INCLUDES@ CRYPTO_LDFLAGS = @CRYPTO_LDFLAGS@ @@ -170,7 +163,6 @@ CXXFLAGS = @CXXFLAGS@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ -DISTCHECK_BENCHMARK_CONFIGURE_FLAG = @DISTCHECK_BENCHMARK_CONFIGURE_FLAG@ DISTCHECK_BOOST_CONFIGURE_FLAG = @DISTCHECK_BOOST_CONFIGURE_FLAG@ DISTCHECK_CONTRIB_CONFIGURE_FLAG = @DISTCHECK_CONTRIB_CONFIGURE_FLAG@ DISTCHECK_CRYPTO_CONFIGURE_FLAG = @DISTCHECK_CRYPTO_CONFIGURE_FLAG@ diff -pruN 2.0.2-3/doc/devel/unit-tests.dox 2.2.0-1/doc/devel/unit-tests.dox --- 2.0.2-3/doc/devel/unit-tests.dox 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/devel/unit-tests.dox 2022-07-26 06:08:02.000000000 +0000 @@ -1,4 +1,4 @@ -// Copyright (C) 2015-2021 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2015-2022 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this @@ -64,6 +64,11 @@ The following environment variable can a expected are by default silent. If set, these unit tests display real and expected logs. +- KEA_MYSQL_HAVE_SSL - Specifies the SSL/TLS support status of MySQL. + When not set the corresponding MySQL global variable is read and + the environment of the unit test process is updated so usually this + variable is manually set only in order to enforce a particular status. + - KEA_PIDFILE_DIR - Specifies the directory which should be used for PID files as used by dhcp::Daemon or its derivatives. If not specified, the default is prefix/var/run/kea, where prefix defaults to @@ -169,13 +174,27 @@ anything e.g. `DEBUG=true`. `unset DEBUG @verbatim mysql> CREATE USER 'keatest'@'localhost' IDENTIFIED BY 'keatest'; mysql> CREATE USER 'keatest_readonly'@'localhost' IDENTIFIED BY 'keatest'; + mysql> CREATE USER 'keatest_secure'@'localhost' IDENTIFIED BY 'keatest'; + mysql> ALTER USER 'keatest_secure'@'localhost' REQUIRE X509; mysql>@endverbatim\n + Some old versions of MySQL do not support the REQUIRE keyword in ALTER + USER. Fortunately all versions support it in GRANT even if it is less secure + as the requirement will apply only to commands for the database instead + to all connections so all commands. And of course in production many + stronger requirements are available: X509 only requires the user to + present a certificate: you can specify which certificate by requiring + for instance a particular Subject Name, etc. -# Grant the created users permissions to access the keatest database (again, the apostrophes around the user names and localhost are required): @verbatim mysql> GRANT ALL ON keatest.* TO 'keatest'@'localhost'; mysql> GRANT SELECT ON keatest.* TO 'keatest_readonly'@'localhost'; + mysql> GRANT ALL ON keatest.* TO 'keatest_secure'@'localhost'; + mysql>@endverbatim\n + When the REQUIRE in ALTER USER is not supported change the last line by: + @verbatim + mysql> GRANT ALL ON keatest.* TO 'keatest_secure'@'localhost' REQUIRE X509; mysql>@endverbatim\n -# If you get You do not have the SUPER privilege and binary logging is enabled error message, you need to add: @@ -189,10 +208,63 @@ anything e.g. `DEBUG=true`. `unset DEBUG %@endverbatim The unit tests are run automatically when "make check" is executed (providing - that Kea has been build with the \c --with-mysql switch (see the installation + that Kea has been built with the \c --with-mysql switch (see the installation section in the Kea Administrator Reference Manual). + @subsection mysqlUnitTestsTLS MySQL Database with SSL/TLS + + Usually MySQL is compiled with SSL/TLS support using OpenSSL. + This is easy to verify using the: + +@verbatim +mysql> SHOW GLOBAL VARIABLES LIKE 'have_ssl'; +@endverbatim + + The variable is documented to have three possible values: + +- DISABLED: compiled with TLS support but it was not configured + +- YES: compiled with configured TLS support + +- NO: not compiled with TLS support + +The value of this MySQL global variable is reflected by the +KEA_MYSQL_HAVE_SSL environment variable. + +The keatest_secure user requires X509 so a client certificate. Of course +in production a stricter requirement should be used, in particular when +a client certificate should be bound to a particular user. + +MySQL unit tests reuse the asiolink library setup. This .my.cnf +configuration file works with MariaDB 10.6.4: + +@verbatim +[mysqld] +ssl_cert=/src/lib/asiolink/testutils/ca/kea-server.crt +ssl_key=/src/lib/asiolink/testutils/ca/kea-server.key +ssl_ca=/src/lib/asiolink/testutils/ca/kea-ca.crt + +[client-mariadb] +ssl_cert=/src/lib/asiolink/testutils/ca/kea-client.crt +ssl_key=/src/lib/asiolink/testutils/ca/kea-client.key +ssl_ca=/src/lib/asiolink/testutils/ca/kea-ca.crt +ssl-verify-server-cert +@endverbatim + +The last statement requires mutual authentication named two way in the +MariaDB documentation. For MySQL versions greater than 5.7.11 this +statement should be replaced by: + +@verbatim +[client] +... +ssl-mode=VERIFY_IDENTITY +@endverbatim + +On Debian some MySQL packages use GnuTLS instead OpenSSL to provide +the SSL/TLS support: this is known to not work with this proposed setup. + @subsection pgsqlUnitTestsPrerequisites PostgreSQL Database PostgreSQL set up differs from system to system. Please consult your @@ -331,29 +403,6 @@ local all postgres section in the Kea Administrator Reference Manual). - - @subsection cqlUnitTestsPrerequisites Cassandra database - - @todo: Describe steps necessary to set up Cassandra database suitable - for running unittests. - - It seems this was enough: - - -# Launch cassandra if not running (-f for foreground) - @verbatim - % cassandra -f - @endverbatim - - The tool is cqlsh: - - -# Run the tool - @verbatim - % cqlsh - Connected to Test Cluster at 127.0.0.1:9042. - [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4] - Use HELP for help. - cqlsh> @endverbatim\n - @section unitTestsKerberos Kerberos Configuration for Unit Tests The GSS-TSIG hook library uses the GSS-API with Kerberos. While there are diff -pruN 2.0.2-3/doc/examples/agent/https.json 2.2.0-1/doc/examples/agent/https.json --- 2.0.2-3/doc/examples/agent/https.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/agent/https.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,8 +4,7 @@ "Control-agent": { // We need to specify where the agent should listen to incoming HTTP - // queries. Note that agent does not provide SSL or TLS protection - // on its own, so limiting the traffic to localhost is a good idea. + // queries. "http-host": "127.0.0.1", // If enabling HA and multi-threading, the 8000 port is used by the HA diff -pruN 2.0.2-3/doc/examples/agent/rbac.json 2.2.0-1/doc/examples/agent/rbac.json --- 2.0.2-3/doc/examples/agent/rbac.json 1970-01-01 00:00:00.000000000 +0000 +++ 2.2.0-1/doc/examples/agent/rbac.json 2022-07-26 06:08:02.000000000 +0000 @@ -0,0 +1,90 @@ +// This is an example of a configuration for Control-Agent (CA) using +// the Role Based Access Control (RBAC) hook library. +{ + "Control-agent": + { + // We need to specify where the agent should listen to incoming HTTP + // queries. + "http-host": "127.0.0.1", + + // If enabling HA and multi-threading, the 8000 port is used by the HA + // hook library http listener. When using HA hook library with + // multi-threading to function, make sure the port used by dedicated + // listener is different (e.g. 8001) than the one used by CA. Note + // the commands should still be sent via CA. The dedicated listener + // is specifically for HA updates only. + "http-port": 8000, + + // TLS trust anchor (Certificate Authority). This is a file name or + // (for OpenSSL only) a directory path. + "trust-anchor": "my-ca", + + // TLS server certificate file name. + "cert-file": "my-cert", + + // TLS server private key file name. + "key-file": "my-key", + + // TLS require client certificates flag. Default is true and means + // require client certificates. False means they are optional. + "cert-required": true, + + // Add hooks here. + "hooks-libraries": [ + { + "library": "/opt/lib/libca_rbac.so", + "parameters": { + // This section configures the RBAC hook library. + // Mandatory parameters. + "assign-role-method": "cert-subject", + "api-files": "/opt/share/kea/api", + // Optional parameters. + "require-tls": true, + "commands": [ + { + "name": "my-command", + "access": "read", + "hook": "my-hook" + } ], + "access-control-lists": [ + { + "my-none": { "not": "ALL" } + },{ + "another-none": { "and": [ "ALL", "NONE" ] } + },{ + "my-read": { "access": "read" } + } ], + "roles": [ + { + "name": "kea-client", + "accept-commands": + { + "commands": [ "list-commands", "status-get" ] + }, + "reject-commands": "NONE", + "other-commands": "reject", + "list-match-first": "accept", + "response-filters": [ "list-commands" ] + },{ + "name": "admin", + "accept-commands": "ALL", + "reject-commands": + { + "hook": "cb_cmds" + }, + "list-match-first": "reject" + } ], + "default-role": + { + "accept-commands": "NONE", + "reject-commands": "ALL" + }, + "unknown-role": + { + "accept-commands": "READ", + "reject-commands": "WRITE" + } + } + } ] + } +} diff -pruN 2.0.2-3/doc/examples/agent/simple.json 2.2.0-1/doc/examples/agent/simple.json --- 2.0.2-3/doc/examples/agent/simple.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/agent/simple.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,8 +4,7 @@ "Control-agent": { // We need to specify where the agent should listen to incoming HTTP - // queries. Note that agent does not provide SSL or TLS protection - // on its own, so limiting the traffic to localhost is a good idea. + // queries. "http-host": "127.0.0.1", // If enabling HA and multi-threading, the 8000 port is used by the HA @@ -27,6 +26,10 @@ // Its default is "kea-control-agent". "realm": "kea-control-agent", + // This optional parameter can be used to specify a common + // prefix for files handling client credentials. + "directory": "/tmp/kea-creds", + // This list specifies the user ids and passwords to use for // basic HTTP authentication. If empty or not present any client // is authorized. @@ -42,6 +45,22 @@ // If password is not specified an empty password is used. "password": "1234" + }, + + // This specifies a hiddent client. + { + // The user id is the content of the file /tmp/kea-creds/hiddenu. + "user-file": "hiddenu", + + // The password is the content of the file /tmp/kea-creds/hiddenp. + "password-file": "hiddenp" + }, + + // This specifies a hidden client using a secret in a file. + { + // The secret is the content of the file /tmp/kea-creds/hiddens + // which must be in the : format. + "password-file": "hiddens" } ] }, diff -pruN 2.0.2-3/doc/examples/ddns/all-keys-netconf.json 2.2.0-1/doc/examples/ddns/all-keys-netconf.json --- 2.0.2-3/doc/examples/ddns/all-keys-netconf.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/ddns/all-keys-netconf.json 2022-07-26 06:08:02.000000000 +0000 @@ -68,7 +68,8 @@ // Name of the zone (required). "name": "example.com.", - // Name of the TSIG key used to protect DNS updates. + // Name of the TSIG key used to protect DNS updates for + // names in the domain. "key-name": "d2.md5.key", // List of DNS servers where to send DNS updates. @@ -78,7 +79,11 @@ "ip-address": "2001:db8:1::10", // DNS server UDP port. Default is 53 (DNS service). - "port": 7802 + "port": 7802, + + // Name of the TSIG key used to protect DNS updates + // sent to the DNS server. + "key-name": "d2.sha1.key" } ] } @@ -94,7 +99,8 @@ // Name of the zone (required). "name": "2.0.192.in-addr.arpa.", - // Name of the TSIG key used to protect DNS updates. + // Name of the TSIG key used to protect DNS updates for + // names in the domain. "key-name": "d2.sha1.key", // List of DNS servers where to send DNS updates. @@ -104,7 +110,10 @@ "ip-address": "172.16.1.1", // DNS server UDP port. Default is 53 (DNS service). - "port": 5301 + "port": 5301, + + // Name of the TSIG key used to protect DNS updates + "key-name": "d2.md5.key" } ] } diff -pruN 2.0.2-3/doc/examples/ddns/gss-tsig.json 2.2.0-1/doc/examples/ddns/gss-tsig.json --- 2.0.2-3/doc/examples/ddns/gss-tsig.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/ddns/gss-tsig.json 2022-07-26 06:08:02.000000000 +0000 @@ -56,7 +56,7 @@ ] }, - // Need to add gss-tsig hook here + // The GSS-TSIG hook is loaded and its configuration is specified here. "hooks-libraries": [ { "library": "/opt/lib/libddns_gss_tsig.so", @@ -69,8 +69,17 @@ "server-principal": "DNS/server.example.org@EXAMPLE.ORG", "client-principal": "DHCP/admin.example.org@EXAMPLE.ORG", - "client-keytab": "FILE:/etc/dhcp.keytab", // toplevel only - "credentials-cache": "FILE:/etc/ccache", // toplevel only + + // client-keytab and credentials-cache can both be used to + // store client keys. As credentials cache is more flexible, + // it is recommended to use it. Typically, using both at the + // same time may cause problems. + // + // "client-keytab": "FILE:/etc/dhcp.keytab", // toplevel only + "credentials-cache": "FILE:/etc/ccache", // toplevel only + + "gss-replay-flag": true, // GSS anti replay service + "gss-sequence-flag": false, // no GSS sequence service "tkey-lifetime": 3600, // 1 hour "rekey-interval": 2700, // 45 minutes "retry-interval": 120, // 2 minutes @@ -89,6 +98,8 @@ "port": 53, "server-principal": "DNS/server1.example.org@EXAMPLE.ORG", "client-principal": "DHCP/admin1.example.org@EXAMPLE.ORG", + "gss-replay-flag": false, // no GSS anti replay service + "gss-sequence-flag": false, // no GSS sequence service "tkey-lifetime": 7200, // 2 hours "rekey-interval": 5400, // 90 minutes "retry-interval": 240, // 4 minutes diff -pruN 2.0.2-3/doc/examples/kea4/advanced.json 2.2.0-1/doc/examples/kea4/advanced.json --- 2.0.2-3/doc/examples/kea4/advanced.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/advanced.json 2022-07-26 06:08:02.000000000 +0000 @@ -18,9 +18,9 @@ { "Dhcp4": { - // Kea is told to listen on ethX interface only. + // Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ], + "interfaces": [ "eth0" ], // This specifies what type of socket Kea uses. Currently supported // are 'raw' (which is the default) and 'udp'. Raw has the benefit @@ -73,8 +73,8 @@ } ], // We need to specify the database used to store leases. As of - // September 2016, four database backends are supported: MySQL, - // PostgreSQL, Cassandra, and the in-memory database, Memfile. + // June 2022, three database backends are supported: MySQL, + // PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // For memfile, it's important to always specify lfc-interval, so // the lease file would not grow without bounds and be sanitized diff -pruN 2.0.2-3/doc/examples/kea4/all-keys.json 2.2.0-1/doc/examples/kea4/all-keys.json --- 2.0.2-3/doc/examples/kea4/all-keys.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/all-keys.json 2022-07-26 06:08:02.000000000 +0000 @@ -298,78 +298,79 @@ "hosts-databases": [ { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 3306, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql", // User name to be used to access the database. - "user": "kea", + "user": "keatest", // Read only mode. - "readonly": false + "readonly": false, + + // Next entries are for the OpenSSL support in MySQL. + + // Trust anchor aka certificate authority file or directory. + "trust-anchor": "my-ca", + + // Client certificate file name. + "cert-file": "my-cert", + + // Private key file name. + "key-file": "my-key", + + // Cipher list (see the OpenSSL ciphers command manual). + "cipher-list": "AES" }, { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 5432, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "postgresql", // User name to be used to access the database. - "user": "kea" + "user": "keatest" }, { // Name of the database to connect to. - "keyspace": "kea", - - // Host on which the database resides. - "contact-points": "127.0.0.1", + "name": "keatest", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 9042, - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "cql", + // Type of the database, e.g. "mysql", "postgresql". + "type": "mysql", // User name to be used to access the database. - "user": "kea", - - // Consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "consistency": "quorum", - - // Serial consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "serial-consistency": "serial", + "user": "keatest", // Connection reconnect wait time. // This parameter governs how long Kea waits before attempting - // to reconnect. Expressed in milliseconds. The default is 2000 [ms] - // for Casandra and 0 (disabled) for MySQL and PostgreSQL. + // to reconnect. Expressed in milliseconds. The default is 0 + // (disabled) for MySQL and PostgreSQL. "reconnect-wait-time": 3000, // Connection maximum reconnect tries. @@ -381,16 +382,7 @@ "on-fail": "stop-retry-exit", // Connection connect timeout. - "connect-timeout": 100, - - // Connection request timeout. - "request-timeout": 100, - - // Connection tcp keepalive. - "tcp-keepalive": 100, - - // Connection tcp nodelay. - "tcp-nodelay": true + "connect-timeout": 100 } ], @@ -422,7 +414,7 @@ // Specifies a list of interfaces on which the Kea DHCPv4 // server should listen to the DHCP requests. "interfaces": [ - "ethX" + "eth0" ], // Enumeration which indicates what interface should be used @@ -438,9 +430,34 @@ // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. - "re-detect": true + "re-detect": true, + + // Kea tries to bind the service sockets during initialization. It may + // fail due to a port being already opened or misconfiguration. Kea can + // suppress these errors and only logs them. This flag prevents starting + // the DHCP server without binding all sockets. If unspecified, it + // defaults to false. + "service-sockets-require-all": true, + + // Kea tries to bind the service sockets during initialization. This + // option specifies how many times binding to interface will be retried. + // The default value is 0 which means that the operation will not be + // repeated. + "service-sockets-max-retries": 5, + + // The time interval in milliseconds to wait before the next attempt to + // retry opening a service socket. + "service-sockets-retry-wait-time": 5000 }, + // Boolean parameter which controls whether an early global host + // reservations lookup should be performed. This lookup takes place + // before subnet selection and when a global reservation is found + // with some client classes, it triggers a second phase classification. + // It can also be used to drop queries using host reservations as a + // decision table indexed by reservation identifiers. + "early-global-reservations-lookup": true, + // Boolean parameter which controls DHCP server's behavior with respect // to creating host reservations for the same IP address. By default // this flag is set to true in which case the server prevents creation @@ -457,6 +474,13 @@ // PostgreSQL backends do support this mode. "ip-reservations-unique": true, + /// Boolean parameter which controls whether host reservations lookup + /// should be performed before lease lookup. This parameter has effect + /// only when multi-threading is disabled. When multi-threading is + /// enabled, host reservations lookup is always performed first to avoid + /// lease lookup resource locking. + "reservations-lookup-first": true, + // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval @@ -481,8 +505,8 @@ // because non stored leases will be lost upon Kea server restart. "persist": true, - // Lease database backend type, i.e. "memfile", "mysql", - // "postgresql" or "cql". + // Lease database backend type, i.e. "memfile", "mysql" or + // "postgresql". "type": "memfile" }, @@ -681,7 +705,7 @@ // Specifies that this shared network is selected for the // requests received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Shared network level flag specifying whether the client // identifier should be used for identifying clients. @@ -770,7 +794,7 @@ "4o6-subnet": "2001:db8:1:1::/64", // Subnet level authoritative flag. - "authoritative": true, + "authoritative": false, // Subnet level bootfile name, set in 'file' field. "boot-file-name": "", @@ -815,7 +839,7 @@ // Specifies that this subnet is selected for the requests // received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Subnet level flag specifying whether the client identifier // should be used for identifying clients. @@ -1023,7 +1047,7 @@ // Name of the database to connect to. "name": "config", - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql" } ], diff -pruN 2.0.2-3/doc/examples/kea4/all-keys-netconf.json 2.2.0-1/doc/examples/kea4/all-keys-netconf.json --- 2.0.2-3/doc/examples/kea4/all-keys-netconf.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/all-keys-netconf.json 2022-07-26 06:08:02.000000000 +0000 @@ -11,6 +11,11 @@ { // Kea DHCPv4 server configuration begins here. "Dhcp4": { + + // Global authoritative flag to handle requests by clients for + // unknown IP addresses (ignore if disabled, NAK if enabled). + "authoritative": false, + // Global bootfile name to be set in the 'file' field. "boot-file-name": "/dev/null", @@ -40,7 +45,16 @@ // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. - "test": "member('HA_server1')" + "test": "member('HA_server1')", + + // Class valid lifetime. + "valid-lifetime": 6000, + + // Class min valid lifetime. + "min-valid-lifetime": 4000, + + // Class max valid lifetime. + "max-valid-lifetime": 8000 }, { // Default value of the class specific bootfile name. Empty name @@ -86,6 +100,14 @@ } ], + // Parameters for triggering behaviors compatible with broken or + // non-compliant clients, relays or other agents + "compatibility": { + // Parse options more leniently where fields can be deduced + // deterministically even if against RFC or common practice. + "lenient-option-parsing": true + }, + // Command control socket configuration parameters for Kea DHCPv4 server. "control-socket": { // Location of the unix domain socket file the DHCPv4 server uses @@ -98,6 +120,65 @@ "socket-type": "unix" }, + // Specifies a prefix to be prepended to the generated Client FQDN. + // It may be specified at the global, shared-network and subnet levels. + "ddns-generated-prefix": "myhost", + + // Boolean flag indicating that server should ignore DHCP client + // wishes to update DNS on its own. With that flag set to true + // the server will send DNS updates for both forward and + // reverse DNS data. The default value is false, which indicates + // that the server will delegate DNS update to the client when + // requested. It may be specified at the global, shared-network + // and subnet levels. + "ddns-override-client-update": false, + + // Boolean flag indicating that the server should override DHCP + // client's wish to not update the DNS. With this parameter + // set to true the server will send DNS update even when + // the client requested no update. It may be specified at the + // global, shared-network and subnet levels. + "ddns-override-no-update": false, + + // Suffix appended to the partial name sent to the DNS. The + // default value is an empty string which indicates that no + // suffix is appended. It may be specified at the global, + // shared-network and subnet levels. + "ddns-qualifying-suffix": "", + + // Enumeration specifying whether the server should honor + // hostname or Client FQDN sent by the client or replace + // this name. The acceptable values are: "never" (use the + // name the client sent), "always" (replace the name the + // client sent), "when-present" (replace the name the client + // sent, but do not generate one when the client didn't sent + // the name), "when-not-present" (generate the name when + // client didn't send one, otherwise leave the name the + // client sent). The default value is "never". It may be + // specified at the global, shared-network and subnet levels. + "ddns-replace-client-name": "never", + + // Boolean flag which enables or disables the DDNS updating. It + // defaults to true. It may be specified at the global, shared- + // network and subnet levels. It works in conjunction with + // dhcp-ddns:enable-updates which must be true to enable connectivity + // to kea-dhcp-ddns. + "ddns-send-updates": true, + + // Boolean flag, which when true instructs the server to always + // update DNS when leases are renewed, even if the DNS information + // has not changed. The server's default behavior (i.e. flag is false) + // is to only update DNS if the DNS information has changed. It + // may be specified at the global, shared-network and subnet levels. + "ddns-update-on-renew": true, + + // Boolean flag, which is passed to kea-dhcp-ddns with each DDNS + // update request to indicate whether or not DNS update conflict + // resolution as described in RFC 4703 should be employed for the + // given update request. The default value for this flag is true. + // It may be specified at the global, shared-network and subnet levels. + "ddns-use-conflict-resolution": true, + // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, @@ -106,23 +187,11 @@ // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { - // Boolean flag indicating if Kea DHCPv4 server must generate NCRs. - // By default NCRs are not generated. + // Boolean flag indicating if Kea DHCPv4 server should connect to + // kea-dhcp-ddns. This must be true for NCRs to be created and + // sent to kea-dhcp-ddns. By default NCRs are not generated. "enable-updates": false, - // Specifies a prefix to be prepended to the generated Client FQDN. - "generated-prefix": "myhost", - - // String of zero or more characters with which to replace each - // invalid character in the hostname or Client FQDN. The default - // value is an empty string which will cause invalid characters - // to be omitted rather than replaced. - "hostname-char-replacement": "x", - - // Regular expression describing the invalid character set in - // the hostname or Client FQDN. - "hostname-char-set": "[^A-Za-z0-9.-]", - // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, @@ -135,36 +204,6 @@ // only UDP is supported. "ncr-protocol": "UDP", - // Boolean flag indicating that server should ignore DHCP client - // wishes to update DNS on its own. With that flag set to true - // the server will send DNS updates for both forward and - // reverse DNS data. The default value is false, which indicates - // that the server will delegate DNS update to the client when - // requested. - "override-client-update": false, - - // Boolean flag indicating that the server should override DHCP - // client's wish to not update the DNS. With this parameter - // set to true the server will send DNS update even when - // the client requested no update. - "override-no-update": false, - - // Suffix appended to the partial name sent to the DNS. The - // default value is an empty string which indicates that no - // suffix is appended. - "qualifying-suffix": "", - - // Enumeration specifying whether the server should honor - // hostname or Client FQDN sent by the client or replace - // this name. The acceptable values are: "never" (use the - // name the client sent), "always" (replace the name the - // client sent), "when-present" (replace the name the client - // sent, but do not generate one when the client didn't sent - // the name), "when-not-present" (generate the name when - // client didn't send one, otherwise leave the name the - // client sent). The default value is "never". - "replace-client-name": "never", - // IP address that Kea DHCPv4 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. @@ -179,7 +218,20 @@ "server-ip": "127.0.0.1", // Port number on which D2 listens for NCRs. - "server-port": 53001 + "server-port": 53001, + + // The follow parameters are DEPRECATED. They have been + // replaced with parameters that may be set at the global, + // shared-network, and subnet4 scopes. They are listed here + // as configuration parsing still accepts them. Eventually + // support for them will be removed. + "generated-prefix": "myhost", + "hostname-char-replacement": "x", + "hostname-char-set": "[^A-Za-z0-9.-]", + "override-client-update": false, + "override-no-update": false, + "qualifying-suffix": "", + "replace-client-name": "never" }, // Specifies the first of the two consecutive ports of the UDP @@ -246,85 +298,75 @@ "hosts-databases": [ { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 3306, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql", // User name to be used to access the database. - "user": "kea" - }, - { - // Name of the database to connect to. - "name": "kea", + "user": "keatest", - // Host on which the database resides. - "host": "localhost", + // Read only mode. + "readonly": false, - // Database password. - "password": "kea", + // Next entries are for the OpenSSL support in MySQL. - // Port on which the database is available. - "port": 5432, + // Trust anchor aka certificate authority file or directory. + "trust-anchor": "my-ca", - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "postgresql", + // Client certificate file name. + "cert-file": "my-cert", - // User name to be used to access the database. - "user": "kea" + // Private key file name. + "key-file": "my-key", + + // Cipher list (see the OpenSSL ciphers command manual). + "cipher-list": "AES" }, { // Name of the database to connect to. - "keyspace": "kea", + "name": "keatest", // Host on which the database resides. - "contact-points": "127.0.0.1", + "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. - "port": 9042, + "port": 5432, - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "cql", + // Type of the database, e.g. "mysql", "postgresql". + "type": "postgresql", // User name to be used to access the database. - "user": "kea", - - // Consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "consistency": "quorum", - - // Serial consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "serial-consistency": "serial", + "user": "keatest", // Connection reconnect wait time. - "reconnect-wait-time": 100, + // This parameter governs how long Kea waits before attempting + // to reconnect. Expressed in milliseconds. The default is 0 + // (disabled) for MySQL and PostgreSQL. + "reconnect-wait-time": 3000, + + // Connection maximum reconnect tries. + "max-reconnect-tries": 3, + + // Action to take when connection recovery fails. + // Supported values: stop-retry-exit, serve-retry-exit, + // serve-retry-continue + "on-fail": "stop-retry-exit", // Connection connect timeout. - "connect-timeout": 100, - - // Connection request timeout. - "request-timeout": 100, - - // Connection tcp keepalive. - "tcp-keepalive": 100, - - // Connection tcp nodelay. - "tcp-nodelay": true + "connect-timeout": 100 } ], @@ -356,7 +398,7 @@ // Specifies a list of interfaces on which the Kea DHCPv4 // server should listen to the DHCP requests. "interfaces": [ - "ethX" + "eth0" ], // Enumeration which indicates what interface should be used @@ -372,9 +414,57 @@ // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. - "re-detect": true + "re-detect": true, + + // Kea tries to bind the service sockets during initialization. It may + // fail due to a port being already opened or misconfiguration. Kea can + // suppress these errors and only logs them. This flag prevents starting + // the DHCP server without binding all sockets. If unspecified, it + // defaults to false. + "service-sockets-require-all": true, + + // Kea tries to bind the service sockets during initialization. This + // option specifies how many times binding to interface will be retried. + // The default value is 0 which means that the operation will not be + // repeated. + "service-sockets-max-retries": 5, + + // The time interval in milliseconds to wait before the next attempt to + // retry opening a service socket. + "service-sockets-retry-wait-time": 5000 }, + // Boolean parameter which controls whether an early global host + // reservations lookup should be performed. This lookup takes place + // before subnet selection and when a global reservation is found + // with some client classes, it triggers a second phase classification. + // It can also be used to drop queries using host reservations as a + // decision table indexed by reservation identifiers. + "early-global-reservations-lookup": true, + + // Boolean parameter which controls DHCP server's behavior with respect + // to creating host reservations for the same IP address. By default + // this flag is set to true in which case the server prevents creation + // of multiple host reservations for the same IP address. When this + // parameter is set to false, the server allows for creating multiple + // reservations for the same IP address within a subnet. This setting + // is useful in deployments in which a given host may be communicating + // with a DHCP server over multiple interfaces and depending on the + // chosen interface different MAC address (or other identifier) will + // be used to identify the host. Note that some host backends do not + // support the mode in which multiple reservations for the same IP + // address are used. If these backends are in use and this setting + // is attempted a configuration error will occur. The MySQL and + // PostgreSQL backends do support this mode. + "ip-reservations-unique": true, + + /// Boolean parameter which controls whether host reservations lookup + /// should be performed before lease lookup. This parameter has effect + /// only when multi-threading is disabled. When multi-threading is + /// enabled, host reservations lookup is always performed first to avoid + /// lease lookup resource locking. + "reservations-lookup-first": true, + // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval @@ -399,8 +489,8 @@ // because non stored leases will be lost upon Kea server restart. "persist": true, - // Lease database backend type, i.e. "memfile", "mysql", - // "postgresql" or "cql". + // Lease database backend type, i.e. "memfile", "mysql" or + // "postgresql". "type": "memfile" }, @@ -419,6 +509,17 @@ // scopes. "next-server": "192.0.2.123", + // Global value which limits the number of client packets (e.g. + // DHCPREQUESTs) that may be parked while waiting for hook library + // work to complete, prior to a response (e.g. DHCPACK) being sent + // back to the client. A typical example is when kea-dhcp4 parks a + // DHCPREQUEST while it sends the lease update(s) to its HA peer(s). + // The packet is unparked once the update(s) have been acknowledged. + // This value limits the number of packets that can be held pending + // the updates. In times of heavy client traffic, this value can keep + // kea-dhcp4 from building an insurmountable backlog of updates. + "parked-packet-limit": 128, + // List of global DHCP options that Kea DHCPv4 server assigns to the // clients. "option-data": [ @@ -495,6 +596,37 @@ // DHCP client renews the lease. "renew-timer": 30, + // Global value to store extended information (e.g. relay agent + // information) with each lease. + "store-extended-info": true, + + // Statistics keep some samples per observation point. + // There are two default values: maximum count and maximum age. + // Set the maximum count to zero disables it. + "statistic-default-sample-count": 0, + + // When the maximum count is 0 the maximum age (in seconds) applies. + "statistic-default-sample-age": 60, + + // Multi-threading parameters. + "multi-threading": { + // By default Kea processes packets on a single thread (default + // 'false' value for this option). To enable multi-threading, this + // option can be set ('true' value). + "enable-multi-threading": false, + + // When multi-threading is enabled, Kea will process packets on a + // number of multiple threads configurable through this option. The + // value must be a positive integer (0 means auto detect). + "thread-pool-size": 0, + + // When multi-threading is enabled, Kea will read packets from the + // interface and append a working item to the thread pool. This + // option configures the maximum number of items that can be queued. + // The value must be a positive integer (0 means unlimited). + "packet-queue-size": 0 + }, + // Governs how the Kea DHCPv4 server should deal with the invalid // data received from the client. "sanity-checks": { @@ -514,6 +646,9 @@ // networks group subnets together. "shared-networks": [ { + // Shared network level authoritative flag. + "authoritative": false, + // Shared network level bootfile name. "boot-file-name": "/dev/null", @@ -522,9 +657,39 @@ // empty string is provided, no restriction is applied. "client-class": "", + // Shared network level value. See description at the global level. + "ddns-generated-prefix": "myhost", + + // Shared network level value. See description at the global level. + "ddns-override-client-update": false, + + // Shared network level value. See description at the global level. + "ddns-override-no-update": false, + + // Shared network level value. See description at the global level. + "ddns-qualifying-suffix": "", + + // Shared network level value. See description at the global level. + "ddns-replace-client-name": "never", + + // Shared network level value. See description at the global level. + "ddns-send-updates": true, + + // Shared network level value. See description at the global level. + "ddns-update-on-renew": true, + + // Shared network level value. See description at the global level. + "ddns-use-conflict-resolution": true, + + // Shared network level value. See description at the global level. + "hostname-char-replacement": "x", + + // Shared network level value. See description at the global level. + "hostname-char-set": "[^A-Za-z0-9.-]", + // Specifies that this shared network is selected for the // requests received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Shared network level flag specifying whether the client // identifier should be used for identifying clients. @@ -561,14 +726,41 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Cache maximum: when the client last transmission time + // is close enough the lease is not renewed and current + // lease is returned as it was "cached". + "cache-max-age": 1000, + // Enumeration specifying server's mode of operation when it // fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and "reservations-out-of-pool" + // parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved addresses + // are out-of-pool. + // Ignored when reservations-in-subnet is false. + // If specified, it is inherited by "subnet4" levels. + "reservations-out-of-pool": false, // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], + // Turn off storage of extended information (e.g. relay agent + // information) with each lease for this shared-network. + "store-extended-info": false, + // Shared network level server hostname set in 'sname' field. "server-hostname": "", @@ -585,6 +777,9 @@ // Prefix matched against source address. See RFC7341. "4o6-subnet": "2001:db8:1:1::/64", + // Subnet level authoritative flag. + "authoritative": false, + // Subnet level bootfile name, set in 'file' field. "boot-file-name": "", @@ -593,12 +788,42 @@ // provided, no restriction is applied. "client-class": "", + // Subnet level value. See description at the global level. + "ddns-generated-prefix": "myhost", + + // Subnet level value. See description at the global level. + "ddns-override-client-update": false, + + // Subnet level value. See description at the global level. + "ddns-override-no-update": false, + + // Subnet level value. See description at the global level. + "ddns-qualifying-suffix": "", + + // Subnet level value. See description at the global level. + "ddns-replace-client-name": "never", + + // Subnet level value. See description at the global level. + "ddns-send-updates": true, + + // Subnet level value. See description at the global level. + "ddns-update-on-renew": true, + + // Subnet level value. See description at the global level. + "ddns-use-conflict-resolution": true, + + // Subnet level value. See description at the global level. + "hostname-char-replacement": "x", + + // Subnet level value. See description at the global level. + "hostname-char-set": "[^A-Za-z0-9.-]", + // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Subnet level flag specifying whether the client identifier // should be used for identifying clients. @@ -608,6 +833,10 @@ // in 'siaddr'. "next-server": "0.0.0.0", + // Turn on storage of extended information (e.g. relay agent + // information) with each lease for this subnet. + "store-extended-info": true, + // Subnet level list of DHCP options. "option-data": [ { @@ -685,9 +914,23 @@ // Enumeration specifying server's mode of operation when it // fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and + // "reservations-out-of-pool" parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved + // addresses are out-of-pool. + // Ignored when reservations-in-subnet is false. + "reservations-out-of-pool": false, - // Subnet-level compute T1 and T2 timers. + // Subnet level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. @@ -696,6 +939,12 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Subnet-level cache maximum. + "cache-max-age": 1000, + // List of static IPv4 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ @@ -707,6 +956,9 @@ // Reserved IP address. "ip-address": "192.0.2.204", + // Hostname. + "hostname": "foo.example.org", + // Reservation specific option data. "option-data": [ { @@ -779,7 +1031,7 @@ // Name of the database to connect to. "name": "config", - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql" } ], @@ -797,11 +1049,29 @@ "enable-queue": true, // Queue type was mandatory. - "queue-type": "kea-ring4" + "queue-type": "kea-ring4", + + // Capacity is optional. + "capacity": 64 }, // Fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and "reservations-out-of-pool" parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved addresses + // are out-of-pool. + // Ignored when reservations-in-subnet is false. + // If specified, it is inherited by "shared-networks" and + // "subnet4" levels. + "reservations-out-of-pool": false, // Global compute T1 and T2 timers. "calculate-tee-times": true, @@ -812,6 +1082,12 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Global cache maximum. + "cache-max-age": 1000, + // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters @@ -845,13 +1121,19 @@ "maxver": 1, // Specifies logging destination. - "output": "stdout" + "output": "stdout", + + // Specifies log entry content + "pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } - ] + ], + + // Look at advanced example for the use of user-contexts. + "user-context": { } } } diff -pruN 2.0.2-3/doc/examples/kea4/all-options.json 2.2.0-1/doc/examples/kea4/all-options.json --- 2.0.2-3/doc/examples/kea4/all-options.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/all-options.json 2022-07-26 06:08:02.000000000 +0000 @@ -1229,7 +1229,7 @@ { "code": 114, "data": "https://default.example.org", - "name": "default-url" + "name": "v4-captive-portal" }, // Option code 115 is unassigned. @@ -1491,13 +1491,6 @@ "name": "v4-portparams" }, - // Type: string - { - "code": 160, - "data": "portal", - "name": "v4-captive-portal" - }, - // Option codes 161-209 are unassigned. /* diff -pruN 2.0.2-3/doc/examples/kea4/backends.json 2.2.0-1/doc/examples/kea4/backends.json --- 2.0.2-3/doc/examples/kea4/backends.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/backends.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,14 +4,13 @@ // - memfile // - MySQL // - PostgreSQL -// - CQL (Cassandra) backend { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify lease type. Exactly one lease-database section @@ -66,21 +65,6 @@ // "connect-timeout": 3 // }, -// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra -// database. Make sure it is up, running and properly initialized. See -// kea-admin documentation for details on how to initialize the -// database. The only strictly required parameters are type, keyspace -// and contact-points. At least one contact point must be specified, but -// more than one is required for redundancy. Make sure you specify the -// contact points without spaces. Kea must be compiled with --with-cql -// option to use this backend. -// "lease-database": { -// "type": "cql", -// "keyspace": "keatest", -// "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", -// "port": 9042 -// }, - // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, @@ -97,7 +81,7 @@ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea4/cassandra.json 2.2.0-1/doc/examples/kea4/cassandra.json --- 2.0.2-3/doc/examples/kea4/cassandra.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/cassandra.json 1970-01-01 00:00:00.000000000 +0000 @@ -1,121 +0,0 @@ -// This is an example configuration file for the DHCPv4 server in Kea. -// It is a basic scenario with one IPv4 subnet configured. It demonstrates -// how to configure Kea to use CQL (Cassandra) backend - -{ "Dhcp4": - -{ -// Kea is told to listen on ethX interface only. - "interfaces-config": { - "interfaces": [ "ethX" ] - }, - -// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra -// database. Make sure it is up, running and properly initialized. See -// kea-admin documentation for details on how to initialize the -// database. The only strictly required parameters are type, keyspace -// and contact-points. At least one contact point must be specified, but -// more than one is required for redundancy. Make sure you specify the -// contact points without spaces. Kea must be compiled with --with-cql -// option to use this backend. - "lease-database": { - "type": "cql", - "keyspace": "keatest", - "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", - "port": 9042, - - // Cassandra supports many additonal parameters that are typically - // not needed, but may be used to tweak your deployment. - - // This parameter governs how long Kea waits before attempting - // to reconnect. Expressed in milliseconds. The default is 2000 [ms]. - "reconnect-wait-time": 2000, - - // This parameter sets the timeout for connecting to a node. Expressed - // in milliseconds. The default is 5000 [ms]. - "connect-timeout": 5000, - - // This parameter sets the timeout for waiting for a response - // from a node. Expressed in milliseconds. The default is 12000 [ms]. - "request-timeout": 12000, - - // This parameter governs the TCP keep-alive mechanism. Expressed - // in seconds of delay. The default is disabled. In this example - // it is set to 20 minutes. - "tcp-keepalive": 1200, - - // This parameter enables/disables Nagle's algorithm on connections. - // The default is true. - "tcp-nodelay": true, - - // This parameter configures consistency level. The default is "quorum". - // Supported values: - // - any - // - one - // - two - // - three - // - quorum - // - all - // - local-quorum - // - each-quorum - // - serial - // - local-serial - // - local-one - // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.html for more details. - "consistency": "quorum", - - // This parameter configures serial consistency level which manages - // lightweight transaction isolation. The default is "serial". - // Supported values: - // - any - // - one - // - two - // - three - // - quorum - // - all - // - local-quorum - // - each-quorum - // - serial - // - local-serial - // - local-one - // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigSerialConsistency.html for more details. - "serial-consistency": "serial" - }, - -// Addresses will be assigned with a lifetime of 4000 seconds. - "valid-lifetime": 4000, - -// Renew and rebind timers are commented out. This implies that options -// 58 and 59 will not be sent to the client. In this case it is up to -// the client to pick the timer values according to RFC2131. Uncomment the -// timers to send these options to the client. -// "renew-timer": 1000, -// "rebind-timer": 2000, - -// The following list defines subnets. We have only one subnet -// here. We tell Kea that it is directly available over local interface. - "subnet4": [ - { - "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], - "subnet": "192.0.2.0/24", - "interface": "ethX" - } - ], - -// The following configures logging. It assumes that messages with at -// least informational level (info, warn, error and fatal) should be -// logged to stdout. - "loggers": [ - { - "name": "kea-dhcp4", - "output_options": [ - { - "output": "stdout" - } - ], - "severity": "INFO" - } - ] -} - -} diff -pruN 2.0.2-3/doc/examples/kea4/classify2.json 2.2.0-1/doc/examples/kea4/classify2.json --- 2.0.2-3/doc/examples/kea4/classify2.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/classify2.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,9 +4,9 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Let's use the simplest backend: memfile and use some reasonable values @@ -89,7 +89,7 @@ "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "client-class": "VoIP", - "interface": "ethX" + "interface": "eth0" }, // This one doesn't have any client-class specified, so everyone // is allowed in. The normal subnet selection rules still apply, @@ -104,7 +104,7 @@ "hw-address": "1a:1b:1c:1d:1e:1f", "client-classes": [ "VoIP" ] } ], - "interface": "ethX", + "interface": "eth0", "require-client-classes": [ "second_subnet" ] }, @@ -125,15 +125,15 @@ "pool": "192.0.5.1 - 192.0.5.200" } ], "subnet": "192.0.4.0/23", - "interface": "ethY" + "interface": "eth1" }, // This subnet is divided in two pools for unknown and known // (i.e. which have a reservation) clients. The built-in KNOWN and // UNKNOWN classes are set or not at host reservation lookup (KNOWN if // this returns something, UNKNOWN if this finds nothing) and client -//classes depending on it are evaluated. +// classes depending on it are evaluated. // This happens after subnet selection and before address allocation -//from pools. +// from pools. { "pools": [ { diff -pruN 2.0.2-3/doc/examples/kea4/classify.json 2.2.0-1/doc/examples/kea4/classify.json --- 2.0.2-3/doc/examples/kea4/classify.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/classify.json 2022-07-26 06:08:02.000000000 +0000 @@ -3,9 +3,9 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Let's use the simplest backend: memfile and use some reasonable values @@ -81,7 +81,7 @@ "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "client-class": "VoIP", - "interface": "ethX" + "interface": "eth0" }, // This one doesn't have any client-class specified, so everyone @@ -97,7 +97,7 @@ "hw-address": "1a:1b:1c:1d:1e:1f", "client-classes": [ "VoIP" ] } ], - "interface": "ethX" + "interface": "eth0" }, // The following list defines a subnet with pools. For some pools @@ -119,7 +119,7 @@ } ], "subnet": "192.0.4.0/23", - "interface": "ethY" + "interface": "eth1" } ], diff -pruN 2.0.2-3/doc/examples/kea4/config-backend.json 2.2.0-1/doc/examples/kea4/config-backend.json --- 2.0.2-3/doc/examples/kea4/config-backend.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/config-backend.json 2022-07-26 06:08:02.000000000 +0000 @@ -11,9 +11,9 @@ // either "all" or "server1" will be used by this instance. "server-tag": "server1", - // Kea is told to listen on ethX interface only. + // Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Use memfile lease database backend. diff -pruN 2.0.2-3/doc/examples/kea4/dhcpv4-over-dhcpv6.json 2.2.0-1/doc/examples/kea4/dhcpv4-over-dhcpv6.json --- 2.0.2-3/doc/examples/kea4/dhcpv4-over-dhcpv6.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/dhcpv4-over-dhcpv6.json 2022-07-26 06:08:02.000000000 +0000 @@ -7,7 +7,7 @@ "Dhcp4": { "interfaces-config": { - "interfaces": [ "eno33554984" ] + "interfaces": [ "eth0" ] }, "lease-database": { @@ -21,7 +21,7 @@ "subnet4": [ { "subnet": "10.10.10.0/24", // Don't forget the "4o6-" before "interface" here! - "4o6-interface": "eno33554984", + "4o6-interface": "eth0", "4o6-subnet": "2001:db8:1:1::/64", "pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ] } ], diff -pruN 2.0.2-3/doc/examples/kea4/global-reservations.json 2.2.0-1/doc/examples/kea4/global-reservations.json --- 2.0.2-3/doc/examples/kea4/global-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/global-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -9,13 +9,13 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, -// We need to specify the database used to store leases. As of September -// 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and +// We need to specify the database used to store leases. As of June +// 2022, three database backends are supported: MySQL, PostgreSQL and // the in-memory database, Memfile. We'll use memfile because it doesn't // require any prior set up. "lease-database": { @@ -144,7 +144,7 @@ // Note: flexible identifier requires flex_id hook library to be // loaded to work. { - "flex-id": "s0mEVaLue", + "flex-id": "'s0mEVaLue'", "ip-address": "192.0.2.206" } ], diff -pruN 2.0.2-3/doc/examples/kea4/ha-load-balancing-primary.json 2.2.0-1/doc/examples/kea4/ha-load-balancing-primary.json --- 2.0.2-3/doc/examples/kea4/ha-load-balancing-primary.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/ha-load-balancing-primary.json 2022-07-26 06:08:02.000000000 +0000 @@ -14,7 +14,7 @@ // Add names of your network interfaces to listen on. "interfaces-config": { // The DHCPv4 server listens on this interface. - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Control socket is required for communication between the Control @@ -28,8 +28,8 @@ // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL) and even Cassandra. Those database backends - // require more parameters, like name, host and possibly user and password. + // (MySQL and/or PostgreSQL). Those database backends require more + // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { @@ -105,7 +105,7 @@ "heartbeat-delay": 10000, // Maximum time for partner's response to a heartbeat, after which // failure detection is started. This is specified in milliseconds. - "max-response-delay": 10000, + "max-response-delay": 60000, // The following parameters control how the server detects the // partner's failure. The ACK delay sets the threshold for the // 'secs' field of the received discovers. This is specified in diff -pruN 2.0.2-3/doc/examples/kea4/hooks.json 2.2.0-1/doc/examples/kea4/hooks.json --- 2.0.2-3/doc/examples/kea4/hooks.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/hooks.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,9 +5,9 @@ {"Dhcp4": { -// Kea is told to listen on the ethX interface only. +// Kea is told to listen on the eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Set up the storage for leases. @@ -22,7 +22,7 @@ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea4/hooks-radius.json 2.2.0-1/doc/examples/kea4/hooks-radius.json --- 2.0.2-3/doc/examples/kea4/hooks-radius.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/hooks-radius.json 2022-07-26 06:08:02.000000000 +0000 @@ -69,8 +69,8 @@ { // Kea is told to listen on specific interfaces only. "interfaces-config": { - // You should probably list your network interfaces here (e.g. "en0") - "interfaces": [ "en0" ] + // You should probably list your network interfaces here (e.g. "eth1961") + "interfaces": [ "eth1961" ] }, // Set up the storage for leases. @@ -101,7 +101,7 @@ // Set the subnet ID (aka RADIUS NAS port). "id": 14, "subnet": "192.0.2.0/24", - "interface": "en0", + "interface": "eth1961", "pools": [ { // Red pool (10-19 are for reservations) diff -pruN 2.0.2-3/doc/examples/kea4/leases-expiration.json 2.2.0-1/doc/examples/kea4/leases-expiration.json --- 2.0.2-3/doc/examples/kea4/leases-expiration.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/leases-expiration.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // Note, we're setting the maximum number of row read errors to 100, // (defaults to 0, meaning unlimited). @@ -49,7 +49,7 @@ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea4/multiple-options.json 2.2.0-1/doc/examples/kea4/multiple-options.json --- 2.0.2-3/doc/examples/kea4/multiple-options.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/multiple-options.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,14 +4,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" diff -pruN 2.0.2-3/doc/examples/kea4/mysql-reservations.json 2.2.0-1/doc/examples/kea4/mysql-reservations.json --- 2.0.2-3/doc/examples/kea4/mysql-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/mysql-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,15 +5,15 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -59,11 +59,15 @@ "type": "mysql", "reconnect-wait-time": 3000, // expressed in ms "max-reconnect-tries": 3, - "name": "kea", - "user": "kea", - "password": "kea", + "name": "keatest", + "user": "keatest", + "password": "keatest", "host": "localhost", - "port": 3306 + "port": 3306, + "trust-anchor": "my-ca", + "cert-file": "my-cert", + "key-file": "my-key", + "cipher-list": "AES" }, // Define a subnet with a single pool of dynamic addresses. Addresses from @@ -75,7 +79,7 @@ { "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX", + "interface": "eth0", "id": 1 } ], diff -pruN 2.0.2-3/doc/examples/kea4/pgsql-reservations.json 2.2.0-1/doc/examples/kea4/pgsql-reservations.json --- 2.0.2-3/doc/examples/kea4/pgsql-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/pgsql-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,15 +5,15 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" @@ -61,9 +61,9 @@ "type": "postgresql", "reconnect-wait-time": 3000, // expressed in ms "max-reconnect-tries": 3, - "name": "kea", - "user": "kea", - "password": "kea", + "name": "keatest", + "user": "keatest", + "password": "keatest", "host": "localhost" } ], @@ -77,7 +77,7 @@ { "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX", + "interface": "eth0", "id": 1 } ], diff -pruN 2.0.2-3/doc/examples/kea4/reservations.json 2.2.0-1/doc/examples/kea4/reservations.json --- 2.0.2-3/doc/examples/kea4/reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,14 +4,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, -// We need to specify the database used to store leases. As of September -// 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and -// the in-memory database, Memfile. We'll use memfile because it doesn't +// We need to specify the database used to store leases. As of April +// 2022, three database backends are supported: MySQL, PostgreSQL, and the +// in-memory database, Memfile. We'll use memfile because it doesn't // require any prior set up. "lease-database": { "type": "memfile", @@ -155,7 +155,7 @@ // Note: flexible identifier requires flex_id hook library to be // loaded to work. { - "flex-id": "s0mEVaLue", + "flex-id": "'s0mEVaLue'", "ip-address": "192.0.2.206" } diff -pruN 2.0.2-3/doc/examples/kea4/several-subnets.json 2.2.0-1/doc/examples/kea4/several-subnets.json --- 2.0.2-3/doc/examples/kea4/several-subnets.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/several-subnets.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" diff -pruN 2.0.2-3/doc/examples/kea4/shared-network.json 2.2.0-1/doc/examples/kea4/shared-network.json --- 2.0.2-3/doc/examples/kea4/shared-network.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/shared-network.json 2022-07-26 06:08:02.000000000 +0000 @@ -11,7 +11,7 @@ // As with any other configuration, you need to tell Kea the interface // names, so it would listen to incoming traffic. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // You also need to tell where to store lease information. diff -pruN 2.0.2-3/doc/examples/kea4/single-subnet.json 2.2.0-1/doc/examples/kea4/single-subnet.json --- 2.0.2-3/doc/examples/kea4/single-subnet.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/single-subnet.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -35,7 +35,7 @@ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea4/vendor-specific.json 2.2.0-1/doc/examples/kea4/vendor-specific.json --- 2.0.2-3/doc/examples/kea4/vendor-specific.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/vendor-specific.json 2022-07-26 06:08:02.000000000 +0000 @@ -70,9 +70,9 @@ ] } ], -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": ["ethX"] + "interfaces": ["eth0"] }, // We need to specify the database used to store leases. "lease-database": { @@ -82,7 +82,7 @@ // here. We tell Kea that it is directly available over local interface. "subnet4": [ { - "interface": "ethX", + "interface": "eth0", "pools": [ { "pool": "192.0.2.50-192.0.2.50" diff -pruN 2.0.2-3/doc/examples/kea4/vivso.json 2.2.0-1/doc/examples/kea4/vivso.json --- 2.0.2-3/doc/examples/kea4/vivso.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/vivso.json 2022-07-26 06:08:02.000000000 +0000 @@ -62,10 +62,10 @@ ] } ], -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { "interfaces": [ - "ethX" + "eth0" ] }, // We need to specify the database used to store leases. @@ -76,7 +76,7 @@ // here. We tell Kea that it is directly available over local interface. "subnet4": [ { - "interface": "ethX", + "interface": "eth0", "pools": [ { "pool": "192.0.2.50-192.0.2.50" diff -pruN 2.0.2-3/doc/examples/kea4/with-ddns.json 2.2.0-1/doc/examples/kea4/with-ddns.json --- 2.0.2-3/doc/examples/kea4/with-ddns.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea4/with-ddns.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp4": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -35,7 +35,7 @@ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/advanced.json 2.2.0-1/doc/examples/kea6/advanced.json --- 2.0.2-3/doc/examples/kea6/advanced.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/advanced.json 2022-07-26 06:08:02.000000000 +0000 @@ -2,7 +2,7 @@ // It attempts to showcase some of the more advanced features. // Topology wise, it's a basic scenario with one IPv6 subnet configured. // It is assumed that one subnet (2001:db8:1::/64) is available directly -// over ethX interface. +// over eth0 interface. // // The following features are currently showcased here: // 1. Configuration of MAC/hardware address sources in DHCPv6 @@ -14,9 +14,9 @@ { "Dhcp6": { - // Kea is told to listen on ethX network interface only. + // Kea is told to listen on eth0 network interface only. "interfaces-config": { - "interfaces": [ "ethX" ], + "interfaces": [ "eth0" ], // This makes interfaces to be re-detected at each (re-)configuration. // By default it is true. @@ -24,8 +24,8 @@ }, // We need to specify the database used to store leases. As of - // September 2016, four database backends are supported: MySQL, - // PostgreSQL, Cassandra, and the in-memory database, Memfile. + // June 2022, three database backends are supported: MySQL, + // PostgreSQL and the in-memory database, Memfile. // We will use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -132,8 +132,8 @@ "prefix": "2001:db8:abcd::", "prefix-len": 48, "delegated-len": 64, - "excluded-prefix": "2001:db8:abcd:1234::", - "excluded-prefix-len": 72, + "excluded-prefix": "2001:db8:abcd:0:1234::", + "excluded-prefix-len": 80, // Another user-context for this PD pool. Again, you can put // anything you want in there as long as it's valid JSON and @@ -145,7 +145,7 @@ ], // end of pools "subnet": "2001:db8:1::/64", - "interface": "ethX", + "interface": "eth0", // Sometimes the relay may use an odd IPv6 address that's not matching // the subnet. This is discouraged, but there are valid cases when it diff -pruN 2.0.2-3/doc/examples/kea6/all-keys.json 2.2.0-1/doc/examples/kea6/all-keys.json --- 2.0.2-3/doc/examples/kea6/all-keys.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/all-keys.json 2022-07-26 06:08:02.000000000 +0000 @@ -258,78 +258,78 @@ "hosts-databases": [ { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 3306, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql", // User name to be used to access the database. - "user": "kea", + "user": "keatest", // Read only mode. - "readonly": false + "readonly": false, + + // Next entries are for the OpenSSL support in MySQL. + // Trust anchor aka certificate authority file or directory. + "trust-anchor": "my-ca", + + // Client certificate file name. + "cert-file": "my-cert", + + // Private key file name. + "key-file": "my-key", + + // Cipher list (see the OpenSSL ciphers command manual). + "cipher-list": "AES" }, { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 5432, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "postgresql", // User name to be used to access the database. - "user": "kea" + "user": "keatest" }, { // Name of the database to connect to. - "keyspace": "kea", - - // Host on which the database resides. - "contact-points": "127.0.0.1", + "name": "keatest", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 9042, - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "cql", + // Type of the database, e.g. "mysql", "postgresql". + "type": "mysql", // User name to be used to access the database. - "user": "kea", - - // Consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "consistency": "quorum", - - // Serial consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "serial-consistency": "serial", + "user": "keatest", // Connection reconnect wait time. // This parameter governs how long Kea waits before attempting - // to reconnect. Expressed in milliseconds. The default is 2000 [ms] - // for Casandra and 0 (disabled) for MySQL and PostgreSQL. + // to reconnect. Expressed in milliseconds. The default is 0 + // (disabled) for MySQL and PostgreSQL. "reconnect-wait-time": 3000, // Connection maximum reconnect tries. @@ -341,16 +341,7 @@ "on-fail": "stop-retry-exit", // Connection connect timeout. - "connect-timeout": 100, - - // Connection request timeout. - "request-timeout": 100, - - // Connection tcp keepalive. - "tcp-keepalive": 100, - - // Connection tcp nodelay. - "tcp-nodelay": true + "connect-timeout": 100 } ], @@ -374,16 +365,41 @@ // Specifies a list of interfaces on which the Kea DHCPv6 // server should listen to the DHCP requests. "interfaces": [ - "ethX" + "eth0" ], // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. - "re-detect": true + "re-detect": true, + + // Kea tries to bind the service sockets during initialization. It may + // fail due to a port being already opened or misconfiguration. Kea can + // suppress these errors and only logs them. This flag prevents starting + // the DHCP server without binding all sockets. If unspecified, it + // defaults to false. + "service-sockets-require-all": true, + + // Kea tries to bind the service sockets during initialization. This + // option specifies how many times binding to interface will be retried. + // The default value is 0 which means that the operation will not be + // repeated. + "service-sockets-max-retries": 5, + + // The time interval in milliseconds to wait before the next attempt to + // retry opening a service socket. + "service-sockets-retry-wait-time": 5000 }, + // Boolean parameter which controls whether an early global host + // reservations lookup should be performed. This lookup takes place + // before subnet selection and when a global reservation is found + // with some client classes, it triggers a second phase classification. + // It can also be used to drop queries using host reservations as a + // decision table indexed by reservation identifiers. + "early-global-reservations-lookup": true, + // Boolean parameter which controls DHCP server's behavior with respect // to creating host reservations for the same IP address or delegated // prefix. By default this flag is set to true in which case the server @@ -401,6 +417,13 @@ // support this mode. "ip-reservations-unique": true, + /// Boolean parameter which controls whether host reservations lookup + /// should be performed before lease lookup. This parameter has effect + /// only when multi-threading is disabled. When multi-threading is + /// enabled, host reservations lookup is always performed first to avoid + /// lease lookup resource locking. + "reservations-lookup-first": true, + // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval @@ -425,8 +448,8 @@ // because non stored leases will be lost upon Kea server restart. "persist": true, - // Lease database backend type, i.e. "memfile", "mysql", - // "postgresql" or "cql". + // Lease database backend type, i.e. "memfile", "mysql" or + // "postgresql". "type": "memfile" }, @@ -638,7 +661,7 @@ // Specifies that this shared network is selected for the // requests received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to @@ -764,7 +787,7 @@ // Specifies that this subnet is selected for the requests // received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to @@ -1011,7 +1034,7 @@ // Name of the database to connect to. "name": "config", - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql" } ], diff -pruN 2.0.2-3/doc/examples/kea6/all-keys-netconf.json 2.2.0-1/doc/examples/kea6/all-keys-netconf.json --- 2.0.2-3/doc/examples/kea6/all-keys-netconf.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/all-keys-netconf.json 2022-07-26 06:08:02.000000000 +0000 @@ -22,7 +22,25 @@ // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. - "test": "member('HA_server1')" + "test": "member('HA_server1')", + + // Class valid lifetime. + "valid-lifetime": 6000, + + // Class min valid lifetime. + "min-valid-lifetime": 4000, + + // Class max valid lifetime. + "max-valid-lifetime": 8000, + + // Class preferred lifetime. + "preferred-lifetime": 7000, + + // Class min preferred lifetime. + "min-preferred-lifetime": 5000, + + // Class max preferred lifetime. + "max-preferred-lifetime": 9000 }, { // Second class name. @@ -51,6 +69,14 @@ } ], + // Parameters for triggering behaviors compatible with broken or + // non-compliant clients, relays or other agents + "compatibility": { + // Parse options more leniently where fields can be deduced + // deterministically even if against RFC or common practice. + "lenient-option-parsing": true + }, + // Command control socket configuration parameters for Kea DHCPv6 server. "control-socket": { // Location of the unix domain socket file the DHCPv6 server uses @@ -63,6 +89,65 @@ "socket-type": "unix" }, + // Specifies a prefix to be prepended to the generated Client FQDN. + // It may be specified at the global, shared-network and subnet levels. + "ddns-generated-prefix": "myhost", + + // Boolean flag indicating that server should ignore DHCP client + // wishes to update DNS on its own. With that flag set to true + // the server will send DNS updates for both forward and + // reverse DNS data. The default value is false, which indicates + // that the server will delegate DNS update to the client when + // requested. It may be specified at the global, shared-network + // and subnet levels. + "ddns-override-client-update": false, + + // Boolean flag indicating that the server should override DHCP + // client's wish to not update the DNS. With this parameter + // set to true the server will send DNS update even when + // the client requested no update. It may be specified at the + // global, shared-network and subnet levels. + "ddns-override-no-update": false, + + // Suffix appended to the partial name sent to the DNS. The + // default value is an empty string which indicates that no + // suffix is appended. It may be specified at the global, + // shared-network and subnet levels. + "ddns-qualifying-suffix": "", + + // Enumeration specifying whether the server should honor + // hostname or Client FQDN sent by the client or replace + // this name. The acceptable values are: "never" (use the + // name the client sent), "always" (replace the name the + // client sent), "when-present" (replace the name the client + // sent, but do not generate one when the client didn't sent + // the name), "when-not-present" (generate the name when + // client didn't send one, otherwise leave the name the + // client sent). The default value is "never". It may be + // specified at the global, shared-network and subnet levels. + "ddns-replace-client-name": "never", + + // Boolean flag which enables or disables the DDNS updating. It + // defaults to true. It may be specified at the global, shared- + // network and subnet levels. It works in conjunction with + // dhcp-ddns:enable-updates which must be true to enable connectivity + // to kea-dhcp-ddns. + "ddns-send-updates": true, + + // Boolean flag, which when true instructs the server to always + // update DNS when leases are renewed, even if the DNS information + // has not changed. The server's default behavior (i.e. flag is false) + // is to only update DNS if the DNS information has changed. It + // may be specified at the global, shared-network and subnet levels. + "ddns-update-on-renew": true, + + // Boolean flag, which is passed to kea-dhcp-ddns with each DDNS + // update request to indicate whether or not DNS update conflict + // resolution as described in RFC 4703 should be employed for the + // given update request. The default value for this flag is true. + // It may be specified at the global, shared-network and subnet levels. + "ddns-use-conflict-resolution": true, + // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, @@ -71,23 +156,11 @@ // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { - // Boolean flag indicating if Kea DHCPv6 server must generate NCRs. - // By default NCRs are not generated. + // Boolean flag indicating if Kea DHCPv6 server should connect to + // kea-dhcp-ddns. This must be true for NCRs to be created and + // sent to kea-dhcp-ddns. By default NCRs are not generated. "enable-updates": false, - // Specifies a prefix to be prepended to the generated Client FQDN. - "generated-prefix": "myhost", - - // String of zero or more characters with which to replace each - // invalid character in the hostname or Client FQDN. The default - // value is an empty string which will cause invalid characters - // to be omitted rather than replaced. - "hostname-char-replacement": "x", - - // Regular expression describing the invalid character set in - // the hostname or Client FQDN. - "hostname-char-set": "[^A-Za-z0-9.-]", - // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, @@ -100,36 +173,6 @@ // only UDP is supported. "ncr-protocol": "UDP", - // Boolean flag indicating that server should ignore DHCP client - // wishes to update DNS on its own. With that flag set to true - // the server will send DNS updates for both forward and - // reverse DNS data. The default value is false, which indicates - // that the server will delegate DNS update to the client when - // requested. - "override-client-update": false, - - // Boolean flag indicating that the server should override DHCP - // client's wish to not update the DNS. With this parameter - // set to true the server will send DNS update even when - // the client requested no update. - "override-no-update": false, - - // Suffix appended to the partial name sent to the DNS. The - // default value is an empty string which indicates that no - // suffix is appended. - "qualifying-suffix": "", - - // Enumeration specifying whether the server should honor - // hostname or Client FQDN sent by the client or replace - // this name. The acceptable values are: "never" (use the - // name the client sent), "always" (replace the name the - // client sent), "when-present" (replace the name the client - // sent, but do not generate one when the client didn't sent - // the name), "when-not-present" (generate the name when - // client didn't send one, otherwise leave the name the - // client sent). The default value is "never". - "replace-client-name": "never", - // IP address that Kea DHCPv6 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. @@ -144,7 +187,20 @@ "server-ip": "::1", // Port number on which D2 listens for NCRs. - "server-port": 53001 + "server-port": 53001, + + // The follow parameters are DEPRECATED. They have been + // replaced with parameters that may be set at the global, + // shared-network, and subnet6 scopes. They are listed here + // as configuration parsing still accepts them. Eventually + // support for them will be removed. + "generated-prefix": "myhost", + "hostname-char-replacement": "x", + "hostname-char-set": "[^A-Za-z0-9.-]", + "override-client-update": false, + "override-no-update": false, + "qualifying-suffix": "", + "replace-client-name": "never" }, // Specifies the first of the two consecutive ports of the UDP @@ -202,85 +258,74 @@ "hosts-databases": [ { // Name of the database to connect to. - "name": "kea", + "name": "keatest", // Host on which the database resides. "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. "port": 3306, - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql", // User name to be used to access the database. - "user": "kea" - }, - { - // Name of the database to connect to. - "name": "kea", + "user": "keatest", - // Host on which the database resides. - "host": "localhost", + // Read only mode. + "readonly": false, - // Database password. - "password": "kea", + // Next entries are for the OpenSSL support in MySQL. + // Trust anchor aka certificate authority file or directory. + "trust-anchor": "my-ca", - // Port on which the database is available. - "port": 5432, + // Client certificate file name. + "cert-file": "my-cert", - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "postgresql", + // Private key file name. + "key-file": "my-key", - // User name to be used to access the database. - "user": "kea" + // Cipher list (see the OpenSSL ciphers command manual). + "cipher-list": "AES" }, { // Name of the database to connect to. - "keyspace": "kea", + "name": "keatest", // Host on which the database resides. - "contact-points": "127.0.0.1", + "host": "localhost", // Database password. - "password": "kea", + "password": "keatest", // Port on which the database is available. - "port": 9042, + "port": 5432, - // Type of the database, e.g. "mysql", "postgresql", "cql". - "type": "cql", + // Type of the database, e.g. "mysql", "postgresql". + "type": "postgresql", // User name to be used to access the database. - "user": "kea", - - // Consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "consistency": "quorum", - - // Serial consistency level for all queries. - // Supported values: any, one, two, three, quorum, all, - // local-quorum, each-quorum, serial, local-serial, local-one. - "serial-consistency": "serial", + "user": "keatest", // Connection reconnect wait time. - "reconnect-wait-time": 100, + // This parameter governs how long Kea waits before attempting + // to reconnect. Expressed in milliseconds. The default is 0 + // (disabled) for MySQL and PostgreSQL. + "reconnect-wait-time": 3000, + + // Connection maximum reconnect tries. + "max-reconnect-tries": 3, + + // Action to take when connection recovery fails. + // Supported values: stop-retry-exit, serve-retry-exit, + // serve-retry-continue + "on-fail": "stop-retry-exit", // Connection connect timeout. - "connect-timeout": 100, - - // Connection request timeout. - "request-timeout": 100, - - // Connection tcp keepalive. - "tcp-keepalive": 100, - - // Connection tcp nodelay. - "tcp-nodelay": true + "connect-timeout": 100 } ], @@ -304,16 +349,65 @@ // Specifies a list of interfaces on which the Kea DHCPv6 // server should listen to the DHCP requests. "interfaces": [ - "ethX" + "eth0" ], // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. - "re-detect": true + "re-detect": true, + + // Kea tries to bind the service sockets during initialization. It may + // fail due to a port being already opened or misconfiguration. Kea can + // suppress these errors and only logs them. This flag prevents starting + // the DHCP server without binding all sockets. If unspecified, it + // defaults to false. + "service-sockets-require-all": true, + + // Kea tries to bind the service sockets during initialization. This + // option specifies how many times binding to interface will be retried. + // The default value is 0 which means that the operation will not be + // repeated. + "service-sockets-max-retries": 5, + + // The time interval in milliseconds to wait before the next attempt to + // retry opening a service socket. + "service-sockets-retry-wait-time": 5000 }, + // Boolean parameter which controls whether an early global host + // reservations lookup should be performed. This lookup takes place + // before subnet selection and when a global reservation is found + // with some client classes, it triggers a second phase classification. + // It can also be used to drop queries using host reservations as a + // decision table indexed by reservation identifiers. + "early-global-reservations-lookup": true, + + // Boolean parameter which controls DHCP server's behavior with respect + // to creating host reservations for the same IP address or delegated + // prefix. By default this flag is set to true in which case the server + // prevents creation of multiple host reservations for the same IP address + // or delegated prefix. When this parameter is set to false, the server + // allows for creating multiple reservations for the same IP address or + // delegated prefix within a subnet. This setting is useful in deployments + // in which a given host may be communicating with a DHCP server over + // multiple interfaces and depending on the chosen interface different + // MAC address (or other identifier) will be used to identify the host. + // Note that some host backends do not support the mode in which multiple + // reservations for the same IP address or delegated prefix are used. + // If these backends are in use and this setting is attempted a + // configuration error will occur. The MySQL and PostgreSQL backends do + // support this mode. + "ip-reservations-unique": true, + + /// Boolean parameter which controls whether host reservations lookup + /// should be performed before lease lookup. This parameter has effect + /// only when multi-threading is disabled. When multi-threading is + /// enabled, host reservations lookup is always performed first to avoid + /// lease lookup resource locking. + "reservations-lookup-first": true, + // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval @@ -338,8 +432,8 @@ // because non stored leases will be lost upon Kea server restart. "persist": true, - // Lease database backend type, i.e. "memfile", "mysql", - // "postgresql" or "cql". + // Lease database backend type, i.e. "memfile", "mysql" or + // "postgresql". "type": "memfile" }, @@ -416,6 +510,18 @@ } ], + // Global value which limits the number of client packets (e.g. + // REQUESTs,RENEWs...) that may be parked while waiting for + // hook library work to complete, prior to a response (e.g. REPLY) + // being sent back to the client. A typical example is when kea-dhcp6 + // parks a REQUEST while it sends the lease update(s) to its + // HA peer(s). The packet is unparked once the update(s) have been + // acknowledged. This value limits the number of packets that can + // be held pending the updates. In times of heavy client traffic, + // this value can keep kea-dhcp6 from building an insurmountable + // backlog of updates. + "parked-packet-limit": 128, + // Global (default) value of the preferred lifetime. "preferred-lifetime": 50, @@ -436,6 +542,37 @@ // DHCP client renews the lease. "renew-timer": 30, + // Global value to store extended information (e.g. relay agent + // information) with each lease. + "store-extended-info": true, + + // Statistics keep some samples per observation point. + // There are two default values: maximum count and maximum age. + // Set the maximum count to zero disables it. + "statistic-default-sample-count": 0, + + // When the maximum count is 0 the maximum age (in seconds) applies. + "statistic-default-sample-age": 60, + + // Multi-threading parameters. + "multi-threading": { + // By default Kea processes packets on a single thread (default + // 'false' value for this option). To enable multi-threading, this + // option can be set ('true' value). + "enable-multi-threading": false, + + // When multi-threading is enabled, Kea will process packets on a + // number of multiple threads configurable through this option. The + // value must be a positive integer (0 means auto detect). + "thread-pool-size": 0, + + // When multi-threading is enabled, Kea will read packets from the + // interface and append a working item to the thread pool. This + // option configures the maximum number of items that can be queued. + // The value must be a positive integer (0 means unlimited). + "packet-queue-size": 0 + }, + // Governs how the Kea DHCPv6 server should deal with the invalid // data received from the client. "sanity-checks": { @@ -476,9 +613,39 @@ // empty string is provided, no restriction is applied. "client-class": "", + // Shared network level value. See description at the global level. + "ddns-generated-prefix": "myhost", + + // Shared network level value. See description at the global level. + "ddns-override-client-update": false, + + // Shared network level value. See description at the global level. + "ddns-override-no-update": false, + + // Shared network level value. See description at the global level. + "ddns-qualifying-suffix": "", + + // Shared network level value. See description at the global level. + "ddns-replace-client-name": "never", + + // Shared network level value. See description at the global level. + "ddns-send-updates": true, + + // Shared network level value. See description at the global level. + "ddns-update-on-renew": true, + + // Shared network level value. See description at the global level. + "ddns-use-conflict-resolution": true, + + // Shared network level value. See description at the global level. + "hostname-char-replacement": "x", + + // Shared network level value. See description at the global level. + "hostname-char-set": "[^A-Za-z0-9.-]", + // Specifies that this shared network is selected for the // requests received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to @@ -526,14 +693,41 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Cache maximum: when the client last transmission time + // is close enough the lease is not renewed and current + // lease is returned as it was "cached". + "cache-max-age": 10, + // Enumeration specifying server's mode of operation when it // fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and "reservations-out-of-pool" + // parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved addresses + // are out-of-pool. + // Ignored when reservations-in-subnet is false. + // If specified, it is inherited by "subnet6" levels. + "reservations-out-of-pool": false, // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], + // Turn off storage of extended information (e.g. relay agent + // information) with each lease for this shared-network. + "store-extended-info": false, + // List of IPv6 subnets belonging to this shared network. "subnet6": [ { @@ -542,18 +736,52 @@ // provided, no restriction is applied. "client-class": "", + // Subnet level value. See description at the global level. + "ddns-generated-prefix": "myhost", + + // Subnet level value. See description at the global level. + "ddns-override-client-update": false, + + // Subnet level value. See description at the global level. + "ddns-override-no-update": false, + + // Subnet level value. See description at the global level. + "ddns-qualifying-suffix": "", + + // Subnet level value. See description at the global level. + "ddns-replace-client-name": "never", + + // Subnet level value. See description at the global level. + "ddns-send-updates": true, + + // Subnet level value. See description at the global level. + "ddns-update-on-renew": true, + + // Subnet level value. See description at the global level. + "ddns-use-conflict-resolution": true, + + // Subnet level value. See description at the global level. + "hostname-char-replacement": "x", + + // Subnet level value. See description at the global level. + "hostname-char-set": "[^A-Za-z0-9.-]", + // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. - "interface": "ethX", + "interface": "eth0", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to // which the response is sent. "interface-id": "", + // Turn on storage of extended information (e.g. relay agent + // information) with each lease for this subnet. + "store-extended-info": true, + // Subnet level list of DHCP options. "option-data": [ { @@ -593,7 +821,7 @@ "delegated-len": 64, // Excluded prefix (address) from client assignments. - "excluded-prefix": "2001:db8::", + "excluded-prefix": "2001:db8:1::", // Excluded prefix (length) from client assignments. "excluded-prefix-len": 72, @@ -602,10 +830,10 @@ "option-data": [], // Prefix range (address) used for client assignments. - "prefix": "2001:db8::", + "prefix": "2001:db8:1::", // Prefix range (length) used for client assignments. - "prefix-len": 40, + "prefix-len": 48, // List of client classes which must be evaluated // when this prefix pool is selected for client assignments. @@ -676,7 +904,21 @@ // Enumeration specifying server's mode of operation when it // fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and + // "reservations-out-of-pool" parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved + // addresses are out-of-pool. + // Ignored when reservations-in-subnet is false. + "reservations-out-of-pool": false, // Subnet level compute T1 and T2 timers. "calculate-tee-times": true, @@ -687,6 +929,12 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Subnet level cache maximum. + "cache-max-age": 10, + // List of static IPv6 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ @@ -770,7 +1018,7 @@ // Name of the database to connect to. "name": "config", - // Type of the database, e.g. "mysql", "postgresql", "cql". + // Type of the database, e.g. "mysql", "postgresql". "type": "mysql" } ], @@ -788,11 +1036,29 @@ "enable-queue": true, // Queue type was mandatory. - "queue-type": "kea-ring6" + "queue-type": "kea-ring6", + + // Capacity is optional. + "capacity": 64 }, // Fetches host reservations. - "reservation-mode": "all", + // "reservation-mode": "all", + // It is replaced by the "reservations-global", + // "reservations-in-subnet" and "reservations-out-of-pool" parameters. + + // Specify if server should lookup global reservations. + "reservations-global": false, + + // Specify if server should lookup in-subnet reservations. + "reservations-in-subnet": true, + + // Specify if server can assume that all reserved addresses + // are out-of-pool. + // Ignored when reservations-in-subnet is false. + // If specified, it is inherited by "shared-networks" and + // "subnet6" levels. + "reservations-out-of-pool": false, // Data directory. "data-directory": "/tmp", @@ -806,14 +1072,20 @@ // T2 = valid lifetime * .75. "t2-percent": .75, + // Cache threshold = valid lifetime * .25. + "cache-threshold": .25, + + // Global cache maximum. + "cache-max-age": 10, + // String of zero or more characters with which to replace each - // invalid character in the hostname or Client FQDN. The default + // invalid character in the Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in - // the hostname or Client FQDN. + // the Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // List of loggers used by the servers using this configuration file. @@ -839,13 +1111,19 @@ "maxver": 1, // Specifies logging destination. - "output": "stdout" + "output": "stdout", + + // Specifies log entry content + "pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } - ] + ], + + // Look at advanced example for the use of user-contexts. + "user-context": { } } } diff -pruN 2.0.2-3/doc/examples/kea6/all-options.json 2.2.0-1/doc/examples/kea6/all-options.json --- 2.0.2-3/doc/examples/kea6/all-options.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/all-options.json 2022-07-26 06:08:02.000000000 +0000 @@ -2069,7 +2069,7 @@ "space": "docsis3-v6" } ], - "subnet": "2001:db8:D0C5:15::/64" + "subnet": "2001:db8:d0c5:15::/64" } ] } diff -pruN 2.0.2-3/doc/examples/kea6/backends.json 2.2.0-1/doc/examples/kea6/backends.json --- 2.0.2-3/doc/examples/kea6/backends.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/backends.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,14 +4,13 @@ // - memfile // - MySQL // - PostgreSQL -// - CQL (Cassandra) backend { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify lease type. Exactly one lease-database section @@ -66,21 +65,6 @@ // "connect-timeout": 3 // }, -// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra -// database. Make sure it is up, running and properly initialized. See -// kea-admin documentation for details on how to initialize the -// database. The only strictly required parameters are type, keyspace -// and contact-points. At least one contact point must be specified, but -// more than one is required for redundancy. Make sure you specify the -// contact points without spaces. Kea must be compiled with --with-cql -// option to use this backend. -// "lease-database": { -// "type": "cql", -// "keyspace": "keatest", -// "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", -// "port": 9042 -// }, - // Addresses will be assigned with preferred and valid lifetimes // being 3000 and 4000, respectively. Client is told to start // renewing after 1000 seconds. If the server does not respond @@ -98,7 +82,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/cassandra.json 2.2.0-1/doc/examples/kea6/cassandra.json --- 2.0.2-3/doc/examples/kea6/cassandra.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/cassandra.json 1970-01-01 00:00:00.000000000 +0000 @@ -1,122 +0,0 @@ -// This is an example configuration file for the DHCPv6 server in Kea. -// It is a basic scenario with one IPv6 subnet configured. It demonstrates -// how to configure Kea to use CQL (Cassandra) backend. - -{ "Dhcp6": - -{ -// Kea is told to listen on ethX interface only. - "interfaces-config": { - "interfaces": [ "ethX" ] - }, - -// CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make -// sure it is up, running and properly initialized. See kea-admin documentation -// for details on how to initialize the database. The only strictly required -// parameters are type, keyspace and contact-points. At least one contact point -// must be specified, but more than one is required for redundancy. Make sure -// you specify the contact points without spaces. Kea must be compiled with -// --with-cql option to use this backend. - "lease-database": { - "type": "cql", - "keyspace": "keatest", - "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", - "port": 9042, - - // Cassandra supports many additonal parameters that are typically - // not needed, but may be used to tweak your deployment. - - // This parameter governs how long Kea waits before attempting - // to reconnect. Expressed in milliseconds. The default is 2000 [ms]. - "reconnect-wait-time": 2000, - - // This parameter sets the timeout for connecting to a node. Expressed - // in milliseconds. The default is 5000 [ms]. - "connect-timeout": 5000, - - // This parameter sets the timeout for waiting for a response - // from a node. Expressed in milliseconds. The default is 12000 [ms]. - "request-timeout": 12000, - - // This parameter governs the TCP keep-alive mechanism. Expressed - // in seconds of delay. The default is disabled. In this example it is - // set to 20 minutes. - "tcp-keepalive": 1200, - - // This parameter enables/disables Nagle's algorithm on connections. - // The default is true. - "tcp-nodelay": true, - - // This parameter configures consistency level. The default is "quorum". - // Supported values: - // - any - // - one - // - two - // - three - // - quorum - // - all - // - local-quorum - // - each-quorum - // - serial - // - local-serial - // - local-one - // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.html for more details. - "consistency": "quorum", - - // This parameter configures serial consistency level which manages - // lightweight transaction isolation. The default is "serial". - // Supported values: - // - any - // - one - // - two - // - three - // - quorum - // - all - // - local-quorum - // - each-quorum - // - serial - // - local-serial - // - local-one - // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigSerialConsistency.html for more details. - "serial-consistency": "serial" - }, - -// Addresses will be assigned with preferred and valid lifetimes -// being 3000 and 4000, respectively. Client is told to start -// renewing after 1000 seconds. If the server does not respond -// after 2000 seconds since the lease was granted, client is supposed -// to start REBIND procedure (emergency renewal that allows switching -// to a different server). - "preferred-lifetime": 3000, - "valid-lifetime": 4000, - "renew-timer": 1000, - "rebind-timer": 2000, - -// The following list defines subnets. Each subnet consists of at -// least subnet and pool entries. - "subnet6": [ - { - "pools": [ { "pool": "2001:db8:1::/80" } ], - "subnet": "2001:db8:1::/64", - "interface": "ethX" - } - ], - -// The following configures logging. It assumes that messages with at -// least informational level (info, warn, error and fatal) should be -// logged to stdout. - "loggers": [ - { - "name": "kea-dhcp6", - "output_options": [ - { - "output": "stdout" - } - ], - "debuglevel": 0, - "severity": "INFO" - } - ] -} - -} diff -pruN 2.0.2-3/doc/examples/kea6/classify2.json 2.2.0-1/doc/examples/kea6/classify2.json --- 2.0.2-3/doc/examples/kea6/classify2.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/classify2.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,9 +4,9 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Let's use the simplest backend: memfile and use some reasonable values @@ -70,7 +70,7 @@ "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "client-class": "cable-modems", - "interface": "ethX" + "interface": "eth0" }, // The following subnet contains a class reservation for a client using // DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned @@ -83,7 +83,7 @@ "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "client-classes": [ "cable-modems" ] } ], - "interface": "ethX", + "interface": "eth0", "require-client-classes": [ "second_subnet" ] }, // The following subnet contains a pool with a class constraint: only @@ -91,19 +91,19 @@ { "pools": [ { - "pool": "2001:db8:3::/80", + "pool": "2001:db8:4::/80", "client-class": "cable-modems" } ], "subnet": "2001:db8:4::/64", - "interface": "ethY" + "interface": "eth1" }, // This subnet is divided in two pools for unknown and known // (i.e. which have a reservation) clients. The built-in KNOWN and // UNKNOWN classes are set or not at host reservation lookup (KNOWN if // this returns something, UNKNOWN if this finds nothing) and client -//classes depending on it are evaluated. +// classes depending on it are evaluated. // This happens after subnet selection and before address allocation -//from pools. +// from pools. { "pools": [ { diff -pruN 2.0.2-3/doc/examples/kea6/classify.json 2.2.0-1/doc/examples/kea6/classify.json --- 2.0.2-3/doc/examples/kea6/classify.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/classify.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,9 +4,9 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Let's use the simplest backend: memfile and use some reasonable values @@ -24,10 +24,10 @@ // One packet can belong to zero or more classes. "client-classes": [ -// The first class attempts to match all packets coming in on ethX interface. +// The first class attempts to match all packets coming in on eth0 interface. { "name": "lab", - "test": "pkt.iface == 'ethX'", + "test": "pkt.iface == 'eth0'", "option-data": [{ "name": "dns-servers", "data": "2001:db8::1" @@ -59,7 +59,7 @@ "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "client-class": "cable-modems", - "interface": "ethX" + "interface": "eth0" }, // The following subnet contains a class reservation for a client using @@ -73,7 +73,7 @@ "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "client-classes": [ "cable-modems" ] } ], - "interface": "ethX" + "interface": "eth0" }, // The following subnet contains a pool with a class constraint: only @@ -81,11 +81,11 @@ { "pools": [ { - "pool": "2001:db8:3::/80", + "pool": "2001:db8:4::/80", "client-class": "cable-modems" } ], "subnet": "2001:db8:4::/64", - "interface": "ethY" + "interface": "eth1" } ], diff -pruN 2.0.2-3/doc/examples/kea6/config-backend.json 2.2.0-1/doc/examples/kea6/config-backend.json --- 2.0.2-3/doc/examples/kea6/config-backend.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/config-backend.json 2022-07-26 06:08:02.000000000 +0000 @@ -11,9 +11,9 @@ // either "all" or "server2" will be used by this instance. "server-tag": "server2", - // Kea is told to listen on ethX interface only. + // Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Use memfile lease database backend. diff -pruN 2.0.2-3/doc/examples/kea6/dhcpv4-over-dhcpv6.json 2.2.0-1/doc/examples/kea6/dhcpv4-over-dhcpv6.json --- 2.0.2-3/doc/examples/kea6/dhcpv4-over-dhcpv6.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/dhcpv4-over-dhcpv6.json 2022-07-26 06:08:02.000000000 +0000 @@ -8,7 +8,7 @@ { "interfaces-config": { // Enable unicast - "interfaces": [ "eno33554984/2001:db8:1:1::1" ] + "interfaces": [ "eth0/2001:db8:1::1" ] }, "lease-database": { @@ -23,7 +23,7 @@ "subnet6": [ { "subnet": "2001:db8:1:1::/64", - "interface": "eno33554984", + "interface": "eth0", "pools": [ { "pool": "2001:db8:1:1::1:0/112" } ] } ], diff -pruN 2.0.2-3/doc/examples/kea6/duid.json 2.2.0-1/doc/examples/kea6/duid.json --- 2.0.2-3/doc/examples/kea6/duid.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/duid.json 2022-07-26 06:08:02.000000000 +0000 @@ -25,14 +25,14 @@ "htype": 1 }, -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -56,7 +56,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/global-reservations.json 2.2.0-1/doc/examples/kea6/global-reservations.json --- 2.0.2-3/doc/examples/kea6/global-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/global-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -9,14 +9,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -148,7 +148,7 @@ "delegated-len": 64 } ], - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/ha-hot-standby.json 2.2.0-1/doc/examples/kea6/ha-hot-standby.json --- 2.0.2-3/doc/examples/kea6/ha-hot-standby.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/ha-hot-standby.json 2022-07-26 06:08:02.000000000 +0000 @@ -10,9 +10,9 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Control socket is required for communication between the Control @@ -26,8 +26,8 @@ // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL) and even Cassandra. Those database backends - // require more parameters, like name, host and possibly user and password. + // (MySQL and/or PostgreSQL). Those database backends require more + // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { @@ -63,7 +63,7 @@ "heartbeat-delay": 10000, // Maximum time for partner's response to a heartbeat, after which // failure detection is started. This is specified in milliseconds. - "max-response-delay": 10000, + "max-response-delay": 60000, // The following parameters control how the server detects the // partner's failure. The ACK delay sets the threshold for the // 'secs' field of the received discovers. This is specified in @@ -113,7 +113,7 @@ } ], - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/hooks.json 2.2.0-1/doc/examples/kea6/hooks.json --- 2.0.2-3/doc/examples/kea6/hooks.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/hooks.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,9 +5,9 @@ {"Dhcp6": { -// Kea is told to listen on the ethX interface only. +// Kea is told to listen on the eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Set up the storage for leases. @@ -30,7 +30,7 @@ "user-context": { "charging": true } } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/iPXE.json 2.2.0-1/doc/examples/kea6/iPXE.json --- 2.0.2-3/doc/examples/kea6/iPXE.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/iPXE.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,7 +5,7 @@ // Mandatory part of the config that list interfaces on which // Kea will listen for incoming traffic. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Two classes are migrated form ISC-DHCP example: diff -pruN 2.0.2-3/doc/examples/kea6/leases-expiration.json 2.2.0-1/doc/examples/kea6/leases-expiration.json --- 2.0.2-3/doc/examples/kea6/leases-expiration.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/leases-expiration.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // Note, we're setting the maximum number of row read errors to 100, // (defaults to 0, meaning unlimited). @@ -57,7 +57,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/multiple-options.json 2.2.0-1/doc/examples/kea6/multiple-options.json --- 2.0.2-3/doc/examples/kea6/multiple-options.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/multiple-options.json 2022-07-26 06:08:02.000000000 +0000 @@ -4,14 +4,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" @@ -159,7 +159,7 @@ } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/mysql-reservations.json 2.2.0-1/doc/examples/kea6/mysql-reservations.json --- 2.0.2-3/doc/examples/kea6/mysql-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/mysql-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -46,12 +46,16 @@ "type": "mysql", "reconnect-wait-time": 3000, // expressed in ms "max-reconnect-tries": 3, - "name": "kea", - "user": "kea", - "password": "kea", + "name": "keatest", + "user": "keatest", + "password": "keatest", "host": "localhost", "port": 3306, - "readonly": true + "readonly": true, + "trust-anchor": "my-ca", + "cert-file": "my-cert", + "key-file": "my-key", + "cipher-list": "AES" }, // Define a subnet with a pool of dynamic addresses and a pool of dynamic @@ -72,7 +76,7 @@ "delegated-len": 64 } ], - "interface": "ethX", + "interface": "eth0", "id": 1 } ], diff -pruN 2.0.2-3/doc/examples/kea6/pgsql-reservations.json 2.2.0-1/doc/examples/kea6/pgsql-reservations.json --- 2.0.2-3/doc/examples/kea6/pgsql-reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/pgsql-reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" @@ -48,9 +48,9 @@ "type": "postgresql", "reconnect-wait-time": 3000, // expressed in ms "max-reconnect-tries": 3, - "name": "kea", - "user": "kea", - "password": "kea", + "name": "keatest", + "user": "keatest", + "password": "keatest", "host": "localhost" } ], @@ -73,7 +73,7 @@ "delegated-len": 64 } ], - "interface": "ethX", + "interface": "eth0", "id": 1 } ], diff -pruN 2.0.2-3/doc/examples/kea6/reservations.json 2.2.0-1/doc/examples/kea6/reservations.json --- 2.0.2-3/doc/examples/kea6/reservations.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/reservations.json 2022-07-26 06:08:02.000000000 +0000 @@ -1,20 +1,20 @@ // This is an example configuration file for DHCPv6 server in Kea // that showcases how to do host reservations. It is // assumed that one subnet (2001:db8:1::/64) is available directly -// over ethX interface. A number of hosts have various combinations +// over eth0 interface. A number of hosts have various combinations // of addresses and prefixes reserved for them. { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -74,7 +74,7 @@ "delegated-len": 64 } ], - "interface": "ethX", + "interface": "eth0", // Host reservations. Define several reservations, note that // they are all within the range of the pool of the dynamically diff -pruN 2.0.2-3/doc/examples/kea6/several-subnets.json 2.2.0-1/doc/examples/kea6/several-subnets.json --- 2.0.2-3/doc/examples/kea6/several-subnets.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/several-subnets.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" diff -pruN 2.0.2-3/doc/examples/kea6/shared-network.json 2.2.0-1/doc/examples/kea6/shared-network.json --- 2.0.2-3/doc/examples/kea6/shared-network.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/shared-network.json 2022-07-26 06:08:02.000000000 +0000 @@ -8,9 +8,9 @@ // initial proposal was not best and way to migrate to something else. { "Dhcp6": { - // Kea is told to listen on ethX interface only. + // Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // You also need to tell where to store lease information. @@ -29,7 +29,7 @@ { "pools": [ { "pool": "2001:db8:2::/80" } ], "subnet": "2001:db8:2::/64", - "interface": "ethX" + "interface": "eth0" } ], @@ -114,7 +114,7 @@ // Ignored when reservations-in-subnet is false. "reservations-out-of-pool": false, "subnet": "2001:db8:1::/64", - "pools": [ { "pool": "2001:db8:1:abcd::/64" } ], + "pools": [ { "pool": "2001:db8:1:0:abcd::/80" } ], "valid-lifetime": 40 }, diff -pruN 2.0.2-3/doc/examples/kea6/simple.json 2.2.0-1/doc/examples/kea6/simple.json --- 2.0.2-3/doc/examples/kea6/simple.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/simple.json 2022-07-26 06:08:02.000000000 +0000 @@ -1,19 +1,19 @@ // This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with one IPv6 subnet configured. It is // assumed that one subnet (2001:db8:1::/64 is available directly -// over ethX interface. +// over eth0 interface. { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -37,7 +37,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/kea6/softwire46.json 2.2.0-1/doc/examples/kea6/softwire46.json --- 2.0.2-3/doc/examples/kea6/softwire46.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/softwire46.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,9 +5,9 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // Let's use a Memfile backend to store leases. @@ -32,7 +32,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX", + "interface": "eth0", // Include MAP-E Container option for hosts connected to this subnet. "option-data": [ { diff -pruN 2.0.2-3/doc/examples/kea6/stateless.json 2.2.0-1/doc/examples/kea6/stateless.json --- 2.0.2-3/doc/examples/kea6/stateless.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/stateless.json 2022-07-26 06:08:02.000000000 +0000 @@ -8,7 +8,7 @@ { "Dhcp6": { "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // This is the list of options that will be granted to all clients that ask. diff -pruN 2.0.2-3/doc/examples/kea6/tee-times.json 2.2.0-1/doc/examples/kea6/tee-times.json --- 2.0.2-3/doc/examples/kea6/tee-times.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/tee-times.json 2022-07-26 06:08:02.000000000 +0000 @@ -5,14 +5,14 @@ { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" diff -pruN 2.0.2-3/doc/examples/kea6/with-ddns.json 2.2.0-1/doc/examples/kea6/with-ddns.json --- 2.0.2-3/doc/examples/kea6/with-ddns.json 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/kea6/with-ddns.json 2022-07-26 06:08:02.000000000 +0000 @@ -1,19 +1,19 @@ // This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with one IPv6 subnet configured. It is // assumed that one subnet (2001:db8:1::/64 is available directly -// over ethX interface. +// over eth0 interface. { "Dhcp6": { -// Kea is told to listen on ethX interface only. +// Kea is told to listen on eth0 interface only. "interfaces-config": { - "interfaces": [ "ethX" ] + "interfaces": [ "eth0" ] }, // We need to specify the database used to store leases. As of -// September 2016, four database backends are supported: MySQL, -// PostgreSQL, Cassandra, and the in-memory database, Memfile. +// June 2022, three database backends are supported: MySQL, +// PostgreSQL and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", @@ -37,7 +37,7 @@ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", - "interface": "ethX" + "interface": "eth0" } ], diff -pruN 2.0.2-3/doc/examples/template-power-user-home/info.md 2.2.0-1/doc/examples/template-power-user-home/info.md --- 2.0.2-3/doc/examples/template-power-user-home/info.md 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/template-power-user-home/info.md 2022-07-26 06:08:02.000000000 +0000 @@ -1,20 +1,20 @@ -Template: Home network of a power user +Template: Home Network of a Power User -------------------------------------- -This directory contains template configurations for home network of a power user. It may also be -appropriate for a small office. It makes the following assumptions: +Below are some templates to assist in configuring the home network of a power user; they may also be +appropriate for a small office. These templates make the following assumptions: -- you want to use a single /24 class of IPv4 addresses -- you want High Availability, so there are 2 DHCP servers -- you have a handful of devices, and some of them (e.g. a printer or NAS) require - static addresses or extra options -- you do not want to be bothered with database management -- the setup is optimized for minimal-to-zero maintenance -- performance is not an issue. You do not expect to see 100s of queries per second -- you do not use IPv6 -- you do not want to update your DNS +- the administrator wants to use a single /24 class of IPv4 addresses. +- High Availability is desired, so there are two DHCP servers. +- there are a handful of devices, and some of them (e.g. a printer or NAS) require + static addresses or extra options. +- the administrator does not want to be bothered with database management. +- the setup is optimized for minimal-to-zero maintenance. +- performance is not an issue; hundreds of queries per second are not expected. +- IPv6 is not used. +- DNS updates will not be performed by Kea. -The logical set-up consists of two hosts, each running Kea DHCPv4 server and a Control Agent (CA). +The logical setup consists of two hosts, each running a Kea DHCPv4 server and a Control Agent (CA). The server connects with the CA using UNIX sockets. Each DHCPv4+CA acts as one partner of the HA pair. @@ -32,97 +32,95 @@ pair. +--------+ +--------+ ``` -The CA at host 1 and CA at host 2 will both listen on port 8000. The DHCP servers will communicate -with each other via CAs which forward control commands to the DHCP servers over the UNIX domain +The CA on host-1 and CA on host-2 both listen on port 8000. The DHCP servers communicate +with each other via the CAs, which forward control commands to the DHCP servers over the UNIX domain sockets. Deployment Considerations ~~~~~~~~~~~~~~~~~~~~~~~~~ -The setup is not expected to be very performant. Most modest hardware will do. There are successful -deployments on Raspberry Pi platforms. If you are running a VM, 2GB ram with one CPU core should -be enough. If you don't have any preference, Ubuntu LTS is a choice that is easy to set up and is -low maintenance. However, any Linux or FreeBSD is fine. Less popular systems, such as OpenBSD or -NetBSD should also work in principle, but they are not regularly tested. +The setup is not expected to be very performant; most modest hardware will do. There are successful +deployments on Raspberry Pi platforms. If it is running on a VM, 2GB of RAM with one CPU core should +be enough. Ubuntu LTS is a choice that is easy to set up and is +low maintenance; however, any Linux or FreeBSD operating system is fine. Less popular systems, such as OpenBSD or +NetBSD, should also work in principle, but they are not regularly tested. -The assumption is that there are 2 hosts that will be running the Kea setup: +The assumption is that there are two hosts that are running the Kea setup: -- 192.168.1.2 - primary HA server (active, will handle all the traffic) +- 192.168.1.2 - primary HA server (active, handles all the traffic) -- 192.168.1.3 - secondary HA server (passive, ready to take over in case the primary fails) +- 192.168.1.3 - secondary HA server (passive, ready to take over if the primary fails) -The network is 192.168.1.0/24. It is assumed that 192.168.1.1 is your default router. +The network is 192.168.1.0/24. It is assumed that 192.168.1.1 is the default router. The whole subnet is split into dynamic and static pools: -- 192.168.1.100 - 192.168.1.199 - this is the dynamic pool. When new devices appear in your network, - they will be assigned dynamic addresses from this pool. -- The reservations are done outside of this dynamic range (depending on your addressing preference, +- 192.168.1.100 - 192.168.1.199 - this is the dynamic pool. When new devices appear in the network, + they are assigned dynamic addresses from this pool. +- The reservations are done outside of this dynamic range (depending on the addressing preference, either 192.168.1.1-192.168.1.99 or 192.168.1.200-192.168.1.254). -To deploy this setup, you need to conduct the following steps: +To deploy this setup, conduct the following steps: -1. Install CA and DHCPv4 on host1, copy the config files to the typical locations. It's typically - ``/etc/kea`` on Linux and ``/usr/local/etc/kea`` on FreeBSD. The files are typically called - ``kea-ctrl-agent.conf`` and ``kea-dhcp4.conf``. Please consult your start-up scripts. +1. Install CA and DHCPv4 on host-1, and copy the configuration files to their typical locations. + They are usually in ``/etc/kea`` on Linux and ``/usr/local/etc/kea`` on FreeBSD, and the files are typically called + ``kea-ctrl-agent.conf`` and ``kea-dhcp4.conf``. Please consult the start-up scripts for any specific system. -2. At the very least alter the following to match your setup: +2. Alter the following to match the local setup: - - the interface name which Kea should listen on (``interfaces`` in ``interfaces-config``) + - the interface name that Kea should listen on (``interfaces`` in ``interfaces-config``). - - the interface name which is used to access the subnet (``interface`` in ``subnet4``) + - the interface name that is used to access the subnet (``interface`` in ``subnet4``). - - your addressing, if you use something different than 192.168.1.0/24. Make sure the CA port - configuration (``http-host`` and ``http-port`` in kea-ca.conf) matches your DHCPv4 server - configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in kea-dhcp4.conf). + - the addressing, if using something other than 192.168.1.0/24. Make sure the CA port + configuration (``http-host`` and ``http-port`` in ``kea-ca.conf``) matches the DHCPv4 server + configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in ``kea-dhcp4.conf``). - - tweak your router option to match your actual network + - the router option, to match the actual network. - - tweak your DNS option to match your actual network + - the DNS option, to match the actual network. - - the path to the hook libraries. This is very OS specific parameter. The library names are in - general the same everywhere, but the path varies. See Section 16.2 of the Kea ARM for details. + - the path to the hook libraries. This is a very OS-specific parameter; the library names are + generally the same everywhere, but the path varies. See :ref:`hooks-libraries-introduction` for details. -3. If using a firewall, make sure server1 can reach server2. A nice way to ensure that is to - try to retrieve server2's config from server1: +3. If using a firewall, make sure host-1 can reach host-2. An easy way to ensure that is to + try to retrieve host-2's config from host-1: ``curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://192.168.1.3:8000/`` - You should get a DHCPv4 running configuration in return in a JSON format. + The DHCPv4 running configuration should be returned, in JSON format. -4. Make sure the opposite direction (server2 can connect to server1) works too. Simply repeat - step 3 from the server2 and user server's 1 IP address and port. +4. Verify that communication between the hosts works in the opposite direction as well + (host-2 can connect to host-1), by repeating step 3 from host-2 using host-1's IP address and port. -5. Install CA and DHCPv4 on host2, similar to steps 1 and 2. Note the config file for the - standby server is very similar, except the definition of ``this-server-name`` field - (and possibly inteface names). In many cases you can simply copy over the file - and just tweak it a little bit. +5. Install the CA and DHCPv4 on host-2, as in steps 1 and 2. The config file for the + standby server is very similar to the one on the primary server, other than the definition of + the ``this-server-name`` field (and possibly the interface names). -Possible extensions +Possible Extensions ~~~~~~~~~~~~~~~~~~~ -The proposed configuration is somewhat basic, but functional. Once your setup is up and running, you -may want to consider the following changes: +The proposed configuration is somewhat basic, but functional. Once it is set up and running, administrators +may wish to consider the following changes: -- if you have your own DNS server, you may configure DNS Updates. This requires running a D2 server - (``kea-dhcp-ddns``), which is a nickname for DHCP-DDNS update server. See Section 13 of the Kea ARM - for details. +- if there is a local DNS server, DNS updates can be configured via Kea. This requires running a DHCP-DDNS update server + (``kea-dhcp-ddns``). See :ref:`dhcp-ddns-overview` for details. -- if you want to run Stateful DHCP for IPv6, you will need to run ``kea-dhcp6`` server. Its configuration +- to run Stateful DHCP for IPv6, a ``kea-dhcp6`` server is necessary. Its configuration is very similar to ``kea-dhcp4``, but there are some notable differences: the default gateway is not - configured via DHCPv6 protocol, but via Router Advertisements sent by your router. Also, there is - a concept of Prefix Delegation, which was non-existent in the DHCPv4. See Section 9 of the Kea ARM + configured via the DHCPv6 protocol, but via router advertisements sent by the local router. Also, the + DHCPv6 concept of prefix delegation does not exist in DHCPv4. See :ref:`dhcp6` for details. -- if you want to expand your network, adding MySQL or PostgreSQL database is a popular direction for - growing networks. You can choose to store leases, host reservations and even most of the configuration - in a database. See Section 4 of the Kea ARM and ``lease-database``, ``hosts-database``, and - ``config-control`` parameters in Section 8 of the Kea ARM. - -- if you want to get more insight into how your DHCP server operates, you may use REST API to query - for a lot of run-time statistics or even change your configuration during run-time. You may also - consider deploying Stork, which is a young, but fast growing dashboard for Kea. See Section 22 - of the Kea ARM for pointers. +- to expand the local network, adding a MySQL or PostgreSQL database is a popular solution. + Users can choose to store leases, host reservations, and even most of the configuration + in a database. See :ref:`admin` and the ``lease-database``, ``hosts-database``, and + ``config-control`` parameters in :ref:`dhcp4`. + +- to provide more insight into how the DHCP server operates, Kea's RESTful API can query + for many runtime statistics or even change the configuration during runtime. Users may also + consider deploying Stork, which is a new but quickly developing dashboard for Kea. See :ref:`stork` + for more information. -- you should probably also read Section 23 of the Kea ARM that discusses various trade offs between - convenience and security. +- all Kea users should read :ref:`security`: to learn about various trade-offs between + convenience and security in Kea. diff -pruN 2.0.2-3/doc/examples/template-power-user-home/kea-dhcp4-1.conf 2.2.0-1/doc/examples/template-power-user-home/kea-dhcp4-1.conf --- 2.0.2-3/doc/examples/template-power-user-home/kea-dhcp4-1.conf 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/template-power-user-home/kea-dhcp4-1.conf 2022-07-26 06:08:02.000000000 +0000 @@ -36,8 +36,8 @@ // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL) and even Cassandra. Those database backends - // require more parameters, like name, host and possibly user and password. + // (MySQL and/or PostgreSQL). Those database backends require more + // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { @@ -48,7 +48,7 @@ }, // Let's configure some global parameters. The home network is not very dynamic - // and there's no shortage of addresses, so no need to recycle aggresively. + // and there's no shortage of addresses, so no need to recycle aggressively. "valid-lifetime": 43200, // leases will be valid for 12h "renew-timer": 21600, // clients should renew every 6h "rebind-timer": 32400, // clients should start looking for other servers after 9h diff -pruN 2.0.2-3/doc/examples/template-power-user-home/kea-dhcp4-2.conf 2.2.0-1/doc/examples/template-power-user-home/kea-dhcp4-2.conf --- 2.0.2-3/doc/examples/template-power-user-home/kea-dhcp4-2.conf 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/examples/template-power-user-home/kea-dhcp4-2.conf 2022-07-26 06:08:02.000000000 +0000 @@ -36,8 +36,8 @@ // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases - // (MySQL and/or PostgreSQL) and even Cassandra. Those database backends - // require more parameters, like name, host and possibly user and password. + // (MySQL and/or PostgreSQL). Those database backends require more + // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { @@ -48,7 +48,7 @@ }, // Let's configure some global parameters. The home network is not very dynamic - // and there's no shortage of addresses, so no need to recycle aggresively. + // and there's no shortage of addresses, so no need to recycle aggressively. "valid-lifetime": 43200, // leases will be valid for 12h "renew-timer": 21600, // clients should renew every 6h "rebind-timer": 32400, // clients should start looking for other servers after 9h diff -pruN 2.0.2-3/doc/Makefile.am 2.2.0-1/doc/Makefile.am --- 2.0.2-3/doc/Makefile.am 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/Makefile.am 2022-07-26 06:08:02.000000000 +0000 @@ -4,6 +4,7 @@ EXTRA_DIST = images/kea-logo-100x70.png nobase_dist_doc_DATA = examples/agent/comments.json nobase_dist_doc_DATA += examples/agent/https.json +nobase_dist_doc_DATA += examples/agent/rbac.json nobase_dist_doc_DATA += examples/agent/simple.json nobase_dist_doc_DATA += examples/ddns/all-keys.json nobase_dist_doc_DATA += examples/ddns/all-keys-netconf.json @@ -19,7 +20,6 @@ nobase_dist_doc_DATA += examples/kea4/al nobase_dist_doc_DATA += examples/kea4/all-keys-netconf.json nobase_dist_doc_DATA += examples/kea4/all-options.json nobase_dist_doc_DATA += examples/kea4/backends.json -nobase_dist_doc_DATA += examples/kea4/cassandra.json nobase_dist_doc_DATA += examples/kea4/classify.json nobase_dist_doc_DATA += examples/kea4/classify2.json nobase_dist_doc_DATA += examples/kea4/comments.json @@ -45,7 +45,6 @@ nobase_dist_doc_DATA += examples/kea6/al nobase_dist_doc_DATA += examples/kea6/all-keys-netconf.json nobase_dist_doc_DATA += examples/kea6/all-options.json nobase_dist_doc_DATA += examples/kea6/backends.json -nobase_dist_doc_DATA += examples/kea6/cassandra.json nobase_dist_doc_DATA += examples/kea6/classify.json nobase_dist_doc_DATA += examples/kea6/classify2.json nobase_dist_doc_DATA += examples/kea6/comments.json diff -pruN 2.0.2-3/doc/Makefile.in 2.2.0-1/doc/Makefile.in --- 2.0.2-3/doc/Makefile.in 2022-02-27 22:11:11.000000000 +0000 +++ 2.2.0-1/doc/Makefile.in 2022-07-26 06:08:13.000000000 +0000 @@ -232,11 +232,6 @@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ -BENCHMARK_CPPFLAGS = @BENCHMARK_CPPFLAGS@ -BENCHMARK_INCLUDES = @BENCHMARK_INCLUDES@ -BENCHMARK_LDADD = @BENCHMARK_LDADD@ -BENCHMARK_LDFLAGS = @BENCHMARK_LDFLAGS@ -BENCHMARK_SOURCE = @BENCHMARK_SOURCE@ BOOST_INCLUDES = @BOOST_INCLUDES@ BOOST_LIBS = @BOOST_LIBS@ BOTAN_TOOL = @BOTAN_TOOL@ @@ -246,8 +241,6 @@ CFLAGS = @CFLAGS@ CONTRIB_DIR = @CONTRIB_DIR@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ -CQL_CPPFLAGS = @CQL_CPPFLAGS@ -CQL_LIBS = @CQL_LIBS@ CRYPTO_CFLAGS = @CRYPTO_CFLAGS@ CRYPTO_INCLUDES = @CRYPTO_INCLUDES@ CRYPTO_LDFLAGS = @CRYPTO_LDFLAGS@ @@ -261,7 +254,6 @@ CXXFLAGS = @CXXFLAGS@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ -DISTCHECK_BENCHMARK_CONFIGURE_FLAG = @DISTCHECK_BENCHMARK_CONFIGURE_FLAG@ DISTCHECK_BOOST_CONFIGURE_FLAG = @DISTCHECK_BOOST_CONFIGURE_FLAG@ DISTCHECK_CONTRIB_CONFIGURE_FLAG = @DISTCHECK_CONTRIB_CONFIGURE_FLAG@ DISTCHECK_CRYPTO_CONFIGURE_FLAG = @DISTCHECK_CRYPTO_CONFIGURE_FLAG@ @@ -425,8 +417,8 @@ top_srcdir = @top_srcdir@ SUBDIRS = sphinx devel EXTRA_DIST = images/kea-logo-100x70.png nobase_dist_doc_DATA = examples/agent/comments.json \ - examples/agent/https.json examples/agent/simple.json \ - examples/ddns/all-keys.json \ + examples/agent/https.json examples/agent/rbac.json \ + examples/agent/simple.json examples/ddns/all-keys.json \ examples/ddns/all-keys-netconf.json \ examples/ddns/comments.json examples/ddns/gss-tsig.json \ examples/ddns/sample1.json examples/ddns/template.json \ @@ -436,9 +428,8 @@ nobase_dist_doc_DATA = examples/agent/co examples/kea4/advanced.json examples/kea4/all-keys.json \ examples/kea4/all-keys-netconf.json \ examples/kea4/all-options.json examples/kea4/backends.json \ - examples/kea4/cassandra.json examples/kea4/classify.json \ - examples/kea4/classify2.json examples/kea4/comments.json \ - examples/kea4/config-backend.json \ + examples/kea4/classify.json examples/kea4/classify2.json \ + examples/kea4/comments.json examples/kea4/config-backend.json \ examples/kea4/dhcpv4-over-dhcpv6.json \ examples/kea4/global-reservations.json \ examples/kea4/ha-load-balancing-primary.json \ @@ -455,9 +446,8 @@ nobase_dist_doc_DATA = examples/agent/co examples/kea6/advanced.json examples/kea6/all-keys.json \ examples/kea6/all-keys-netconf.json \ examples/kea6/all-options.json examples/kea6/backends.json \ - examples/kea6/cassandra.json examples/kea6/classify.json \ - examples/kea6/classify2.json examples/kea6/comments.json \ - examples/kea6/config-backend.json \ + examples/kea6/classify.json examples/kea6/classify2.json \ + examples/kea6/comments.json examples/kea6/config-backend.json \ examples/kea6/dhcpv4-over-dhcpv6.json examples/kea6/duid.json \ examples/kea6/global-reservations.json \ examples/kea6/ha-hot-standby.json examples/kea6/hooks.json \ diff -pruN 2.0.2-3/doc/sphinx/api-files.txt 2.2.0-1/doc/sphinx/api-files.txt --- 2.0.2-3/doc/sphinx/api-files.txt 2022-02-27 22:12:25.000000000 +0000 +++ 2.2.0-1/doc/sphinx/api-files.txt 2022-07-26 06:09:13.000000000 +0000 @@ -29,6 +29,8 @@ src/share/api/gss-tsig-key-get.json src/share/api/gss-tsig-list.json src/share/api/gss-tsig-purge-all.json src/share/api/gss-tsig-purge.json +src/share/api/gss-tsig-rekey-all.json +src/share/api/gss-tsig-rekey.json src/share/api/ha-continue.json src/share/api/ha-heartbeat.json src/share/api/ha-maintenance-cancel.json @@ -173,11 +175,15 @@ src/share/api/statistic-sample-count-set src/share/api/status-get.json src/share/api/subnet4-add.json src/share/api/subnet4-del.json +src/share/api/subnet4-delta-add.json +src/share/api/subnet4-delta-del.json src/share/api/subnet4-get.json src/share/api/subnet4-list.json src/share/api/subnet4-update.json src/share/api/subnet6-add.json src/share/api/subnet6-del.json +src/share/api/subnet6-delta-add.json +src/share/api/subnet6-delta-del.json src/share/api/subnet6-get.json src/share/api/subnet6-list.json src/share/api/subnet6-update.json diff -pruN 2.0.2-3/doc/sphinx/arm/acknowledgments.rst 2.2.0-1/doc/sphinx/arm/acknowledgments.rst --- 2.0.2-3/doc/sphinx/arm/acknowledgments.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/acknowledgments.rst 2022-07-26 06:08:02.000000000 +0000 @@ -11,7 +11,7 @@ We thank all the organizations and indiv Kea possible. `Comcast `__ and the Comcast Innovation Fund provided major support for the development of Kea's DHCPv4, DHCPv6, and DDNS modules. Mozilla funded initial work on the -REST API via a MOSS award. +RESTful API via a MOSS award. Kea was initially implemented as a collection of applications within the BIND 10 framework. We thank the founding sponsors of the BIND 10 @@ -19,7 +19,7 @@ project: `Afilias `__, `Nominet `__, `SIDN `__, `JPRS `__, -`CIRA `__; and additional sponsors +and `CIRA `__; and additional sponsors `AFNIC `__, `CNNIC `__, `CZ.NIC `__, `DENIC eG `__, diff -pruN 2.0.2-3/doc/sphinx/arm/admin.rst 2.2.0-1/doc/sphinx/arm/admin.rst --- 2.0.2-3/doc/sphinx/arm/admin.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/admin.rst 2022-07-26 06:08:02.000000000 +0000 @@ -6,8 +6,8 @@ Kea Database Administration .. _kea-database-version: -Databases and Database Version Numbers -====================================== +Databases and Schema Versions +============================= Kea may be configured to use a database as storage for leases or as a source of servers' configurations and host reservations (i.e. static @@ -15,32 +15,30 @@ assignments of addresses, prefixes, opti updated, new database schemas are introduced to facilitate new features and correct discovered issues with the existing schemas. -Each version of Kea expects a particular structure in the backend and -checks for this by examining the version of the database it is using. -Separate version numbers are maintained for the backends, independent of the -version of Kea itself. It is possible that the backend version will stay -the same through several Kea revisions; similarly, it is possible that -the version of the backend may go up several revisions during a single Kea -version upgrade. Versions for each backend are also independent, so an increment in -the MySQL backend version does not imply an increment in that of -PostgreSQL. - -Backend versions are specified in a major.minor format. The minor number -is increased when there are backward-compatible changes introduced: for -example, when a new index is added. It is desirable but not mandatory -to apply such a change; running an older backend version is possible. -(Although, in the example given, running without the new index may -introduce a performance penalty.) On the other hand, the -major number is increased when an incompatible change is introduced: for -example, an extra column is added to a table. If Kea attempts to run on a -backend that is too old (as indicated by a mismatched backend major -version number), it will fail; administrative action is -required to upgrade the backend. +Each version of Kea expects a particular schema structure and checks for this by +examining the version of the database it is using. Separate version numbers are +maintained for the schemas, independent of the version of Kea itself. It is +possible that the schema version will stay the same through several Kea +revisions; similarly, it is possible that the version of the schema may go up +several revisions during a single Kea version upgrade. Versions for each backend +type are also independent, so an increment in the MySQL backend version does not +imply an increment in that of PostgreSQL. + +Schema versions are specified in a major.minor format. For the most recent +versions, the minor version is always zero and only the major version is +incremented. + +Historically, the minor version used to be incremented when backward-compatible +changes were introduced to the schema: for example - when a new index is added. +This was opposed to incrementing the major version which implied an incompatible +schema change: for example - changing the type of an existing column. If Kea +attempts to run on a schema that is too old, as indicated by a mismatched schema +version, it will fail; administrative action is required to upgrade the schema. .. _kea-admin: -The kea-admin Tool -================== +The ``kea-admin`` Tool +====================== To manage the databases, Kea provides the ``kea-admin`` tool. It can initialize a new backend, check its version number, perform a backend @@ -50,43 +48,40 @@ upgrade, and dump lease data to a text f ``backend``. Additional, non-mandatory options may be specified. The currently supported commands are: -- ``db-init`` — Initializes a new database schema. This is useful +- ``db-init`` — initializes a new database schema. This is useful during a new Kea installation. The database is initialized to the latest version supported by the version of the software being installed. -- ``db-version`` — Reports the database backend version number. This +- ``db-version`` — reports the database backend version number. This is not necessarily equal to the Kea version number, as each backend has its own versioning scheme. -- ``db-upgrade`` — Conducts a database schema upgrade. This is +- ``db-upgrade`` — conducts a database schema upgrade. This is useful when upgrading Kea. -- ``lease-dump`` — Dumps the contents of the lease database (for MySQL, - PostgreSQL, or CQL backends) to a CSV (comma-separated values) text - file. The first line of the file contains the column names. This is - meant to be used as a diagnostic tool, so it provides a portable, - human-readable form of the lease data. - -.. note:: +- ``lease-dump`` — dumps the contents of the lease database (for MySQL or + PostgreSQL backends) to a CSV (comma-separated values) text file. - In versions of Kea earlier than 1.6.0, the `db-init`, `db-version`, and - `db-upgrade` commands were named `lease-init`, `lease-version`, and - `lease-upgrade`, respectively. + The first line of the file contains the column names. This can be used + as a way to switch from a database backend to a memfile backend. + Alternatively, it can be used as a diagnostic tool, so it provides a portable + form of the lease data. + +- ``lease-upload`` — uploads leases from a CSV (comma-separated values) text + file to a MySQL or a PostgreSQL lease database. The CSV file needs to be in + memfile format. ``backend`` specifies the type of backend database. The currently supported types are: -- ``memfile`` — Lease information is stored on disk in a text file. +- ``memfile`` — lease information is stored on disk in a text file. -- ``mysql`` — Information is stored in a MySQL relational database. +- ``mysql`` — information is stored in a MySQL relational database. -- ``pgsql`` — Information is stored in a PostgreSQL relational +- ``pgsql`` — information is stored in a PostgreSQL relational database. -- ``cql`` — Information is stored in an Apache Cassandra database. - This backend is deprecated. - Additional parameters may be needed, depending on the setup and specific operation: username, password, and database name or the directory where specific files are located. See the appropriate manual @@ -104,32 +99,32 @@ backend is essential for the success of .. table:: List of available backends - +---------------+----------------+----------------+---------------+--------------+ - | Feature | Memfile | MySQL | PostgreSQL | CQL | - | | | | | (Cassandra) | - +===============+================+================+===============+==============+ - | Status | Stable | Stable | Stable | Deprecated | - | | | | | | - +---------------+----------------+----------------+---------------+--------------+ - | Data format | CSV file | SQL RMDB | SQL RMDB | NoSQL | - | | | | | database | - | | | | | (Cassandra) | - +---------------+----------------+----------------+---------------+--------------+ - | Leases | yes | yes | yes | yes | - +---------------+----------------+----------------+---------------+--------------+ - | Host | no | yes | yes | yes | - | reservations | | | | | - | | | | | | - +---------------+----------------+----------------+---------------+--------------+ - | Options | no | yes | yes | yes | - | defined on | | | | | - | per host | | | | | - | basis | | | | | - +---------------+----------------+----------------+---------------+--------------+ - | Configuration | no | yes | no | no | - | backend | | | | | - | | | | | | - +---------------+----------------+----------------+---------------+--------------+ + +---------------+----------------+----------------+---------------+ + | Feature | Memfile | MySQL | PostgreSQL | + | | | | | + +===============+================+================+===============+ + | Status | Stable | Stable | Stable | + | | | | | + +---------------+----------------+----------------+---------------+ + | Data format | CSV file | SQL RMDB | SQL RMDB | + | | | | | + | | | | | + +---------------+----------------+----------------+---------------+ + | Leases | yes | yes | yes | + +---------------+----------------+----------------+---------------+ + | Host | no | yes | yes | + | reservations | | | | + | | | | | + +---------------+----------------+----------------+---------------+ + | Options | no | yes | yes | + | defined on | | | | + | per host | | | | + | basis | | | | + +---------------+----------------+----------------+---------------+ + | Configuration | no | yes | yes | + | backend | | | | + | | | | | + +---------------+----------------+----------------+---------------+ Memfile ------- @@ -197,9 +192,9 @@ To check the MySQL timezone: To configure the MySQL timezone for a specific server, please refer to the installed version documentation. -Usually the setting is configured in the [mysqld] section in /etc/mysql/my.cnf, -/etc/mysql/mysql.cnf, /etc/mysql/mysqld.cnf, or -/etc/mysql/mysql.conf.d/mysqld.cnf. +Usually the setting is configured in the [mysqld] section in ``/etc/mysql/my.cnf``, +``/etc/mysql/mysql.cnf``, ``/etc/mysql/mysqld.cnf``, or +``/etc/mysql/mysql.conf.d/mysqld.cnf``. .. code-block:: ini @@ -292,7 +287,7 @@ To create the database: mysql> CONNECT database-name; mysql> SOURCE path-to-kea/share/kea/scripts/mysql/dhcpdb_create.mysql - (where "path-to-kea" is the location where Kea is installed.) + (where ``path-to-kea`` is the location where Kea is installed.) The database may also be dropped manually as follows: @@ -301,9 +296,10 @@ To create the database: mysql> CONNECT database-name; mysql> SOURCE path-to-kea/share/kea/scripts/mysql/dhcpdb_drop.mysql - (where "path-to-kea" is the location where Kea is installed.) + (where ``path-to-kea`` is the location where Kea is installed.) .. warning:: + Dropping the database results in the unrecoverable loss of any data it contains. @@ -382,7 +378,7 @@ Improved Performance With MySQL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Changing the MySQL internal value ``innodb_flush_log_at_trx_commit`` from the default value -of ``1`` to ``2`` can result in a huge gain in Kea performance. In some deployments, the +of 1 to 2 can result in a huge gain in Kea performance. In some deployments, the gain was over 1000% (10 times faster when set to 2, compared to the default value of 1). It can be set per-session for testing: @@ -519,7 +515,7 @@ which the servers will access it. A numb COMMIT $ - ("path-to-kea" is the location where Kea is installed.) + (``path-to-kea`` is the location where Kea is installed.) If instead an error is encountered, such as: @@ -590,105 +586,18 @@ Use the following command to perform an $ kea-admin db-upgrade pgsql -u database-user -p database-password -n database-name -.. _cql-database: - -Cassandra ---------- - -Cassandra (sometimes referred to as CQL) is the newest backend added to Kea; initial -development was contributed by Deutsche Telekom. The Cassandra backend -is able to store leases, host reservations, and options defined on a -per-host basis. - -.. note:: - - The Cassandra backend was deprecated in Kea 1.9.9. New users are discouraged from - using Cassandra and existing users should consider a migration strategy. See - :ref:`deprecated` for details. - -.. _cql-database-create: - -First-Time Creation of the Cassandra Database -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -When setting up the Cassandra database for the first time, -the keyspace area within it must be created. This needs to be done -manually; it cannot be performed by ``kea-admin``. - -To create the database: - -1. Export ``CQLSH_HOST`` environment variable: - - .. code-block:: console - - $ export CQLSH_HOST=localhost - -2. Log into CQL: - - .. code-block:: console - - $ cqlsh - cql> - -3. Create the CQL keyspace: - - :: +.. _pgsl-ssl: - cql> CREATE KEYSPACE keyspace-name WITH replication = {'class' : 'SimpleStrategy','replication_factor' : 1}; +PostgreSQL without OpenSSL support +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - (``keyspace-name`` is the name chosen for the keyspace.) - -4. At this point, the database tables can be created. - To do this: - - :: - - cqlsh -k keyspace-name -f path-to-kea/share/kea/scripts/cql/dhcpdb_create.cql - - (path-to-kea is the location where Kea is installed.) - -It is also possible to exit Cassandra and create the tables using -the ``kea-admin`` tool. If the tables were not created in Step 4, do so now by -running the ``kea-admin`` tool: - -.. code-block:: console - - $ kea-admin db-init cql -n database-name - -Do not do this if the tables were created in Step 4. ``kea-admin`` -implements rudimentary checks; it will refuse to initialize a database -that contains any existing tables. To start from scratch, -all data must be removed manually. (This process is a manual operation -on purpose, to avoid accidentally irretrievable mistakes by ``kea-admin``.) - -.. _cql-upgrade: - -Upgrading a Cassandra Database From an Earlier Version of Kea -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Sometimes a new Kea version uses a newer database schema, so the -existing database needs to be upgraded. This can be done using the -``kea-admin db-upgrade`` command. - -To check the current version of the database, use the following command: - -.. code-block:: console - - $ kea-admin db-version cql -n database-name - -(See :ref:`kea-database-version` -for a discussion about versioning.) If the version does not match the -minimum required for the new version of Kea (as described in the release -notes), the database needs to be upgraded. - -Before upgrading, please make sure that the database is backed up. The -upgrade process does not discard any data, but depending on the nature -of the changes, it may be impossible to subsequently downgrade to an -earlier version. To perform an upgrade, issue the following command: +Usually the PostgreSQL database client library is built with the OpenSSL +support but Kea can be configured to handle the case where it is not +supported: .. code-block:: console - $ kea-admin db-upgrade cql -n database-name + $ ./configure [other-options] --disable-pgsql-ssl Using Read-Only Databases With Host Reservations ------------------------------------------------ diff -pruN 2.0.2-3/doc/sphinx/arm/agent.rst 2.2.0-1/doc/sphinx/arm/agent.rst --- 2.0.2-3/doc/sphinx/arm/agent.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/agent.rst 2022-07-26 06:08:02.000000000 +0000 @@ -14,7 +14,7 @@ interface for managing Kea servers. The commands over HTTP and either forward these commands to the respective Kea servers or handle these commands on its own. The determination whether the command should be handled by the CA or forwarded is made by -checking the value of the `service` parameter, which may be included in +checking the value of the ``service`` parameter, which may be included in the command from the controlling client. The details of the supported commands, as well as their structures, are provided in :ref:`ctrl-channel`. @@ -108,7 +108,7 @@ different from the HA peer URLs, which a for internal HA traffic between the peers. User commands should still be sent via CA. -The ``trust-anchor``, ``cert-file``, ```key-file``, and ``cert-required`` +The ``trust-anchor``, ``cert-file``, ``key-file``, and ``cert-required`` parameters specify the TLS setup for HTTP, i.e. HTTPS. If these parameters are not specified, HTTP is used. The TLS/HTTPS support in Kea is described in :ref:`tls`. @@ -135,13 +135,6 @@ for the DHCPv4 server and the CA (for th :ref:`d2-ctrl-channel` to learn how the socket configuration is specified for the DHCPv4, DHCPv6, and D2 services. -.. warning:: - - ``dhcp4-server``, ``dhcp6-server``, and ``d2-server`` were renamed to - ``dhcp4``, ``dhcp6``, and ``d2`` respectively in Kea 1.2. If - migrating from Kea 1.2, be sure to modify the CA configuration to use - this new naming convention. - User contexts can store arbitrary data as long as they are in valid JSON syntax and their top-level element is a map (i.e. the data must be enclosed in curly brackets). Some hook libraries may expect specific @@ -180,6 +173,23 @@ is used. in UTF-8, but the current Kea JSON syntax only supports the Latin-1 (i.e. 0x00..0xff) Unicode subset. +To avoid to expose the password or both the user ID and the associated +password these values can be read from files. The syntax was extended by: + +- The ``directory`` authentication parameter which handles the common + part of file paths. By default the value is the empty string. + +- The``password-file`` client parameter which with the ``directory`` + parameter specifies the path of a file where the password or when no + user ID is given the whole basic HTTP authentication secret before + encoding can be read. + +- The ``user-file`` client parameter which with the ``directory`` parameter + specifies the path of a file where the user ID can be read. + +When files are used they are read when the configuration is loaded in order +to detect configuration errors as soon as possible. + Hook libraries can be loaded by the Control Agent in the same way as they are loaded by the DHCPv4 and DHCPv6 servers. The CA currently supports one hook point - ``control_command_receive`` - which makes it @@ -291,11 +301,9 @@ server enables authentication of the cli } } -.. - .. note:: - Note that the configuration snippet provided above is for testing + The configuration snippet provided above is for testing purposes only. It should be modified according to the security policies and best practices of the administrator's organization. @@ -328,7 +336,7 @@ a boolean parameter: authentication. The file format is PEM. Either all the string parameters are specified and -HTTP over TLS aka HTTPS is used, or none is specified and plain HTTP is used. +HTTP over TLS (HTTPS) is used, or none is specified and plain HTTP is used. Configuring only one or two string parameters results in an error. .. note:: @@ -336,7 +344,7 @@ Configuring only one or two string param When client certificates are not required, only the server side is authenticated, i.e. the communication is encrypted with an unknown client. This protects only against passive attacks; active - attacks, such as "Man in the Middle," are still possible. + attacks, such as "man-in-the-middle," are still possible. .. note:: @@ -359,7 +367,7 @@ file it should use. For example: $ ./kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.conf -It can be started by keactrl as well (see :ref:`keactrl`). +It can be started by ``keactrl`` as well (see :ref:`keactrl`). .. _agent-clients: diff -pruN 2.0.2-3/doc/sphinx/arm/classify.rst 2.2.0-1/doc/sphinx/arm/classify.rst --- 2.0.2-3/doc/sphinx/arm/classify.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/classify.rst 2022-07-26 06:08:02.000000000 +0000 @@ -28,84 +28,108 @@ ways: - Implicitly, using a vendor class option or another built-in condition. -- Using an expression which evaluates to true. +- Using an expression which evaluates to ``true``. - Using static host reservations, a shared network, a subnet, etc. - Using a hook. -It is envisaged that client classification will be used to change the -behavior of almost any part of the DHCP message processing. There are -currently five mechanisms that take advantage of client classification: -subnet selection, pool selection, definition of DHCPv4 private (codes -224-254) and code 43 options, assignment of different options, and, for -DHCPv4 cable modems, the setting of specific options for use with the -TFTP server address and the boot file field. +Client classification can be used to change the behavior of almost any +part of the DHCP message processing. There are currently six +mechanisms that take advantage of client classification: dropping +queries, subnet selection, pool selection, definition of DHCPv4 +private (codes 224-254) and code 43 options, assignment of different +options, and, for DHCPv4 cable modems, the setting of specific options +for use with the TFTP server address and the boot file field. + +.. _classify-classification-steps: + +Classification Steps +-------------------- The classification process is conducted in several steps: -1. The ALL class is associated with the incoming packet. +1. The ``ALL`` class is associated with the incoming packet. 2. Vendor class options are processed. 3. Classes with matching expressions and not marked for later evaluation ("on - request" or depending on the KNOWN/UNKNOWN built-in classes) + request" or depending on the ``KNOWN``/``UNKNOWN`` built-in classes) are processed in the order they are defined in the configuration; the boolean expression is evaluated and, if it - returns true ("match"), the incoming packet is associated with the + returns ``true`` (a match), the incoming packet is associated with the class. 4. If a private or code 43 DHCPv4 option is received, it is decoded - following its client class or global (or, for option 43, last - resort) definition. + following its client-class or global (or, for option 43, + last-resort) definition. -5. When the incoming packet belongs to the special class, `DROP`, it is +5. When the incoming packet belongs to the special class ``DROP``, it is dropped and an informational message is logged with the packet information. -6. A subnet is chosen, possibly based on the class information when +.. note:: + + The ``pkt4_receive`` and ``pkt6_receive`` callouts are called here. + +6. When the ``early-global-reservations-lookup`` global parameter is + configured to true global reservations are looked for and the 8, 9 + and 10 steps are partially performed: the lookup is limited to + global reservations, if one is found the ``KNOWN`` class is set + but if none is found the ``UNKNOWN`` class is **not** set. + +7. A subnet is chosen, possibly based on the class information when some subnets are reserved. More precisely: when choosing a subnet, the server iterates over all of the subnets that are feasible given the information found in the packet (client address, relay address, - etc.). It uses the first subnet it finds that either doesn't have a + etc.). It uses the first subnet it finds that either has no class associated with it, or has a class which matches one of the packet's classes. -7. The server looks for host reservations. If an identifier from the +.. note:: + + The ``subnet4_select`` and ``subnet6_select`` callouts are called here. + +8. The server looks for host reservations. If an identifier from the incoming packet matches a host reservation in the subnet or shared - network, the packet is associated with the KNOWN class and all + network, the packet is associated with the ``KNOWN`` class and all classes of the host reservation. If a reservation is not found, the - packet is assigned to the UNKNOWN class. + packet is assigned to the ``UNKNOWN`` class. -8. Classes with matching expressions - directly, or indirectly using the - KNOWN/UNKNOWN built-in classes and not marked for later evaluation ("on +9. Classes with matching expressions - directly, or indirectly using the + ``KNOWN``/``UNKNOWN`` built-in classes and not marked for later evaluation ("on request") - are processed in the order they are defined in the configuration; the boolean expression is evaluated and, if it - returns true ("match"), the incoming packet is associated with the + returns ``true`` (a match), the incoming packet is associated with the class. After a subnet is selected, the server determines whether there is a reservation for a given client. Therefore, it is not - possible to use KNOWN/UNKNOWN classes to select a shared network or - a subnet. + possible to use the ``UNKNOWN`` class to select a shared network or + a subnet. For the ``KNOWN`` class only global reservations only + global reservations are used and the ``early-global-reservations-lookup`` + parameter must be configured to true -9. When the incoming packet belongs to the special class, `DROP`, it is +10. When the incoming packet belongs to the special class ``DROP``, it is dropped and an informational message is logged with the packet - information. Since Kea version 1.9.8 it is allowed to make DROP - class dependent on KNOWN/UNKNOWN classes. + information. Since Kea version 1.9.8, it is permissible to make the ``DROP`` + class dependent on the ``KNOWN``/``UNKNOWN`` classes. -10. If needed, addresses and prefixes from pools are assigned, possibly +11. If needed, addresses and prefixes from pools are assigned, possibly based on the class information when some pools are reserved for class members. -11. Classes marked as "required" are evaluated in the order in which +.. note:: + + The ``lease4_select``, ``lease4_renew``, ``lease6_select``, ``lease6_renew``, and ``lease6_rebind`` + callouts are called here. + +12. Classes marked as "required" are evaluated in the order in which they are listed: first the shared network, then the subnet, and finally the pools that assigned resources belong to. -12. Options are assigned, again possibly based on the class information +13. Options are assigned, again possibly based on the class information in the order that classes were associated with the incoming packet. - For DHCPv4 private and code 43 options, this includes class local - option definitions. - -.. + For DHCPv4 private and code 43 options, this includes option + definitions specified within classes. .. note:: @@ -117,17 +141,17 @@ When determining which options to includ examines the union of options from all of the assigned classes. If two or more classes include the same option, the value from the first class examined is used; classes are examined in the order they were -associated, so ALL is always the first class and matching required +associated, so ``ALL`` is always the first class and matching required classes are last. As an example, imagine that an incoming packet matches two classes. -Class "foo" defines values for an NTP server (option 42 in DHCPv4) and -an SMTP server (option 69 in DHCPv4), while class "bar" defines values +Class ``foo`` defines values for an NTP server (option 42 in DHCPv4) and +an SMTP server (option 69 in DHCPv4), while class ``bar`` defines values for an NTP server and a POP3 server (option 70 in DHCPv4). The server examines the three options - NTP, SMTP, and POP3 - and returns any that the client requested. As the NTP server was defined twice, the server chooses only one of the values for the reply; the class from which the -value is obtained determined as explained in the previous paragraph. +value is obtained is determined as explained in the previous paragraph. .. note:: @@ -140,36 +164,40 @@ value is obtained determined as explaine Built-in Client Classes ======================= -Some classes are built-in, so they do not need to be defined. The main -example uses Vendor Class information: the server checks whether an +Some classes are built-in, so they do not need to be defined. +Vendor class information is the primary example: the server checks whether an incoming DHCPv4 packet includes the vendor class identifier option (60) or an incoming DHCPv6 packet includes the vendor class option (16). If -it does, the content of that option is prepended with "VENDOR_CLASS\_" +it does, the content of that option is prepended with ``VENDOR_CLASS_`` and the result is interpreted as a class. For example, modern cable -modems send this option with value "docsis3.0", so the packet belongs to -class "VENDOR_CLASS_docsis3.0". +modems send this option with value ``docsis3.0``, so the packet belongs to +class ``VENDOR_CLASS_docsis3.0``. -The "HA\_" prefix is used by the High Availability hooks library to +The ``HA_`` prefix is used by the High Availability hook library to designate certain servers to process DHCP packets as a result of load -balancing. The class name is constructed by prepending the "HA\_" prefix +balancing. The class name is constructed by prepending the ``HA_`` prefix to the name of the server which should process the DHCP packet. This server uses an appropriate pool or subnet to allocate IP addresses (and/or prefixes), based on the assigned client classes. The details can -be found in :ref:`high-availability-library`. +be found in :ref:`hooks-high-availability`. -The BOOTP class is used by the BOOTP hook library to classify and +The ``BOOTP`` class is used by the BOOTP hook library to classify and respond to inbound BOOTP queries. -Other examples are the ALL class, which all incoming packets belong to, -and the KNOWN class, assigned when host reservations exist for a -particular client. By convention, built-in classes' names begin with all +The ``SKIP_DDNS`` class is used by the DDNS-tuning hook library to suppress +DDNS updates on a per client basis. + +Other examples are the ``ALL`` class, to which all incoming packets belong, +and the ``KNOWN`` class, assigned when host reservations exist for a +particular client. By convention, the names of built-in classes begin with all capital letters. -Currently recognized built-in class names are ALL, KNOWN and UNKNOWN, and the -prefixes VENDOR_CLASS\_, HA\_, AFTER\_, and EXTERNAL\_. Although the AFTER\_ -prefix is a provision for an as-yet-unwritten hook, the EXTERNAL\_ -prefix can be freely used; built-in classes are implicitly defined so -they never raise warnings if they do not appear in the configuration. +Currently recognized built-in class names are ``ALL``, ``KNOWN`` and ``UNKNOWN``, +and the prefixes ``VENDOR_CLASS_``, ``HA_``, ``AFTER_``, ``EXTERNAL_``, +``SKIP_DDNS``. Although the ``AFTER_`` prefix is a provision for an +as-yet-unwritten hook, the ``EXTERNAL_`` prefix can be freely used; built-in +classes are implicitly defined so they never raise warnings if they do not +appear in the configuration. .. _classification-using-expressions: @@ -179,9 +207,9 @@ Using Expressions in Classification The expression portion of a classification definition contains operators and values. All values are currently strings; operators take a string or strings and return another string. When all the operations have -completed, the result should be a value of "true" or "false". The packet +completed, the result should be a value of ``true`` or ``false``. The packet belongs to the class (and the class name is added to the list of -classes) if the result is "true". Expressions are written in standard +classes) if the result is ``true``. Expressions are written in standard format and can be nested. Expressions are pre-processed during the parsing of the configuration @@ -200,9 +228,9 @@ Dependencies between classes are also ch dependencies are rejected when the configuration is parsed; an expression can only depend on already-defined classes (including built-in classes) which are evaluated in a previous or the same evaluation phase. -This does not apply to the KNOWN or UNKNOWN classes. +This does not apply to the ``KNOWN`` or ``UNKNOWN`` classes. -.. table:: List of Classification Values +.. table:: List of classification values +-----------------------+-------------------------------+-----------------------+ | Name | Example expression | Example value | @@ -345,71 +373,70 @@ Notes: 0x00000001 instead of 0x1 or 0x01. Also, make sure the value is specified in network order, e.g. 1 is represented as 0x00000001. -- "option[code].hex" extracts the value of the option with the code - "code" from the incoming packet. If the packet doesn't contain the +- ``option[code].hex`` extracts the value of the option with the code + ``code`` from the incoming packet. If the packet does not contain the option, it returns an empty string. The string is presented as a byte string of the option payload, without the type code or length fields. -- "option[code].exists" checks whether an option with the code "code" +- ``option[code].exists`` checks whether an option with the code ``code`` is present in the incoming packet. It can be used with empty options. -- "member('foobar')" checks whether the packet belongs to the client - class "foobar". To avoid dependency loops, the configuration file +- ``member('foobar')`` checks whether the packet belongs to the client + class ``foobar``. To avoid dependency loops, the configuration file parser verifies whether client classes were already defined or are - built-in, i.e., beginning by "VENDOR_CLASS\_", "AFTER\_" (for the - to-come "after" hook) and "EXTERNAL\_" or equal to "ALL", "KNOWN", - "UNKNOWN", etc. - - "known" and "unknown" are shorthand for "member('KNOWN')" and "not - member('KNOWN')". Note that the evaluation of any expression using - directly or indirectly the "KNOWN" class is deferred after the host - reservation lookup (i.e. when the "KNOWN" or "UNKNOWN" partition is + built-in, i.e., beginning with ``VENDOR_CLASS_``, ``AFTER_`` (for the + to-come "after" hook) and ``EXTERNAL_`` or equal to ``ALL``, ``KNOWN``, + ``UNKNOWN``, etc. + + ``known`` and ``unknown`` are shorthand for ``member('KNOWN')`` and ``not + member('KNOWN')``. Note that the evaluation of any expression using + the ``KNOWN`` class (directly or indirectly) is deferred after the host + reservation lookup (i.e. when the ``KNOWN`` or ``UNKNOWN`` partition is determined). -- "relay4[code].hex" attempts to extract the value of the sub-option - "code" from the option inserted as the DHCPv4 Relay Agent Information - (82) option. If the packet doesn't contain a RAI option, or the RAI - option doesn't contain the requested sub-option, the expression +- ``relay4[code].hex`` attempts to extract the value of the sub-option + ``code`` from the option inserted as the DHCPv4 Relay Agent Information + (82) option. If the packet does not contain a RAI option, or the RAI + option does not contain the requested sub-option, the expression returns an empty string. The string is presented as a byte string of the option payload without the type code or length fields. This expression is allowed in DHCPv4 only. -- "relay4" shares the same representation types as "option"; for - instance, "relay4[code].exists" is supported. +- ``relay4`` shares the same representation types as ``option``; for + instance, ``relay4[code].exists`` is supported. -- "relay6[nest]" allows access to the encapsulations used by any DHCPv6 - relays that forwarded the packet. The "nest" level specifies the +- ``relay6[nest]`` allows access to the encapsulations used by any DHCPv6 + relays that forwarded the packet. The ``nest`` level specifies the relay from which to extract the information, with a value of 0 indicating the relay closest to the DHCPv6 server. Negative values - allow specifying relays counted from the DHCPv6 client, -1 indicating - the relay closest to the client. In general, a negative "nest" level is - the same as the number of relays + "nest" level. If the requested - encapsulation doesn't exist, an empty string "" is returned. This + allow relays to be specified counting from the DHCPv6 client, with -1 indicating + the relay closest to the client. If the requested + encapsulation does not exist, an empty string ``""`` is returned. This expression is allowed in DHCPv6 only. -- "relay6[nest].option[code]" shares the same representation types as - "option"; for instance, "relay6[nest].option[code].exists" is +- ``relay6[nest].option[code]`` shares the same representation types as + ``option``; for instance, ``relay6[nest].option[code].exists`` is supported. -- Expressions starting with "pkt4" can be used only in DHCPv4. They +- Expressions starting with ``pkt4`` can be used only in DHCPv4. They allow access to DHCPv4 message fields. -- "pkt6" refers to information from the client request. To access any - information from an intermediate relay use "relay6". "pkt6.msgtype" - and "pkt6.transid" output a 4-byte binary string for the message type - or transaction id. For example the message type SOLICIT will be - "0x00000001" or simply 1 as in "pkt6.msgtype == 1". +- ``pkt6`` refers to information from the client request. To access any + information from an intermediate relay, use ``relay6``. ``pkt6.msgtype`` + and ``pkt6.transid`` output a 4-byte binary string for the message type + or transaction ID. For example, the message type ``SOLICIT`` is + ``0x00000001`` or simply 1, as in ``pkt6.msgtype == 1``. -- Vendor option means the Vendor-Identifying Vendor-Specific Information +- "Vendor option" means the Vendor-Identifying Vendor-Specific Information option in DHCPv4 (code 125; see `Section 4 of RFC - 3925 `__) and + 3925 `__) and the Vendor-Specific Information Option in DHCPv6 (code 17, defined in `Section 21.17 of RFC - 8415 `__). Vendor - class option means Vendor-Identifying Vendor Class Option in DHCPv4 + 8415 `__). "Vendor + class option" means the Vendor-Identifying Vendor Class Option in DHCPv4 (code 124; see `Section 3 of RFC 3925 `__) in DHCPv4 and - Class Option in DHCPv6 (code 16; see `Section 21.16 of RFC + the Class Option in DHCPv6 (code 16; see `Section 21.16 of RFC 8415 `__). Vendor options may have sub-options that are referenced by their codes. Vendor class options do not have sub-options, but rather data chunks, @@ -417,8 +444,8 @@ Notes: chunk, index 1 is for the second data chunk (if present), etc. - In the vendor and vendor-class constructs an asterisk (*) or 0 can be - used to specify a wildcard enterprise-id value, i.e. it will match - any enterprise-id value. + used to specify a wildcard ``enterprise-id`` value, i.e. it will match + any ``enterprise-id`` value. - Vendor Class Identifier (option 60 in DHCPv4) can be accessed using the option[60] expression. @@ -427,20 +454,20 @@ Notes: 8415 `__ allow for multiple instances of vendor options to appear in a single message. The client classification code currently examines the first instance if more - than one appear. For the vendor.enterprise and vendor-class.enterprise + than one appear. For the ``vendor.enterprise`` and ``vendor-class.enterprise`` expressions, the value from the first instance is returned. Please submit a feature request on the `Kea GitLab site `__ to request support for multiple instances. -.. table:: List of Classification Expressions +.. table:: List of classification expressions +-----------------------+-------------------------+-----------------------+ | Name | Example | Description | +=======================+=========================+=======================+ | Equal | 'foo' == 'bar' | Compare the two | | | | values and return | - | | | "true" or "false" | + | | | `true` or `false` | +-----------------------+-------------------------+-----------------------+ | Not | not ('foo' == 'bar') | Logical negation | +-----------------------+-------------------------+-----------------------+ @@ -469,8 +496,12 @@ Notes: | | | a hexadecimal string, | | | | e.g. 0a:1b:2c:3e | +-----------------------+-------------------------+-----------------------+ + | Split | split('foo.bar', '.', 2)| Return the second | + | | | field, splitting on | + | | | dots. | + +-----------------------+-------------------------+-----------------------+ -.. table:: List of Conversion to Text Expressions +.. table:: List of conversion-to-text expressions +-----------------------+---------------------------+------------------------+ | Name | Example | Description | @@ -481,27 +512,27 @@ Notes: | | | IPv6 address in human | | | | readable format | +-----------------------+---------------------------+------------------------+ - | Int8ToText | int8totext (-1) | Represents the 8 bit | + | Int8ToText | int8totext (-1) | Represents the 8-bit | | | | signed integer in text | | | | format | +-----------------------+---------------------------+------------------------+ - | Int16ToText | int16totext (-1) | Represents the 16 bit | + | Int16ToText | int16totext (-1) | Represents the 16-bit | | | | signed integer in text | | | | format | +-----------------------+---------------------------+------------------------+ - | Int32ToText | int32totext (-1) | Represents the 32 bit | + | Int32ToText | int32totext (-1) | Represents the 32-bit | | | | signed integer in text | | | | format | +-----------------------+---------------------------+------------------------+ - | UInt8ToText | uint8totext (255) | Represents the 8 bit | + | UInt8ToText | uint8totext (255) | Represents the 8-bit | | | | unsigned integer in | | | | text format | +-----------------------+---------------------------+------------------------+ - | UInt16ToText | uint16totext (65535) | Represents the 16 bit | + | UInt16ToText | uint16totext (65535) | Represents the 16-bit | | | | unsigned integer in | | | | text format | +-----------------------+---------------------------+------------------------+ - | UInt32ToText | uint32totext (4294967295) | Represents the 32 bit | + | UInt32ToText | uint32totext (4294967295) | Represents the 32-bit | | | | unsigned integer in | | | | text format | +-----------------------+---------------------------+------------------------+ @@ -511,30 +542,31 @@ Notes: The conversion operators can be used to transform data from binary to the text representation. The only requirement is that the input data type length matches an expected value. -The AddressToText token expects 4 bytes for IPv4 addresses or 16 bytes for IPv6 -addresses. The Int8ToText and UInt8ToText expect 1 byte, the Int16ToText and -UInt16ToText expect 2 bytes and Int32ToText and UInt32ToText expect 4 bytes. + +The ``AddressToText`` token expects 4 bytes for IPv4 addresses or 16 bytes for IPv6 +addresses. The ``Int8ToText`` and ``UInt8ToText`` tokens expect 1 byte, the ``Int16ToText`` and +``UInt16ToText`` tokens expect 2 bytes, and ``Int32ToText`` and ``UInt32ToText`` expect 4 bytes. For all conversion tokens, if the data length is 0, the result string is empty. -Logical operators +Logical Operators ----------------- The Not, And, and Or logical operators are the common operators. Not has the highest precedence and Or the lowest. And and Or are (left) associative. Parentheses around a logical expression can be used to -enforce a specific grouping; for instance, in "A and (B or C)" (without -parentheses "A and B or C" means "(A and B) or C"). +enforce a specific grouping; for instance, in "A and (B or C)". Without +parentheses, "A and B or C" means "(A and B) or C". Substring --------- -The substring operator "substring(value, start, length)" accepts both +The substring operator ``substring(value, start, length)`` accepts both positive and negative values for the starting position and the length. -For "start", a value of 0 is the first byte in the string while -1 is +For ``start``, a value of 0 is the first byte in the string while -1 is the last byte. If the starting point is outside of the original string -an empty string is returned. "length" is the number of bytes to extract. +an empty string is returned. ``length`` is the number of bytes to extract. A negative number means to count towards the beginning of the string but -does not include the byte pointed to by "start". The special value "all" +does not include the byte pointed to by ``start``. The special value ``all`` means to return all bytes from start to the end of the string. If the length is longer than the remaining portion of the string, then the entire remaining portion is returned. Some examples may be helpful: @@ -553,13 +585,13 @@ remaining portion is returned. Some exam Concat ------ -The concat function "concat(string1, string2)" returns the concatenation +The concat function ``concat(string1, string2)`` returns the concatenation of its two arguments. For instance: :: concat('foo', 'bar') == 'foobar' -For user convenience Kea version 1.9.8 added an associative operator +For user convenience, Kea version 1.9.8 added an associative operator version of the concat function. For instance: :: @@ -580,11 +612,30 @@ or: 'abcdefghijkl...' +Split +--------- + +The Split operator ``split(value, delimiters, field-number)`` accepts a list +of characters to use as delimiters and a positive field number of the +desired field when the value is split into fields separated by the delimiters. +Adjacent delimiters are not compressed out, rather they result in an empty +string for that field number. If value is an empty string, the result will be an +empty string. If the delimiters list is empty, the result will be the original +value. If the field-number is less than one or larger than the number of +fields, the result will be an empty string. Some examples follow: +:: + + split ('one.two..four', '.', 1) == 'one' + split ('one.two..four', '.', 2) == 'two' + split ('one.two..four', '.', 3) == '' + split ('one.two..four', '.', 4) == 'four' + split ('one.two..four', '.', 5) == '' + Ifelse ------ -The ifelse function "ifelse(cond, iftrue, ifelse)" returns the "iftrue" -or "ifelse" branch value following the boolean condition "cond". For +The ifelse function ``ifelse(cond, iftrue, ifelse)`` returns the ``iftrue`` +or ``ifelse`` branch value following the boolean condition ``cond``. For instance: :: @@ -594,16 +645,14 @@ instance: Hexstring --------- -The hexstring function "hexstring(binary, separator)" returns the binary +The hexstring function ``hexstring(binary, separator)`` returns the binary value as its hexadecimal string representation: pairs of hexadecimal -digits separated by the separator, e.g ':', '-', '' (empty separator). +digits separated by the separator, e.g ``':'``, ``'-'``, ``''`` (empty separator). :: hexstring(pkt4.mac, ':') -.. - .. note:: The expression for each class is executed on each packet received. If @@ -618,13 +667,13 @@ Configuring Classes =================== A class contains five items: a name, a test expression, option data, -an option definition, and an only-if-required flag. The name must exist and +an option definition, and an ``only-if-required`` flag. The name must exist and must be unique among all classes. The test expression, option data and -definition, and only-if-required flag are optional. +definition, and ``only-if-required`` flag are optional. The test expression is a string containing the logical expression used to determine membership in the class. The entire expression is in double -quotes. +quotes ("). The option data is a list which defines any options that should be assigned to members of this class. @@ -635,23 +684,23 @@ The option definition is for DHCPv4 opti Usually the test expression is evaluated before subnet selection, but in some cases it is useful to evaluate it later when the subnet, -shared network, or pools are known but output option processing has not yet -been done. The only-if-required flag, false by default, allows the +shared network, or pools are known but output-option processing has not yet +been done. The ``only-if-required`` flag, which is ``false`` by default, allows the evaluation of the test expression only when it is required, i.e. in a -require-client-classes list of the selected subnet, shared network, or +``require-client-classes`` list of the selected subnet, shared network, or pool. -The require-client-classes list which is valid for shared-network, -subnet, and pool scope specifies the classes which are evaluated in the -second pass before output option processing. The list is built in the +The ``require-client-classes`` list, which is valid for shared-network, +subnet, and pool scope, specifies the classes which are evaluated in the +second pass before output-option processing. The list is built in the reversed precedence order of option data, i.e. an option data item in a subnet takes precedence over one in a shared network, but required class in a subnet is added after one in a shared network. The mechanism is -related to the only-if-required flag but it is not mandatory that the -flag be set to true. +related to the ``only-if-required`` flag but it is not mandatory that the +flag be set to ``true``. In the following example, the class named "Client_foo" is defined. It is -comprised of all clients whose client ids (option 61) start with the +comprised of all clients whose client IDs (option 61) start with the string "foo". Members of this class will be given 192.0.2.1 and 192.0.2.2 as their domain name servers. @@ -677,11 +726,11 @@ string "foo". Members of this class will ... } -This example shows a client class being defined for use by the DHCPv6 +The next example shows a client class being defined for use by the DHCPv6 server. In it the class named "Client_enterprise" is defined. It is comprised of all clients whose client identifiers start with the given -hex string (which would indicate a DUID based on an enterprise id of -0xAABBCCDD). Members of this class will be given an 2001:db8:0::1 and +hex string (which would indicate a DUID based on an enterprise ID of +0xAABBCCDD). Members of this class will be given 2001:db8:0::1 and 2001:db8:2::1 as their domain name servers. :: @@ -708,27 +757,34 @@ hex string (which would indicate a DUID .. _classification-using-host-reservations: -Using Static Host Reservations In Classification +Using Static Host Reservations in Classification ================================================ Classes can be statically assigned to the clients using techniques described in :ref:`reservation4-client-classes` and :ref:`reservation6-client-classes`. +Subnet host reservations are searched after subnet selection. +Global host reservations are searched at the same time by default but +the ``early-global-reservations-lookup`` allows to change this behavior +into searching them before the subnet selection. + +Pool selection is performed after all host reservations lookups. + .. _classification-subnets: Configuring Subnets With Class Information ========================================== In certain cases it is beneficial to restrict access to certain subnets -only to clients that belong to a given class, using the "client-class" +only to clients that belong to a given class, using the ``client-class`` keyword when defining the subnet. Let's assume that the server is connected to a network segment that uses the 192.0.2.0/24 prefix. The administrator of that network has decided -that addresses from the range 192.0.2.10 to 192.0.2.20 are going to be +that addresses from the range 192.0.2.10 to 192.0.2.20 will be managed by the DHCP4 server. Only clients belonging to client class -Client_foo are allowed to use this subnet. Such a configuration can be +"Client_foo" are allowed to use this subnet. Such a configuration can be achieved in the following way: :: @@ -762,7 +818,7 @@ achieved in the following way: } The following example shows how to restrict access to a DHCPv6 subnet. This -configuration will restrict use of the addresses 2001:db8:1::1 to +configuration restricts use of the addresses in the range 2001:db8:1::1 to 2001:db8:1::FFFF to members of the "Client_enterprise" class. :: @@ -801,13 +857,13 @@ Configuring Pools With Class Information Similar to subnets, in certain cases access to certain address or prefix pools must be restricted to only clients that belong to a given class, -using the "client-class" when defining the pool. +using the ``client-class`` when defining the pool. Let's assume that the server is connected to a network segment that uses the 192.0.2.0/24 prefix. The administrator of that network has decided that addresses from the range 192.0.2.10 to 192.0.2.20 are going to be managed by the DHCP4 server. Only clients belonging to client class -Client_foo are allowed to use this pool. Such a configuration can be +"Client_foo" are allowed to use this pool. Such a configuration can be achieved in the following way: :: @@ -845,7 +901,7 @@ achieved in the following way: } The following example shows how to restrict access to an address pool. This -configuration will restrict use of the addresses 2001:db8:1::1 to +configuration restricts use of the addresses in the range 2001:db8:1::1 to 2001:db8:1::FFFF to members of the "Client_enterprise" class. :: @@ -890,10 +946,10 @@ Currently classes can be used for two fu to members of the class, and they can be used to choose a subnet from which an address will be assigned to a class member. -When supplying options, options defined as part of the class definition -are considered "class globals." They will override any global options -that may be defined and in turn will be overridden by any options -defined for an individual subnet. +When options are defined as part of the class definition +they override any global options that may be defined, and +in turn will be overridden by any options defined for an +individual subnet. Classes and Hooks ================= @@ -914,21 +970,20 @@ it useful to enable logging; see :ref:`l description of the logging facility. To enable the debug statements in the classification system, -the severity must be set to "DEBUG" and the debug level to at least 55. -The specific loggers are "kea-dhcp4.eval" and "kea-dhcp6.eval". +the severity must be set to ``DEBUG`` and the debug level to at least 55. +The specific loggers are ``kea-dhcp4.eval`` and ``kea-dhcp6.eval``. -To understand the logging statements, it is essential to understand a bit -about how expressions are evaluated; for a more complete description, -refer to the design document at -https://gitlab.isc.org/isc-projects/kea/wikis/designs/Design-documents. In -brief, there are two structures used during the evaluation of an +To understand the logging statements, it is essential to understand a bit about +how expressions are evaluated; for a more complete description, refer to +[the design document](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classification-design). +In brief, there are two structures used during the evaluation of an expression: a list of tokens which represent the expressions, and a value stack which represents the values being manipulated. The list of tokens is created when the configuration file is processed, with most expressions and values being converted to a token. The list is -organized in reverse Polish notation. During execution, the list will be -traversed in order; as each token is executed it will be able to pop +organized in reverse Polish notation. During execution, the list is +traversed in order; as each token is executed, it is able to pop values from the top of the stack and eventually push its result on the top of the stack. Imagine the following expression: @@ -944,21 +999,21 @@ This will result in the following tokens option, number (0), number (3), substring, text ('foo'), equals -In this example the first three tokens will simply push values onto the +In this example, the first three tokens will simply push values onto the stack. The substring token will then remove those three values and compute a result that it places on the stack. The text option also -places a value on the stack and finally the equals token removes the two +places a value on the stack, and finally the equals token removes the two tokens on the stack and places its result on the stack. -When debug logging is enabled, each time a token is evaluated it will -emit a log message indicating the values of any objects that were popped -off of the value stack and any objects that were pushed onto the value +When debug logging is enabled, each time a token is evaluated it +emits a log message indicating the values of any objects that were popped +off of the value stack, and any objects that were pushed onto the value stack. -The values will be displayed as either text, if the command is known to +The values are displayed as either text, if the command is known to use text values, or hexadecimal, if the command either uses binary values or can manipulate either text or binary values. For expressions that pop -multiple values off the stack, the values will be displayed in the order +multiple values off the stack, the values are displayed in the order they were popped. For most expressions this will not matter, but for the concat expression the values are displayed in reverse order from their written order in the expression. @@ -983,15 +1038,12 @@ The logging might then resemble this: 2016-05-19 13:35:04.167 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string 'foo' 2016-05-19 13:35:04.168 DEBUG [kea.eval/44478] EVAL_DEBUG_EQUAL Popping 0x666F6F and 0x666F6F pushing result 'true' - -.. - .. note:: - The debug logging may be quite verbose if there are a number of - expressions to evaluate; that is intended as an aid in helping + The debug logging may be quite verbose if there are multiple + expressions to evaluate; it is intended as an aid in helping create and debug expressions. Administrators should plan to disable debug - logging when the expressions are working correctly. Users may also + logging when expressions are working correctly. Users may also wish to include only one set of expressions at a time in the configuration file while debugging them, to limit the log statements. For example, when adding a new set of expressions, an administrator diff -pruN 2.0.2-3/doc/sphinx/arm/config-backend.rst 2.2.0-1/doc/sphinx/arm/config-backend.rst --- 2.0.2-3/doc/sphinx/arm/config-backend.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/config-backend.rst 2022-07-26 06:08:02.000000000 +0000 @@ -8,27 +8,31 @@ Kea Configuration Backend Applicability ------------- -Kea Configuration Backend (CB or config backend) is a feature, first -introduced in Kea 1.6.0, that gives Kea servers the ability +Kea Configuration Backend (CB or config backend) gives Kea servers the ability to manage and fetch their configuration from one or more databases. In this documentation, the term "Configuration Backend" may also refer to the particular Kea module providing support to manage and fetch the -configuration information from the particular database type. For -example, MySQL Configuration Backend is the logic implemented within the +configuration information from the particular database type. For +example, the MySQL Configuration Backend is the logic implemented within the ``mysql_cb`` hook library, which provides a complete set of functions to manage and fetch the configuration information from the MySQL database. +The PostgreSQL Configuration Backend is the logic implemented within the +``pgsql_cb`` hook library, which provides a complete set of functions to +manage and fetch the configuration information from the PostgreSQL database. +From herein, the term "database" is used to refer to either a MySQL or +PostgreSQL database. In small deployments, e.g. those comprising a single DHCP server instance with limited and infrequently changing number of subnets, it may be impractical to use the CB as a configuration repository because it requires additional third-party software to be installed and -configured - in particular the MySQL server and MySQL client. Once the -number of DHCP servers and/or the number of managed subnets in the +configured - in particular the database server, client and libraries. +Once the number of DHCP servers and/or the number of managed subnets in the network grows, the usefulness of the CB becomes obvious. One use case for the CB is a pair of Kea DHCP servers that are configured to support High Availability as described in -:ref:`high-availability-library`. The configurations of both servers +:ref:`hooks-high-availability`. The configurations of both servers (including the value of the ``server-tag`` parameter) are almost exactly the same: they may differ by the server identifier and designation of the server as a primary or standby (or secondary), and/or @@ -68,18 +72,18 @@ CB Capabilities and Limitations Currently, the Kea CB has the following limitations: -- It is only supported for the MySQL database. +- It is only supported for MySQL and PostgreSQL databases. -- It is only supported for the DHCPv4 and DHCPv6 daemons; the Control Agent, D2 daemon, and - the NETCONF daemon cannot be configured from the database, +- It is only supported for the DHCPv4 and DHCPv6 daemons; the Control Agent, + D2 daemon, and the NETCONF daemon cannot be configured from the database, - Only certain DHCP configuration parameters can be set in the database: global parameters, option definitions, global options, client classes, shared networks, and subnets. Other configuration parameters must be sourced from a JSON configuration file. -Kea CB stores data in a MySQL schema that is public. It is possible to -insert configuration data into the MySQL tables manually or automatically +Kea CB stores data in a schema that is public. It is possible to +insert configuration data into the tables manually or automatically using SQL scripts, but this requires SQL and schema knowledge. The supported method for managing the data is through the ``cb-cmds`` hook library, which provides management commands for config backends. It simplifies many @@ -96,7 +100,10 @@ Appendix A of this manual for a complete at https://www.isc.org/contact. -The schema creation script can be found at `dhcpdb_create.mysql `__; +The schema creation scripts can be found at `dhcpdb_create.mysql `__ and +; +`dhcpdb_create.pgsql `__ and +; other related design documents are stored in our GitLab: `CB Design `__ and `Client Classes in CB Design `__. @@ -155,28 +162,32 @@ in two independent configuration sources CB Components ------------- -Kea 1.6.0 version or later is required to use the configuration backend. -The ``mysql_cb`` open source hook library implementing the configuration -backend for MySQL must be compiled and loaded by the DHCP servers. This -hook library is compiled when the ``--with-mysql`` configuration switch -is used during the Kea build. The MySQL C client libraries must be -installed, as explained in :ref:`dhcp-install-configure`. +To use a MySQL configuration backend you must compile the ``mysql_cb`` open +source hook library and configure the DHCP servers to load it. It is compiled when +the ``--with-mysql`` configuration switch is used during the Kea build. The MySQL +C client libraries must be installed, as explained in :ref:`dhcp-install-configure`. + +To use a PostgreSQL configuration backend you must compile the ``pgsql_cb`` open +source hook library and configure the DHCP servers to load it. It is compiled when +the ``--with-pgsql`` configuration switch is used during the Kea build. The PostgreSQL +C client libraries must be installed, as explained in :ref:`dhcp-install-configure`. .. note:: - Any existing MySQL schema must be upgraded to the latest schema + An existing database schema must be upgraded to the latest schema required by the particular Kea version using the ``kea-admin`` tool, as described in :ref:`kea-admin`. The ``cb_cmds`` premium hook library, which is available to ISC's paid support customers, provides a complete set of commands to manage the servers' configuration information within the database. This library can -be attached to both DHCPv4 and DHCPv6 server instances. It is +be attached to both DHCPv4 and DHCPv6 server instances. While it is possible to manage the configuration information without the ``cb_cmds`` hook library with commonly available tools, such as MySQL Workbench or -the command-line MySQL client, by directly working with the database. +the command-line MySQL client, or by directly working with the database; +these avenues are neither recommended nor supported. -Refer to :ref:`cb-cmds-library` for the details regarding the +Refer to :ref:`hooks-cb-cmds` for the details regarding the ``cb_cmds`` hook library. The DHCPv4 and DHCPv6 server-specific configurations of the CB, as well as diff -pruN 2.0.2-3/doc/sphinx/arm/config.rst 2.2.0-1/doc/sphinx/arm/config.rst --- 2.0.2-3/doc/sphinx/arm/config.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/config.rst 2022-07-26 06:08:02.000000000 +0000 @@ -53,6 +53,16 @@ Kea components use extended JSON with ad - File inclusion: JSON files can include other JSON files by using a statement of the form \. +- Extra commas: to remove the inconvenience of errors caused by leftover commas + after making changes to configuration. While parsing, a warning is printed + with the location of the comma to give the user the ability to correct a + potential mistake. + +.. warning:: + + These features are meant to be used in a JSON configuration file. + Their usage in any other way may result in errors. + The configuration file consists of a single object (often colloquially called a map) started with a curly bracket. It comprises only one of the "Dhcp4", "Dhcp6", "DhcpDdns", "Control-agent", or "Netconf" objects. @@ -91,19 +101,6 @@ A very simple configuration for DHCPv4 c More examples are available in the installed ``share/doc/kea/examples`` directory. - .. note:: - - As of Kea 1.6.0, the "Logging" element was removed and its contents (the - "loggers" object) moved inside the configuration objects (maps) for the - respective Kea modules. For example, the "Dhcp4" map contains the - "loggers" object, specifying logging configuration for the DHCPv4 - server. Support for the top-level "Logging" object was - removed in Kea 1.7.10. - - The specification for supporting several elements (e.g. "Dhcp4", "Dhcp6") - in one file was removed in Kea 1.7.10, so each component - now requires a separate configuration file. - To avoid repetition of mostly similar structures, examples in the rest of this guide will showcase only the subset of parameters appropriate for a given context. For example, when discussing the IPv6 subnets @@ -186,7 +183,78 @@ configuration. It is not uncommon for a The best way to avoid this problem is simply to abandon JSON comments and use user-context. -For a discussion about user-context used in hooks, see :ref:`user-context-hooks`. +Kea supports user contexts at the following levels: global scope, +interfaces configuration, shared networks, +subnets, client classes, option data and definitions, host +reservations, control socket, DHCP-DDNS, loggers, leases, and server ID. These +are supported in both DHCPv4 and DHCPv6, with the exception of server ID, +which is DHCPv6 only. + +User context can be added and edited in structures supported by commands. + +We encourage Kea users to utilize these functions to store information +used by other systems and custom hooks. + +For example, the `subnet4-update` command can be used to add user context data +to an existing subnet. + +:: + + "subnet4": [ { + "id": 1, + "subnet": "10.20.30.0/24", + "user-context": { + "building": "Main" + "floor": 1 + } + } ] + +The same can be done with many other commands like lease6-add etc. + +Kea also uses user context to store non-standard data. +Currently, only :ref:`dhcp4-store-extended-info` uses this feature. + +When enabled, it adds the ISC key in `user-context` to differentiate automatically +added content. + +Example of relay information stored in a lease: + +:: + + { + "arguments": { + "client-id": "42:42:42:42:42:42:42:42", + "cltt": 12345678, + "fqdn-fwd": false, + "fqdn-rev": true, + "hostname": "myhost.example.com.", + "hw-address": "08:08:08:08:08:08", + "ip-address": "192.0.2.1", + "state": 0, + "subnet-id": 44, + "valid-lft": 3600 + "user-context": { + "ISC": { + "relays": [ + { + "hop": 2, + "link": "2001:db8::1", + "peer": "2001:db8::2" + }, + { + "hop": 1, + "link": "2001:db8::3", + "options": "0x00C800080102030405060708", + "peer": "2001:db8::4" + }] + } + } + } + + +User context can store configuration for multiple hooks and comments at once. + +For a discussion about user context used in hooks, see :ref:`user-context-hooks`. Simplified Notation diff -pruN 2.0.2-3/doc/sphinx/arm/config-templates.rst 2.2.0-1/doc/sphinx/arm/config-templates.rst --- 2.0.2-3/doc/sphinx/arm/config-templates.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/config-templates.rst 2022-07-26 06:08:02.000000000 +0000 @@ -3,13 +3,14 @@ Configuration Templates ======================= -The following sections include configuration templates that are proposed configuration for -certain deployment types. The example configuration files are also available in the Kea sources -in the `doc/examples` directory. +The following sections include configuration templates for +certain deployment types. The example configuration files are also available in the Kea sources, +in the ``doc/examples`` directory. .. include:: template-power-user-home.md -At the very least, the lines marked in yellow must be adjusted to match the actual deployment. +Some tweaking of these templates may be required to match specific system needs: at a +minimum, the lines highlighted in yellow must be adjusted to match the actual deployment. Server1's Control Agent configuration file: diff -pruN 2.0.2-3/doc/sphinx/arm/congestion-handling.rst 2.2.0-1/doc/sphinx/arm/congestion-handling.rst --- 2.0.2-3/doc/sphinx/arm/congestion-handling.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/congestion-handling.rst 2022-07-26 06:08:02.000000000 +0000 @@ -18,33 +18,22 @@ continue to retry forever. In the former recover, but the latter case is a vicious cycle from which the server is unable to escape. -In a well-planned deployment, the number and capacity of servers is -matched to the maximum client loads expected. As long as capacity is -matched to load, congestion does not occur. If the load is routinely too -heavy, then the deployment needs to be re-evaluated. Congestion -typically occurs when there is a network event that causes overly large +Congestion typically occurs when there is a network event that causes overly large numbers of clients to simultaneously need leases, such as recovery after -a network outage. +a network outage. In a well-planned deployment, the number and capacity of servers is +matched to the maximum expected client load. If the load is routinely too +heavy, then the deployment needs to be re-evaluated. The goal of congestion handling is to help servers mitigate the peak in traffic by fulfilling as many of the most relevant requests as possible until the congestion subsides. -Prior to Kea 1.5, kea-dhcp4 and kea-dhcp6 read inbound packets directly -from the interface sockets in the main application thread, which meant -that packets waiting to be processed were held in socket buffers -themselves. Once these buffers filled, any new packets were discarded. -Under swamped conditions, the servers ended up processing client packets -that were no longer relevant, or worse, were redundant. In other words, -the packets waiting in the FIFO socket buffers became increasingly -stale. - .. _congestion-handling-solution: Configuring Congestion Handling =============================== -Kea 1.5 introduced the Congestion Handling feature. Congestion handling +Congestion handling offers the ability to configure the server to use a separate thread to read packets from the interface socket buffers. As the thread reads packets from the buffers, they are added to an internal packet queue, @@ -54,26 +43,26 @@ configurable layer has been introduced w packets to process, how to store them, and the order in which they are processed by the server. -The default packet queue implementation for both kea-dhcp4 and kea-dhcp6 +The default packet queue implementation for both ``kea-dhcp4`` and ``kea-dhcp6`` is a simple ring buffer. Once it reaches capacity, new packets get added to the back of the queue by discarding packets from the front of the queue. Rather than always discarding the newest packets, Kea now always discards the oldest packets. The capacity of the buffer, i.e. the maximum number of packets the buffer can contain, is configurable. A reasonable -starting point would be to match the capacity to the number of leases -per second a specific installation of Kea can handle. Please note that this +starting point is to match the capacity to the number of leases +per second a specific installation of Kea can handle. This figure varies widely depending on the specifics of an individual deployment. -As there is no one algorithm that will best handle the dynamics of all +As there is no one algorithm that can best handle the dynamics of all sites, and because over time new approaches will evolve, the packet queue is implemented as a plug-in, which can be replaced by a custom queue implementation via a hook library. This should make it straightforward for interested parties to experiment with their own solutions. -(Developers can refer to isc::dhcp::PacketQueue and -isc::dhcp::PacketQueueMgr, described in the +(Developers can refer to ``isc::dhcp::PacketQueue`` and +``isc::dhcp::PacketQueueMgr``, described in the `Kea Developer's Guide `__.) -Packet queue behavior is configured in both kea-dhcp4 and kea-dhcp6 +Packet queue behavior is configured in both ``kea-dhcp4`` and ``kea-dhcp6`` servers through an optional, top-level, configuration element, ``dhcp-queue-control``. Omitting this element disables packet queueing: @@ -87,24 +76,24 @@ servers through an optional, top-level, where: -- ``enable-queue`` true|false - enables or disables packet queueing. - When true, the server processes packets from the packet queue, which - is filled by a separate thread. When false, the server processes +- ``enable-queue`` - enables or disables packet queueing. + When ``true``, the server processes packets from the packet queue, which + is filled by a separate thread. When ``false``, the server processes packets directly from the socket buffers in the main thread. It is - disabled by default. + disabled (``false``) by default. -- ``queue-type`` - name of the queue implementation to use. This value +- ``queue-type`` - the name of the queue implementation to use. This value exists so that custom implementations can be registered (via a hook library) and then selected. There is a default packet queue implementation that is pre-registered during server start up: - "kea-ring4" for kea-dhcp4 and "kea-ring6" for kea-dhcp6. + "kea-ring4" for ``kea-dhcp4`` and "kea-ring6" for ``kea-dhcp6``. -- ``capacity`` = n [packets] - this is the maximum number of packets the +- ``capacity`` - this is the maximum number of packets the queue can hold before packets are discarded. The optimal value for this is extremely site-dependent. The default value is 64 for both - kea-ring4 and kea-ring6. + "kea-ring4" and "kea-ring6". -The following example enables the default packet queue for kea-dhcp4, +The following example enables the default packet queue for ``kea-dhcp4``, with a queue capacity of 250 packets: :: @@ -120,7 +109,7 @@ with a queue capacity of 250 packets: ... } -The following example enables the default packet queue for kea-dhcp6, +The following example enables the default packet queue for ``kea-dhcp6``, with a queue capacity of 300 packets: :: @@ -138,5 +127,5 @@ with a queue capacity of 300 packets: .. note: - Currently the congestion handling is incompatible with multi-threading: - when both are enabled the congestion handling is silently disabled. + Congestion handling is currently incompatible with multi-threading; + when both are enabled, congestion handling is silently disabled. diff -pruN 2.0.2-3/doc/sphinx/arm/ctrl-channel.rst 2.2.0-1/doc/sphinx/arm/ctrl-channel.rst --- 2.0.2-3/doc/sphinx/arm/ctrl-channel.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/ctrl-channel.rst 2022-07-26 06:08:02.000000000 +0000 @@ -29,7 +29,7 @@ machine. Network administrators usually prefer using some form of a RESTful API to control the servers, rather than using UNIX domain sockets directly. -Therefore, Kea includes a component called the Control Agent (or CA), which +Therefore, Kea includes a component called the Control Agent (CA), which exposes a RESTful API to the controlling clients and can forward commands to the respective Kea services over the UNIX domain sockets. The CA configuration is described in @@ -44,15 +44,15 @@ services, it requires additional "forwar in the client's messages. This forwarding information is carried within the ``service`` parameter of the received command. If the ``service`` parameter is not included, or if the parameter is a blank list, the CA -will assume that the control command is targeted at the CA itself and -will try to handle it on its own. +assumes that the control command is targeted at the CA itself and +attempts to respond. Control connections over both HTTP and UNIX domain sockets are guarded -with timeouts. The default timeout value is set to 10 seconds and is not +with timeouts. The timeout value is set to 10 seconds and is not configurable. This API can be used by external tools to manage and monitor Kea operation. -An example of such a monitoring tool is ISC Stork. For details, see +An example of such a monitoring tool is ISC's Stork. For details, see :ref:`stork`. .. _ctrl-channel-syntax: @@ -61,7 +61,7 @@ Data Syntax =========== Communication over the control channel is conducted using JSON -structures. If configured, Kea will open a socket and listen for +structures. If configured, Kea opens a socket and listens for incoming connections. A process connecting to this socket is expected to send JSON commands structured as follows: @@ -77,7 +77,7 @@ send JSON commands structured as follows } } -The same command sent over the RESTful interface to the CA will have the +The same command sent over the RESTful interface to the CA has the following structure: :: @@ -101,21 +101,21 @@ command. The exact content and format of ``service`` is a list of the servers at which the control command is targeted. In the example above, the control command is targeted at the -DHCPv4 server. In most cases, the CA will simply forward this command to +DHCPv4 server. In most cases, the CA simply forwards this command to the DHCPv4 server for processing via a UNIX domain socket. Sometimes, the command including a service value may also be processed by the CA, -if the CA is running a hooks library which handles such a command for -the given server. As an example, the hooks library loaded by the CA may +if the CA is running a hook library which handles such a command for +the given server. As an example, the hook library loaded by the CA may perform some operations on the database, such as adding host reservations, modifying leases, etc. An advantage of performing DHCPv4-specific administrative operations in the CA, rather than forwarding it to the DHCPv4 server, is the ability to perform these operations without disrupting the DHCPv4 service, since the DHCPv4 -server doesn't have to stop processing DHCP messages to apply changes to -the database. Nevertheless, these situations are rather rare and, in +server does not have to stop processing DHCP messages to apply changes to +the database. Nevertheless, these situations are rather rare; in most cases, when the ``service`` parameter contains a name of the -service the commands are simply forwarded by the CA. The forwarded -command includes the ``service`` parameter but this parameter is ignored +service, the commands are simply forwarded by the CA. The forwarded +command includes the ``service`` parameter, but this parameter is ignored by the receiving server. This parameter is only meaningful to the CA. If the command received by the CA does not include a ``service`` @@ -133,9 +133,9 @@ forwarded: - ``dhcp6`` - the command is forwarded to the ``kea-dhcp6`` server. -- ``d2`` - the command is forwarded to the ``kea-d2`` server. +- ``d2`` - the command is forwarded to the ``kea-dhcp-ddns`` server. -The server processing the incoming command will send a response of the +The server processing the incoming command sends a response of the form: :: @@ -159,7 +159,7 @@ example, a well-formed command that requ server's configuration returns the result 0. If the server encounters an error condition, it returns 1. If the command asks for the IPv6 subnet, but was sent to a DHCPv4 server, it returns 2. If the query asks for a -subnet-id and there is no subnet with such an id, the result is 3. +``subnet-id`` and there is no subnet with such an ID, the result is 3. The ``text`` field typically appears when the result is non-zero and contains a description of the error encountered, but it often also @@ -171,15 +171,8 @@ that depends on the specific command. .. note:: - When sending commands via the Control Agent, it is possible to specify - multiple services at which the command is targeted. CA forwards this - command to each service individually. Thus, the CA response to the - controlling client contains an array of individual responses. - -.. note:: - - Since Kea 1.9.7 it is possible to put comments in the commands as - in the configuration file, for instance: + Since Kea 1.9.7, it is possible to put comments in commands as + in the configuration file. For instance: :: @@ -195,6 +188,72 @@ that depends on the specific command. } } +.. _ctrl-channel-control-agent-command-response-format: + +Control Agent Command Response Format +===================================== + +When sending commands via the Control Agent, it is possible to specify +multiple services at which the command is targeted. CA forwards this +command to each service individually. Thus, the CA response to the +controlling client is always wrapped in an array (JSON list) of +individual responses. For example, the response for a command sent +to one service would be structured as follows: + +:: + + [ + { + "result": 0|1|2|3, + "text": "textual description", + "arguments": { + "argument1": "value1", + "argument2": "value2", + ... + } + ] + + +If the command is sent to more than one service, the array would +contain responses from each service, in the order they were requested: + +:: + + [ + { + "result": 0|1|2|3, + "text": "textual description", + "arguments": { + "argument1": "value1", + "argument2": "value2", + ... + }, + { + "result": 0|1|2|3, + "text": "textual description", + "arguments": { + "argument1": "value1", + "argument2": "value2", + ... + }, + ... + ] + +An exception to this are authentication or authorization errors which cause CA +to reject the entirely. The response to such an error will be formatted +as a single entry (JSON map) as follows: + +:: + + { + "result": 403, + "text": "Forbidden" + } + + +These types of errors are possible on systems configured for either basic +authentication or agents that load the RBAC hook library. + .. _ctrl-channel-client: Using the Control Channel @@ -245,8 +304,8 @@ Commands Supported by Both the DHCPv4 an .. _command-build-report: -The build-report Command ------------------------- +The ``build-report`` Command +---------------------------- The ``build-report`` command returns on the control channel what the command line ``-W`` argument displays, i.e. the embedded content of the @@ -260,22 +319,24 @@ command line ``-W`` argument displays, i .. _command-config-get: -The config-get Command ----------------------- +The ``config-get`` Command +-------------------------- The ``config-get`` command retrieves the current configuration used by the server. This command does not take any parameters. The configuration returned is roughly equal to the configuration that was loaded using the --c command line option during server start-up or later set using the +``-c`` command-line option during server start-up, or was later set using the ``config-set`` command. However, there may be certain differences, as comments are not retained. If the original configuration used file inclusion, the returned configuration will include all parameters from -all the included files. +all included files. + +.. warning:: -Note that the returned configuration is not redacted, i.e. it will -contain database passwords in plain text if those were specified in the -original configuration. Care should be taken not to expose the command -channel to unprivileged users. + The returned configuration is not redacted, i.e. it + contains database passwords in plain text, if those were specified in the + original configuration. Care should be taken not to expose the command + channel to unprivileged users. An example command invocation looks like this: @@ -287,19 +348,19 @@ An example command invocation looks like .. _command-config-reload: -The config-reload Command -------------------------- +The ``config-reload`` Command +----------------------------- The ``config-reload`` command instructs Kea to load again the configuration file that was used previously. This operation is useful if the configuration file has been changed by some external source; for -example, a sysadmin can tweak the configuration file and use this +example, a system administrator can tweak the configuration file and use this command to force Kea pick up the changes. Caution should be taken when mixing this with ``config-set`` commands. Kea remembers the location of the configuration file it was started with, and this configuration can be significantly changed using the ``config-set`` -command. When ``config-reload`` is issued after ``config-set``, Kea will attempt +command. When ``config-reload`` is issued after ``config-set``, Kea attempts to reload its original configuration from the file, possibly losing all changes introduced using ``config-set`` or other commands. @@ -312,23 +373,23 @@ invocation looks like this: "command": "config-reload" } -If the configuration file is incorrect reloading it can raise an error -which leaves the server in an unusable state. Look at :ref:`command-config-set` -what to do to recover a working server. +If the configuration file is incorrect, reloading it can raise an error +which leaves the server in an unusable state. See :ref:`command-config-set` +to learn how to recover from a non-working server. .. _command-config-test: -The config-test Command ------------------------ +The ``config-test`` Command +--------------------------- The ``config-test`` command instructs the server to check whether the new configuration supplied in the command's arguments can be loaded. The supplied configuration is expected to be the full configuration for the -target server, along with an optional Logger configuration. As for the -``-t`` command, some sanity checks are not performed, so it is possible a -configuration which successfully passes this command will still fail in -the ``config-set`` command or at launch time. The structure of the -command is as follows: +target server, along with an optional logger configuration. The configuration +is sanity-checked to the extent possible without the server actually +attempting to load it; it is possible for a configuration which successfully +passes this command to still fail in the ``config-set`` command or at launch +time. The structure of the command is as follows: :: @@ -340,7 +401,7 @@ command is as follows: } } -where is the configuration element name for a given server such +where is the configuration element name for a given server, such as "Dhcp4" or "Dhcp6". For example: :: @@ -354,8 +415,8 @@ as "Dhcp4" or "Dhcp6". For example: } } -The server's response will contain a numeric code, "result" (0 for -success, non-zero on failure), and a string, "text", describing the +The server's response contains a numeric code, ``result`` (0 for +success, non-zero on failure), and a string, ``text``, describing the outcome: :: @@ -368,15 +429,15 @@ outcome: .. _command-config-write: -The config-write Command ------------------------- +The ``config-write`` Command +---------------------------- The ``config-write`` command instructs the Kea server to write its current configuration to a file on disk. It takes one optional argument, called "filename", that specifies the name of the file to write the configuration to. If not specified, the name used when starting Kea -(passed as a -c argument) will be used. If a relative path is specified, -Kea will write its files only in the directory it is running. +(passed as a ``-c`` argument) is used. If a relative path is specified, +Kea writes its files only in the directory where it is running. An example command invocation looks like this: @@ -391,8 +452,8 @@ An example command invocation looks like .. _command-leases-reclaim: -The leases-reclaim Command --------------------------- +The ``leases-reclaim`` Command +------------------------------ The ``leases-reclaim`` command instructs the server to reclaim all expired leases immediately. The command has the following JSON syntax: @@ -407,22 +468,22 @@ leases immediately. The command has the } The ``remove`` boolean parameter is mandatory and indicates whether the -reclaimed leases should be removed from the lease database (if true), or -left in the "expired-reclaimed" state (if false). The latter facilitates -lease affinity, i.e. the ability to re-assign an expired lease to the -same client that used this lease before. See :ref:`lease-affinity` -for the details. Also, see :ref:`lease-reclamation` for general +reclaimed leases should be removed from the lease database (if ``true``), or +left in the ``expired-reclaimed`` state (if ``false``). The latter facilitates +lease affinity, i.e. the ability to re-assign an expired lease to a +returning client that previously used that lease. See :ref:`lease-affinity` +for details. Also, see :ref:`lease-reclamation` for general information about the processing of expired leases (lease reclamation). .. _command-libreload: -The libreload Command ---------------------- +The ``libreload`` Command +------------------------- The ``libreload`` command first unloads and then loads all currently -loaded hooks libraries. This is primarily intended to allow one or more -hooks libraries to be replaced with newer versions without requiring Kea -servers to be reconfigured or restarted. Note that the hooks libraries +loaded hook libraries. This is primarily intended to allow one or more +hook libraries to be replaced with newer versions, without requiring Kea +servers to be reconfigured or restarted. The hook libraries are passed the same parameter values (if any) that were passed when they originally loaded. @@ -433,13 +494,13 @@ originally loaded. "arguments": { } } -The server will respond with a result of either 0, indicating success, +The server responds with a result of either 0, indicating success, or 1, indicating failure. .. _command-list-commands: -The list-commands Command -------------------------- +The ``list-commands`` Command +----------------------------- The ``list-commands`` command retrieves a list of all commands supported by the server. It does not take any arguments. An example command may @@ -458,15 +519,15 @@ command. .. _command-config-set: -The config-set Command ----------------------- +The ``config-set`` Command +-------------------------- The ``config-set`` command instructs the server to replace its current configuration with the new configuration supplied in the command's arguments. The supplied configuration is expected to be the full -configuration for the target server, along with an optional Logger -configuration. While optional, the Logger configuration is highly -recommended, as without it the server will revert to its default logging +configuration for the target server, along with an optional logger +configuration. While optional, the logger configuration is highly +recommended, as without it the server reverts to its default logging configuration. The structure of the command is as follows: :: @@ -479,7 +540,7 @@ configuration. The structure of the comm } } -where is the configuration element name for a given server such +where is the configuration element name for a given server, such as "Dhcp4" or "Dhcp6". For example: :: @@ -494,18 +555,18 @@ as "Dhcp4" or "Dhcp6". For example: } If the new configuration proves to be invalid, the server retains its -current configuration but in some cases a fatal error message is logged +current configuration; however, in some cases a fatal error message is logged indicating that the server no longer provides any service: a working configuration must be loaded as soon as possible. If the control channel -is dead the configuration file can still be reloaded using the SIGHUP -signal. Of course a last chance solution is to restart the server. +is dead, the configuration file can still be reloaded using the ``SIGHUP`` +signal. If that is unsuccessful, restart the server. Please note that the new configuration is retained in memory only; if the server is restarted or a configuration reload is triggered via a signal, the server uses the configuration stored in its configuration file. The server's response contains a -numeric code, "result" (0 for success, non-zero on failure), and a -string, "text", describing the outcome: +numeric code, ``result`` (0 for success, non-zero on failure), and a +string, ``text``, describing the outcome: :: @@ -517,11 +578,11 @@ string, "text", describing the outcome: .. _command-shutdown: -The shutdown Command --------------------- +The ``shutdown`` Command +------------------------ The ``shutdown`` command instructs the server to initiate its shutdown -procedure. It is the equivalent of sending a SIGTERM signal to the +procedure. It is the equivalent of sending a ``SIGTERM`` signal to the process. This command does not take any arguments. An example command may look like this: @@ -535,20 +596,20 @@ may look like this: } The server responds with a confirmation that the shutdown procedure has -been initiated. The optional parameter, "exit-value", specifies the -numeric value with which the server process will exit to the system. +been initiated. The optional parameter, ``exit-value``, specifies the +numeric value with which the server process exits to the system. The default value is zero. -The DDNS daemon supports an extra parameter "type" which controls the way +The DDNS daemon supports an extra parameter, ``type``, which controls the way the process cleans up on exit. The supported shutdown types are: - - "normal" - Stops the queue manager and finishes all current transactions + - "normal" - stops the queue manager and finishes all current transactions before exiting. This is the default. - - "drain_first" - Stops the queue manager but continues processing requests + - "drain_first" - stops the queue manager but continues processing requests from the queue until it is empty. - - "now" - Exits immediately. + - "now" - exits immediately. An example command may look like this: @@ -564,8 +625,8 @@ An example command may look like this: .. _command-dhcp-disable: -The dhcp-disable Command ------------------------- +The ``dhcp-disable`` Command +---------------------------- The ``dhcp-disable`` command globally disables the DHCP service. The server continues to operate, but it drops all received DHCP messages. @@ -573,17 +634,17 @@ This command is useful when the server's server temporarily stop allocating new leases and renew existing leases. It is also useful in failover-like configurations during a synchronization of the lease databases at startup, or recovery after a -failure. The optional parameter "max-period" specifies the time in +failure. The optional parameter ``max-period`` specifies the time in seconds after which the DHCP service should be automatically re-enabled, if the ``dhcp-enable`` command is not sent before this time elapses. -Since Kea 1.9.4 there is an additional "origin" parameter that specifies the +Since Kea 1.9.4, there is an additional ``origin`` parameter that specifies the command source. A server administrator should typically omit this parameter because the default value "user" indicates that the administrator sent the command. This command can also be sent by the partner server running HA hooks library. In that case, the partner server sets the parameter to "ha-partner". This value is reserved for the communication between HA partners and should not -be specified in the administrator's commands because it may interfere with the +be specified in the administrator's commands, as it may interfere with HA operation. The administrator should either omit this parameter or set it to "user". @@ -599,18 +660,18 @@ HA operation. The administrator should e .. _command-dhcp-enable: -The dhcp-enable Command ------------------------ +The ``dhcp-enable`` Command +--------------------------- The ``dhcp-enable`` command globally enables the DHCP service. -Since Kea 1.9.4 there is an additional "origin" parameter that specifies the +Since Kea 1.9.4, there is an additional ``origin`` parameter that specifies the command source. A server administrator should typically omit this parameter because the default value "user" indicates that the administrator sent the -command. This command can also be sent by the partner server running HA hooks +command. This command can also be sent by the partner server running the HA hook library. In that case, the partner server sets the parameter to "ha-partner". This value is reserved for the communication between HA partners and should not -be specified in the administrator's commands because it may interfere with the +be specified in the administrator's commands, as it may interfere with HA operation. The administrator should either omit this parameter or set it to "user". @@ -625,76 +686,77 @@ HA operation. The administrator should e .. _command-status-get: -The status-get Command ----------------------- +The ``status-get`` Command +-------------------------- -The ``status-get`` command returns server's runtime information: +The ``status-get`` command returns the server's runtime information: - - pid: process id. + - ``pid``: the process ID. - - uptime: number of seconds since the start of the server. + - ``uptime``: the number of seconds since the start of the server. - - reload: number of seconds since the last configuration (re)load. + - ``reload``: the number of seconds since the last configuration (re)load. - - high-availability: HA specific status information about the DHCP servers - configured to use HA hooks library: + - ``high-availability``: HA-specific status information about the DHCP servers + configured to use the HA hook library: - * local: for the local server the state, the role (primary, - secondary, ...) and scopes (i.e. what the server is actually - processing). + * ``local``: the state, the role (primary, + secondary, ...), and the scopes (i.e. what the server is actually + processing) of the local server. - * remote: for the remote server the last known state, served - HA scopes and the role of the server in the HA relationship. + * ``remote``: the remote server's last known state, its served + HA scopes, and the role of the remote server in the HA relationship. - - multi-threading-enabled: flag indicating if multi-threading is enabled. + - ``multi-threading-enabled``: a flag indicating whether multi-threading is enabled. - - thread-pool-size: number of dhcp service threads. + - ``thread-pool-size``: the number of DHCP service threads. - - packet-queue-size: maximum size of the packet queue. There is one queue, - regardless of how many threads are running. + - ``packet-queue-size``: the maximum size of the packet queue. There is one queue, + regardless of the number of running threads. - - packet-queue-statistics: average queue size for last 10, 100 and 1000 - packets. Statistics using an approach similar to the Unix ``top`` command. - The averaged queue size for the last 10 packets can be considered an + - ``packet-queue-statistics``: the average queue size for the last 10, 100, and 1000 + packets, using an approach similar to the UNIX ``top`` command. + The average queue size for the last 10 packets can be considered an instantaneous value, while the average for the last 1000 packets shows - a longer term trend. + a longer-term trend. The ``high-availability`` information is returned only when the command is -sent to the DHCP servers being in the HA setup. This parameter is +sent to the DHCP servers in an HA setup. This parameter is never returned when the ``status-get`` command is sent to the Control Agent or DDNS daemon. -The ``thread-pool-size`` and ``packet-queue-size`` parameters are returned only -when the command is sent to DHCP servers with multi-threading enabled. These two -parameters and ``multi-threading-enabled`` are never returned when the -``status-get`` command is sent to the Control Agent or DDNS daemon. +The ``thread-pool-size``, ``packet-queue-size`` and +``packet-queue-statistics`` parameters are returned only when the +command is sent to DHCP servers with multi-threading enabled. These +three parameters and ``multi-threading-enabled`` are never returned when +the ``status-get`` command is sent to the Control Agent or DDNS daemon. To learn more about the HA status information returned by the -``status-get`` command please refer to the :ref:`command-ha-status-get` +``status-get`` command, please refer to the :ref:`command-ha-status-get` section. .. _command-server-tag-get: -The server-tag-get Command: ---------------------------- +The ``server-tag-get`` Command: +------------------------------- The ``server-tag-get`` command returns the configured server tag of -the DHCPv4 or DHCPv6 server (:ref:`cb-sharing` explains the server tag concept) +the DHCPv4 or DHCPv6 server (:ref:`cb-sharing` explains the server tag concept). .. _command-config-backend-pull: -The config-backend-pull Command: --------------------------------- +The ``config-backend-pull`` Command: +------------------------------------ -The ``config-backend-pull`` command triggers the polling of Config Backends -(which should be configured for this command to do something) +The ``config-backend-pull`` command triggers the polling of configuration backends +(which must be configured for this command to have an effect), explained in :ref:`dhcp4-cb-json`. .. _command-version-get: -The version-get Command ------------------------ +The ``version-get`` Command +--------------------------- The ``version-get`` command returns extended information about the Kea version. It is the same information available via the ``-V`` @@ -709,53 +771,53 @@ command-line argument. This command does Commands Supported by the D2 Server =================================== -The D2 server supports only a subset of DHCPv4 / DHCPv6 server commands: +The D2 server supports only a subset of the DHCPv4/DHCPv6 server commands: -- build-report +- ``build-report`` -- config-get +- ``config-get`` -- config-reload +- ``config-reload`` -- config-set +- ``config-set`` -- config-test +- ``config-test`` -- config-write +- ``config-write`` -- list-commands +- ``list-commands`` -- shutdown +- ``shutdown`` -- status-get +- ``status-get`` -- version-get +- ``version-get`` .. _agent-commands: Commands Supported by the Control Agent ======================================= -The following commands listed in :ref:`commands-common` are also supported by the -Control Agent, i.e. when the ``service`` parameter is blank, the +The following commands, listed in :ref:`commands-common`, are also supported by the +Control Agent; when the ``service`` parameter is blank, the commands are handled by the CA and they relate to the CA process itself: -- build-report +- ``build-report`` -- config-get +- ``config-get`` -- config-reload +- ``config-reload`` -- config-set +- ``config-set`` -- config-test +- ``config-test`` -- config-write +- ``config-write`` -- list-commands +- ``list-commands`` -- shutdown +- ``shutdown`` -- status-get +- ``status-get`` -- version-get +- ``version-get`` diff -pruN 2.0.2-3/doc/sphinx/arm/database-connectivity.rst 2.2.0-1/doc/sphinx/arm/database-connectivity.rst --- 2.0.2-3/doc/sphinx/arm/database-connectivity.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/database-connectivity.rst 2022-07-26 06:08:02.000000000 +0000 @@ -3,10 +3,12 @@ ********************* Database Connectivity ********************* -Kea servers (kea-dhcp4 and kea-dhcp6) can be configured to use a variety of -database backends for leases, hosts, and configuration. All of them may be -configured to support automatic recovery when connectivity is lost (see -``max-reconnect-tries``, ``reconnect-wait-time``and ``on-fail``). +The Kea servers (``kea-dhcp4`` and ``kea-dhcp6``) can be configured to use a variety of +database backends for leases, hosts, and configuration. They can be +configured to support automatic recovery when connectivity is lost, via +the ``on-fail`` parameter. (The ``reconnect-wait-time`` and +``max-reconnect-tries`` parameters are described +in :ref:`database-configuration4` and :ref:`database-configuration6`.) It is important to understand how and when automatic recovery comes into play. Automatic recovery, when configured, only operates after a successful startup @@ -23,29 +25,60 @@ During dynamic reconfiguration, all back reconnected using the new configuration. If connectivity to any of the backends cannot be established, the server logs a fatal error but remains up. It is able to process commands but does not serve clients. This -allows the configuration to be corrected via command, if required. +allows the configuration to be corrected via the ``config-set`` or +``remote-*`` commands, if required. During normal operations, if connectivity to any of the backends is lost and automatic recovery for that backend is enabled, the server disconnects from the respective backend and then attempts to reconnect. During the recovery process, the server ceases to serve clients according to the ``on-fail`` configured -option and continues to respond to commands. +option but continues to respond to commands. The ``on-fail`` parameter configures the actions the server should take when a connection is lost. It can have one of the following values: -- ``stop-retry-exit`` which indicates that the server should stop the service - while it tries to recover the connection and exit if recovery is not +- ``stop-retry-exit`` - indicates that the server should stop the service + while it tries to recover the connection, and exit if recovery is not successful after ``max-reconnect-tries``. -- ``serve-retry-exit`` which indicates that the server should not stop the - service while it tries to recover the connection and exit if recovery is not +- ``serve-retry-exit`` - indicates that the server should not stop the + service while it tries to recover the connection, and exit if recovery is not successful after ``max-reconnect-tries``. -- ``serve-retry-continue`` which indicates that the server should not stop the - service while it tries to recover the connection and not exit if recovery is +- ``serve-retry-continue`` - indicates that the server should not stop the + service while it tries to recover the connection, and not exit if recovery is not successful after ``max-reconnect-tries``. If connectivity to all backends is restored, the server returns to normal -operations. If the connection can not be restored and the server is configured +operations. If the connection cannot be restored and the server is configured to exit, it issues a fatal error before shutdown. + +The connection to the database server can optionally be protected by TLS. +Corresponding database configuration parameters for Kea servers are: + +- The ``trust-anchor`` specifies the Certification Authority file name or + directory path. + +- The ``cert-file`` specifies the client certificate file name. + +- The ``key-file`` specifies the private key file name. + +- The ``cipher-list`` specifies the list of TLS ciphers (the syntax of + the content of this parameter is described in the OpenSSL ciphers + manual). + +These parameters are similar to the parameters of the secure connections +with the agent but are interpreted by different backends using database +configurations too. + +Currently the support for each database is: + +- MySQL supports the whole set, additional configuration must be done + in the MySQL local setup, for instance certificate revocation list, + choice of a specific TLS version, mutual authentication, etc. + When a TLS connection was required but the actual connection is in + clear text an error log is emitted. + +- PostgreSQL only uses the configuration to enable the SSL/TLS support + in the client library (libpq). Anything else must be done in the + PostgreSQL local configuration. diff -pruN 2.0.2-3/doc/sphinx/arm/ddns.rst 2.2.0-1/doc/sphinx/arm/ddns.rst --- 2.0.2-3/doc/sphinx/arm/ddns.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/ddns.rst 2022-07-26 06:08:02.000000000 +0000 @@ -9,11 +9,11 @@ The DHCP-DDNS Server Overview ======== -The DHCP-DDNS Server (kea-dhcp-ddns, known informally as D2) conducts +The DHCP-DDNS Server (``kea-dhcp-ddns``, known informally as D2) conducts the client side of the Dynamic DNS protocol (DDNS, defined in `RFC 2136 `__) on behalf of the DHCPv4 -and DHCPv6 servers (kea-dhcp4 and kea-dhcp6 respectively). The DHCP -servers construct DDNS update requests, known as Name Change Requests +and DHCPv6 servers (``kea-dhcp4`` and ``kea-dhcp6`` respectively). The DHCP +servers construct DDNS update requests, known as NameChangeRequests (NCRs), based on DHCP lease change events and then post them to D2. D2 attempts to match each request to the appropriate DNS server(s) and carries out the necessary conversation with those servers to update the @@ -24,36 +24,36 @@ DNS data. DNS Server Selection -------------------- -In order to match a request to the appropriate DNS servers, D2 must have +To match a request to the appropriate DNS servers, D2 must have a catalog of servers from which to select. In fact, D2 has two such catalogs, one for forward DNS and one for reverse DNS; these catalogs -are referred to as DDNS Domain Lists. Each list consists of one or more -named DDNS Domains. Further, each DDNS Domain has a list of one or more +are referred to as "DDNS domain lists." Each list consists of one or more +named DDNS domains. Further, each DDNS domain has a list of one or more DNS servers that publish the DNS data for that domain. -When conducting forward domain matching, D2 compares the fully qualified -domain name (FQDN) in the request against the name of each Forward DDNS -Domain in its catalog. The domain whose name matches the longest portion +When conducting forward-domain matching, D2 compares the fully qualified +domain name (FQDN) in the request against the name of each forward DDNS +domain in its catalog. The domain whose name matches the longest portion of the FQDN is considered the best match. For example, if the FQDN is "myhost.sample.example.com.", and there are two forward domains in the catalog, "sample.example.com." and "example.com.", the former is regarded as the best match. In some cases, it may not be possible to find a suitable match. Given the same two forward domains there would be -no match for the FQDN, "bogus.net", so the request would be rejected. -Finally, if there are no Forward DDNS Domains defined, D2 simply -disregards the forward update portion of requests. +no match for the FQDN "bogus.net", so the request would be rejected. +Finally, if there are no forward DDNS domains defined, D2 simply +disregards the forward-update portion of requests. -When conducting reverse domain matching, D2 constructs a reverse FQDN +When conducting reverse-domain matching, D2 constructs a reverse FQDN from the lease address in the request and compares that against the name -of each Reverse DDNS Domain. Again, the domain whose name matches the +of each reverse DDNS domain. Again, the domain whose name matches the longest portion of the FQDN is considered the best match. For instance, if the lease address is "172.16.1.40" and there are two reverse domains in the catalog, "1.16.172.in-addr.arpa." and "16.172.in-addr.arpa", the -former is the best match. As with forward matching, it may not find a +former is the best match. As with forward matching, D2 may not find a suitable match. Given the same two domains, there would be no match for the lease address, "192.168.1.50", and the request would be rejected. -Finally, if there are no Reverse DDNS Domains defined, D2 simply -disregards the reverse update portion of requests. +As with forward-domain matching, if there are no reverse DDNS domains defined, D2 simply +disregards the reverse-update portion of requests. .. _dhcp-ddns-conflict-resolution: @@ -71,10 +71,20 @@ wishes to update or remove existing forw do so if their client matches that of the DHCID RR. In other words, the DHCID RR maps an FQDN to the client to whom it -belongs, and thereafter changes to that mapping should only be done by +belongs, and thereafter changes to that mapping can only be done by or at the behest of that client. -Currently, conflict detection is always performed. +Conflict resolution can be indirectly enabled or disabled via +the configuration parameter ``ddns-use-conflict-resolution``, supported +by both ``kea-dhcp4`` and ``kea-dhcp6``. These servers use this parameter to +set a flag within each NameChangeRequest they send that tells D2 +whether conflict resolution should be employed for that request. +By default, conflict resolution is enabled. For more details, please refer +to discussions of ``ddns-use-conflict-resolution`` in :ref:`dhcp4-ddns-config` and :ref:`dhcp6-ddns-config`. + +When conflict resolution is disabled, D2 still adds DHCID RRs but does +not use them to enforce client ownership of DNS entries. Disabling it should +only be used after careful consideration. .. _dhcp-ddns-dual-stack: @@ -84,12 +94,12 @@ Dual-Stack Environments `RFC 4703, section 5.2, `__ describes issues that may arise with dual-stack clients. These are clients that -wish to have both IPv4 and IPv6 mappings for the same FQDN. For -this to work properly, the clients are required to embed their IPv6 DUID +wish to have both IPv4 and IPv6 mappings for the same FQDN. +To work properly, clients must embed their IPv6 DUID within their IPv4 client identifier option, as described in `RFC -4703 `__. In this way, DNS updates -for both IPv4 and IPv6 can be managed under the same DHCID RR. Kea does not -currently support this feature. +4361 `__. In this way, DNS updates +for both IPv4 and IPv6 can be managed under the same DHCID RR. This feature +is supported by Kea beginning with release 2.1.2. .. _dhcp-ddns-server-start-stop: @@ -107,7 +117,7 @@ directly. It accepts the following comma - ``-c file`` - specifies the configuration file. This is the only mandatory switch. -- ``-d`` - specifies whether the server logging should be switched to +- ``-d`` - specifies whether server logging should be switched to debug/verbose mode. In verbose mode, the logging severity and debuglevel specified in the configuration file are ignored and "debug" severity and the maximum debuglevel (99) are assumed. The @@ -121,14 +131,14 @@ directly. It accepts the following comma it is embedded in the executable binary. - ``-t file`` - specifies the configuration file to be tested. - Kea-dhcp-ddns will attempt to load it and will conduct sanity checks. - Note that certain checks are possible only while running the actual + ``kea-dhcp-ddns`` attempts to load it and conducts sanity checks. + Certain checks are possible only while running the actual server. The actual status is reported with an exit code (0 = - configuration looks ok, 1 = error encountered). Kea prints out log + configuration looks okay, 1 = error encountered). Kea prints out log messages to standard output and errors to standard error when testing the configuration. -The ``config.report`` may also be accessed more directly, via the +The ``config.report`` file may also be accessed directly, via the following command. The binary ``path`` may be found in the install directory or in the ``.libs`` subdirectory in the source tree. For example: ``kea/src/bin/d2/.libs/kea-dhcp-ddns``. @@ -137,16 +147,16 @@ example: ``kea/src/bin/d2/.libs/kea-dhcp strings path/kea-dhcp-ddns | sed -n 's/;;;; //p' -Upon startup, the module will load its configuration and begin listening +Upon startup, the module loads its configuration and begins listening for NCRs based on that configuration. -During startup, the server will attempt to create a PID file of the form: -[**runstatedir**]/[**conf name**].kea-dhcp-ddns.pid where: +During startup, the server attempts to create a PID file of the form: +``[runstatedir]/[conf name].kea-dhcp-ddns.pid`` where: - ``runstatedir`` - is the value as passed into the build configure script; it defaults to "/usr/local/var/run". Note that this value may be overridden at runtime by setting the environment variable - KEA_PIDFILE_DIR. This is intended primarily for testing purposes. + ``KEA_PIDFILE_DIR``. This is intended primarily for testing purposes. - ``conf name`` - is the configuration file name used to start the server, minus all preceding paths and the file extension. For example, given @@ -154,7 +164,7 @@ During startup, the server will attempt be "myconf". If the file already exists and contains the PID of a live process, the -server will issue a DHCP_DDNS_ALREADY_RUNNING log message and exit. It +server issues a ``DHCP_DDNS_ALREADY_RUNNING`` log message and exits. It is possible, though unlikely, that the file is a remnant of a system crash and the process to which the PID belongs is unrelated to Kea. In such a case it is necessary to manually delete the PID file. @@ -196,9 +206,9 @@ which is described below: - *TSIG Key Info* - defines the TSIG keys used for secure traffic with DNS servers. -- *Forward DDNS* - defines the catalog of Forward DDNS Domains. +- *Forward DDNS* - defines the catalog of forward DDNS domains. -- *Reverse DDNS* - defines the catalog of Forward DDNS Domains. +- *Reverse DDNS* - defines the catalog of reverse DDNS domains. .. _d2-server-parameter-config: @@ -236,8 +246,6 @@ illustrates how to change D2's global pa } } -.. - .. warning:: It is possible for a malicious attacker to send bogus @@ -248,8 +256,8 @@ illustrates how to change D2's global pa .. note:: - If the ip-address and port are changed, the corresponding values in - the DHCP servers' "dhcp-ddns" configuration section must be changed. + If the ``ip-address`` and ``port`` are changed, the corresponding values in + the DHCP servers' ``dhcp-ddns`` configuration section must be changed. .. _d2-ctrl-channel: @@ -259,7 +267,7 @@ Management API for the D2 Server The management API allows the issuing of specific management commands, such as configuration retrieval or shutdown. For more details, see :ref:`ctrl-channel`. Currently, the only supported communication -channel type is UNIX stream socket. By default there are no sockets +channel type is the UNIX stream socket. By default there are no sockets open; to instruct Kea to open a socket, the following entry in the configuration file can be used: @@ -277,7 +285,7 @@ The length of the path specified by the restricted by the maximum length for the UNIX socket name on the operating system, i.e. the size of the ``sun_path`` field in the ``sockaddr_un`` structure, decreased by 1. This value varies on -different operating systems between 91 and 107 characters. Typical +different operating systems, between 91 and 107 characters. Typical values are 107 on Linux and 103 on FreeBSD. Communication over the control channel is conducted using JSON structures. @@ -298,7 +306,7 @@ The D2 server supports the following ope - status-get - version-get -Starting with Kea version 2.0.0 the D2 server supports too the following +Since Kea version 2.0.0, the D2 server also supports the following operational commands for statistics: - statistic-get @@ -306,17 +314,17 @@ operational commands for statistics: - statistic-reset - statistic-reset-all -The ``shutdown`` command supports the extra ``type`` argument which controls the +The ``shutdown`` command supports the extra ``type`` argument, which controls the way the D2 server cleans up on exit. The supported shutdown types are: -- ``normal`` - Stops the queue manager and finishes all current transactions +- ``normal`` - stops the queue manager and finishes all current transactions before exiting. This is the default. -- ``drain_first`` - Stops the queue manager but continues processing requests +- ``drain_first`` - stops the queue manager but continues processing requests from the queue until it is empty. -- ``now`` - Exits immediately. +- ``now`` - exits immediately. An example command may look like this: @@ -335,21 +343,22 @@ An example command may look like this: TSIG Key List ------------- -A DDNS protocol exchange can be conducted with or without TSIG (defined +A DDNS protocol exchange can be conducted with or without a transaction +signature, or TSIG (defined in `RFC 2845 `__). This configuration section allows the administrator to define the set of TSIG keys that may be used in such exchanges. To use TSIG when updating entries in a DNS domain, a key must be defined -in the TSIG Key list and referenced by name in that domain's +in the TSIG key list and referenced by name in that domain's configuration entry. When D2 matches a change request to a domain, it checks whether the domain has a TSIG key associated with it. If so, D2 uses that key to sign DNS update messages sent to and verify responses received from the domain's DNS server(s). For each TSIG key -required by the DNS servers that D2 will be working with, there must be -a corresponding TSIG key in the TSIG Key list. +required by the DNS servers that D2 is working with, there must be +a corresponding TSIG key in the TSIG key list. -As one might gather from the name, the tsig-key section of the D2 +As one might gather from the name, the ``tsig-key`` section of the D2 configuration lists the TSIG keys. Each entry describes a TSIG key used by one or more DNS servers to authenticate requests and sign responses. Every entry in the list has three parameters: @@ -378,7 +387,7 @@ Every entry in the list has three parame bits. The default value 0 means truncation is forbidden; non-zero values must be an integral number of octets, and be greater than both 80 and half of the full length. (Note that in BIND 9 this parameter - is appended after a dash to the algorithm name.) + is appended to the algorithm name, after a dash.) - ``secret`` - is used to specify the shared secret key code for this key. This value is case-sensitive and must exactly match the value @@ -398,7 +407,7 @@ named.conf file looks like this: }; : -By default, the TSIG Key list is empty: +By default, the TSIG key list is empty: :: @@ -407,7 +416,7 @@ By default, the TSIG Key list is empty: ... } -We must extend the list with a new key: +A new key must be added to the list: :: @@ -422,7 +431,7 @@ We must extend the list with a new key: ... } -These steps would be repeated for each TSIG key needed. Note that the +These steps must be repeated for each TSIG key needed, although the same TSIG key can be used with more than one domain. .. _d2-forward-ddns-config: @@ -430,9 +439,9 @@ same TSIG key can be used with more than Forward DDNS ------------ -The Forward DDNS section is used to configure D2's forward update +The forward DDNS section is used to configure D2's forward-update behavior. Currently it contains a single parameter, the catalog of -Forward DDNS Domains, which is a list of structures. +forward DDNS domains, which is a list of structures. :: @@ -443,44 +452,44 @@ Forward DDNS Domains, which is a list of ... } -By default, this list is empty, which will cause the server to ignore -the forward update portions of requests. +By default, this list is empty, which causes the server to ignore +the forward-update portions of requests. .. _add-forward-ddns-domain: Adding Forward DDNS Domains ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A Forward DDNS Domain maps a forward DNS zone to a set of DNS servers +A forward DDNS domain maps a forward DNS zone to a set of DNS servers which maintain the forward DNS data (i.e. name-to-address mapping) for -that zone. Each zone served needs one Forward DDNS Domain. It may very -well be that some or all of the zones are maintained by the same -servers, but one DDNS Domain is still needed for each zone. Remember that +that zone. Each zone served needs one forward DDNS domain. +Some or all of the zones may be maintained by the same +servers, but one DDNS domain is still needed for each zone. Remember that matching a request to the appropriate server(s) is done by zone and a -DDNS Domain only defines a single zone. +DDNS domain only defines a single zone. -This section describes how to add Forward DDNS Domains; repeat these -steps for each Forward DDNS Domain desired. Each Forward DDNS Domain has +This section describes how to add forward DDNS domains; repeat these +steps for each forward DDNS domain desired. Each forward DDNS domain has the following parameters: -- ``name`` - the fully qualified domain name (or zone) that this DDNS - Domain can update. This value is compared against the request FQDN +- ``name`` - this is the fully qualified domain name (or zone) that this DDNS + domain can update. This value is compared against the request FQDN during forward matching. It must be unique within the catalog. - ``key-name`` - if TSIG is used with this domain's servers, this value - should be the name of the key from the TSIG Key list. If the + should be the name of the key from the TSIG key list. If the value is blank (the default), TSIG will not be used in DDNS conversations with this domain's servers. -- ``dns-servers`` - a list of one or more DNS servers which can conduct +- ``dns-servers`` - this is a list of one or more DNS servers which can conduct the server side of the DDNS protocol for this domain. The servers are used in a first-to-last preference; in other words, when D2 begins to process a request for this domain, it will pick the first server in this list and attempt to communicate with it. If that attempt fails, - D2 will move to the next one in the list and so on until either it + D2 will move to the next one in the list and so on, until either it is successful or the list is exhausted. -To create a new Forward DDNS Domain, add a new domain element and set +To create a new forward DDNS domain, add a new domain element and set its parameters: :: @@ -507,11 +516,11 @@ useful, at least one DNS server must be Adding Forward DNS Servers ^^^^^^^^^^^^^^^^^^^^^^^^^^ -This section describes how to add DNS servers to a Forward DDNS Domain. +This section describes how to add DNS servers to a forward DDNS domain. Repeat these instructions as needed for all the servers in each domain. -Forward DNS Server entries represent actual DNS servers which support -the server side of the DDNS protocol. Each Forward DNS Server has the +Forward DNS server entries represent actual DNS servers which support +the server side of the DDNS protocol. Each forward DNS server has the following parameters: - ``hostname`` - the resolvable host name of the DNS server; this @@ -523,9 +532,9 @@ following parameters: - ``port`` - the port on which the server listens for DDNS requests. It defaults to the standard DNS service port of 53. -To create a new Forward DNS Server, a new server element must be added to +To create a new forward DNS server, a new server element must be added to the domain and its parameters filled in. If, for example, the service is -running at "172.88.99.10", set the Forward DNS Server as follows: +running at "172.88.99.10", set the forward DNS server as follows: :: @@ -546,11 +555,9 @@ running at "172.88.99.10", set the Forwa } } -.. - .. note:: - Since "hostname" is not yet supported, the parameter "ip-address" + Since ``hostname`` is not yet supported, the parameter ``ip-address`` must be set to the address of the DNS server. .. _d2-reverse-ddns-config: @@ -558,10 +565,10 @@ running at "172.88.99.10", set the Forwa Reverse DDNS ------------ -The Reverse DDNS section is used to configure D2's reverse update +The reverse DDNS section is used to configure D2's reverse update behavior, and the concepts are the same as for the forward DDNS section. -Currently it contains a single parameter, the catalog of Reverse DDNS -Domains, which is a list of structures. +Currently it contains a single parameter, the catalog of reverse DDNS +domains, which is a list of structures. :: @@ -572,49 +579,49 @@ Domains, which is a list of structures. ... } -By default, this list is empty, which will cause the server to ignore -the reverse update portions of requests. +By default, this list is empty, which causes the server to ignore +the reverse-update portions of requests. .. _add-reverse-ddns-domain: Adding Reverse DDNS Domains ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A Reverse DDNS Domain maps a reverse DNS zone to a set of DNS servers +A reverse DDNS domain maps a reverse DNS zone to a set of DNS servers which maintain the reverse DNS data (address-to-name mapping) for that -zone. Each zone served needs one Reverse DDNS Domain. It may very well -be that some or all of the zones are maintained by the same servers, but -one DDNS Domain entry is still needed for each zone. Remember that +zone. Each zone served needs one reverse DDNS domain. +Some or all of the zones may be maintained by the same servers, but +one DDNS domain entry is needed for each zone. Remember that matching a request to the appropriate server(s) is done by zone and a -DDNS Domain only defines a single zone. +DDNS domain only defines a single zone. -This section describes how to add Reverse DDNS Domains; repeat these -steps for each Reverse DDNS Domain desired. Each Reverse DDNS Domain has +This section describes how to add reverse DDNS domains; repeat these +steps for each reverse DDNS domain desired. Each reverse DDNS domain has the following parameters: -- ``name`` - the fully qualified reverse zone that this DDNS domain can - update. This is the value used during reverse matching, which will - compare it with a reversed version of the request's lease address. +- ``name`` - this is the fully qualified reverse zone that this DDNS domain can + update. This is the value used during reverse matching, which + compares it with a reversed version of the request's lease address. The zone name should follow the appropriate standards; for example, to support the IPv4 subnet 172.16.1, the name should be "1.16.172.in-addr.arpa.". Similarly, to support an IPv6 subnet of 2001:db8:1, the name should be "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa." - Whatever the name, it must be unique within the catalog. + The name must be unique within the catalog. - ``key-name`` - if TSIG is used with this domain's servers, - this value should be the name of the key from the TSIG Key List. If + this value should be the name of the key from the TSIG key list. If the value is blank (the default), TSIG will not be used in DDNS conversations with this domain's servers. -- ``dns-servers`` - a list of one or more DNS servers which can conduct +- ``dns-servers`` - this is a list of one or more DNS servers which can conduct the server side of the DDNS protocol for this domain. Currently, the servers are used in a first-to-last preference; in other words, when D2 begins to process a request for this domain, it will pick the first server in this list and attempt to communicate with it. If that - attempt fails, D2 will move to the next one in the list and so on + attempt fails, D2 will move to the next one in the list and so on, until either it is successful or the list is exhausted. -To create a new Reverse DDNS Domain, a new domain element must be added +To create a new reverse DDNS domain, a new domain element must be added and its parameters set. For example, to support subnet 2001:db8:1::, the following configuration could be used: @@ -642,11 +649,11 @@ useful, at least one DNS server must be Adding Reverse DNS Servers ^^^^^^^^^^^^^^^^^^^^^^^^^^ -This section describes how to add DNS servers to a Reverse DDNS Domain. +This section describes how to add DNS servers to a reverse DDNS domain. Repeat these instructions as needed for all the servers in each domain. -Reverse DNS Server entries represent actual DNS servers which support -the server side of the DDNS protocol. Each Reverse DNS Server has the +Reverse DNS server entries represent actual DNS servers which support +the server side of the DDNS protocol. Each reverse DNS server has the following parameters: - ``hostname`` - the resolvable host name of the DNS server; this value @@ -658,8 +665,8 @@ following parameters: - ``port`` - the port on which the server listens for DDNS requests. It defaults to the standard DNS service port of 53. -To create a new reverse DNS Server, a new server -element must be added to the domain and its parameters filled in. If, for example, the +To create a new reverse DNS server, a new server +element must be added to the domain and its parameters specified. If, for example, the service is running at "172.88.99.10", then set it as follows: :: @@ -681,32 +688,30 @@ service is running at "172.88.99.10", th } } -.. - .. note:: - Since "hostname" is not yet supported, the parameter "ip-address" + Since ``hostname`` is not yet supported, the parameter ``ip-address`` must be set to the address of the DNS server. .. _per-server-keys: -Per DNS server TSIG keys +Per-DNS-Server TSIG Keys ~~~~~~~~~~~~~~~~~~~~~~~~ -Since Kea version 2.0.0 a TSIG key can be specified in a DNS server +Since Kea version 2.0.0, a TSIG key can be specified in a DNS server configuration. The priority rule is: -- if a not empty key name is specified in a DNS server entry this TSIG - key will protect DNS updates sent to this server. +- if a not-empty key name is specified in a DNS server entry, this TSIG + key protects DNS updates sent to this server. -- if empty or no key name is specified in a DNS server entry but a not - empty key name is specified in the parent domain entry, the domain - TSIG key will protect DNS updates sent to this server. +- if the DNS server entry is empty, but a + not-empty key name is specified in the parent's domain entry, the parent domain's + TSIG key protects DNS updates sent to this server. -- if empty or no key name is specified in a DNS server entry and its parent - domain entry, no TSIG will protect DNS updates sent to this server. +- if the DNS server entry is empty, and no key name is specified in its parent + domain entry, no TSIG protects DNS updates sent to this server. -For instance in this configuration: +For instance, in this configuration: :: @@ -763,8 +768,8 @@ For instance in this configuration: } -The 172.88.99.10 server will use the foo TSIG key, 172.88.99.11 and -172.88.99.13 servers the bar one and 172.88.99.12 will not use TSIG. +The 172.88.99.10 server will use the "foo" TSIG key, the 172.88.99.11 and +172.88.99.13 servers will use the "bar" key. and 172.88.99.12 will not use TSIG. .. _d2-user-contexts: @@ -774,8 +779,8 @@ User Contexts in DDNS See :ref:`user-context` for additional background regarding the user context idea. -User contexts can be specified on global scope, DDNS domain, DNS server, -TSIG key, and loggers. One other useful usage is the ability to store +User contexts can be specified on a global scope, a DDNS domain, a DNS server, +a TSIG key, and loggers. One other useful usage is the ability to store comments or descriptions; the parser translates a "comment" entry into a user context with the entry, which allows a comment to be attached inside the configuration itself. @@ -789,7 +794,7 @@ This section provides a sample DHCP-DDNS a small example network. Let's suppose our example network has three domains, each with their own subnet. -.. table:: Our Example Network +.. table:: Our example network +------------------+-----------------+-----------------+-----------------+ | Domain | Subnet | Forward DNS | Reverse DNS | @@ -803,9 +808,9 @@ domains, each with their own subnet. | example.com | 192.0.0.0/16 | 172.16.2.5 | 172.16.2.5 | +------------------+-----------------+-----------------+-----------------+ -We need to construct three Forward DDNS Domains: +We need to construct three forward DDNS domains: -.. table:: Forward DDNS Domains Needed +.. table:: Forward DDNS domains needed +----+-------------------+------------------------+ | # | DDNS Domain Name | DNS Servers | @@ -818,12 +823,12 @@ We need to construct three Forward DDNS +----+-------------------+------------------------+ As discussed earlier, FQDN-to-domain matching is based on the longest -match. The FQDN, "myhost.four.example.com.", will match the first domain -("four.example.com") while "admin.example.com." will match the third -domain ("example.com"). The FQDN, "other.example.net.", will fail to +match. The FQDN "myhost.four.example.com." matches the first domain +("four.example.com"), while "admin.example.com." matches the third +domain ("example.com"). The FQDN "other.example.net." fails to match any domain and is rejected. -The following example configuration specifies the Forward DDNS Domains. +The following example configuration specifies the forward DDNS domains. :: @@ -859,9 +864,9 @@ The following example configuration spec } } -Similarly, we need to construct the three Reverse DDNS Domains: +Similarly, we need to construct the three reverse DDNS domains: -.. table:: Reverse DDNS Domains Needed +.. table:: Reverse DDNS domains needed +----+-----------------------------------+------------------------+ | # | DDNS Domain Name | DNS Servers | @@ -873,11 +878,11 @@ Similarly, we need to construct the thre | 3. | 0.182.in-addr.arpa. | 172.16.2.5 | +----+-----------------------------------+------------------------+ -An address of "192.0.2.150" will match the first domain, -"2001:db8:1::10" will match the second domain, and "192.0.50.77" the +An address of "192.0.2.150" matches the first domain, +"2001:db8:1::10" matches the second domain, and "192.0.50.77" matches the third domain. -These Reverse DDNS Domains are specified as follows: +These reverse DDNS domains are specified as follows: :: @@ -914,68 +919,69 @@ These Reverse DDNS Domains are specified DHCP-DDNS Server Statistics =========================== -Kea version 2.0.0 introduced statistics support for the DHCP-DDNS. +Kea version 2.0.0 introduced statistics support for DHCP-DDNS. -Statistics are divided in three groups: Name Change Request, DNS update -and per TSIG key DNS updates. If the statistics of the first two groups +Statistics are divided into three groups: NameChangeRequests, DNS updates, +and per-TSIG-key DNS updates. While the statistics of the first two groups are cumulative, i.e. not affected by configuration change or reload, -per key statistics are reset to 0 when the underlying object is +per-key statistics are reset to 0 when the underlying object is (re)created. -Currently the statistics management is limited: +Currently Kea's statistics management has the following limitations: -- only integer samples (i.e. a counter and a timestamp) are used -- the maximum sample count is 1 -- there is no API to remove one or all statistics -- there is no API to set the maximum sample count or age +- only integer samples (i.e. a counter and a timestamp) are used; +- the maximum sample count is 1; +- there is no API to remove one or all statistics; +- there is no API to set the maximum sample count or age. .. note:: - Hook libraries like the GSS-TSIG add new statistics. + Hook libraries, such as the the ISC subscriber-only GSS-TSIG library, + make new statistics available in Kea. -A reference about Kea statistics can be found at :ref:`stats`. +More information about Kea statistics can be found at :ref:`stats`. NCR Statistics -------------- -The Name Change Request statistics are: +The NameChangeRequest statistics are: -- ``ncr-received`` - received valid NCRs -- ``ncr-invalid`` - received invalid NCRs -- ``ncr-error`` - errors in NCR receptions other than I/O cancel on shutdown +- ``ncr-received`` - the number of received valid NCRs +- ``ncr-invalid`` - the number of received invalid NCRs +- ``ncr-error`` - the number of errors in NCR receptions other than an I/O cancel on shutdown DNS Update Statistics --------------------- The global DNS update statistics are: -- ``update-sent`` - sent DNS updates -- ``update-signed`` - sent DNS updates protected by TSIG -- ``update-unsigned`` - sent DNS updates not protected by TSIG -- ``update-success`` - DNS updates which completed with a success -- ``update-timeout`` - DNS updates which completed on timeout -- ``update-error`` - DNS updates which completed with an error other than +- ``update-sent`` - the number of DNS updates sent +- ``update-signed`` - the number of DNS updates sent and protected by TSIG +- ``update-unsigned`` - the number of DNS updates sent and not protected by TSIG +- ``update-success`` - the number of DNS updates which successfully completed +- ``update-timeout`` - the number of DNS updates which completed on timeout +- ``update-error`` - the number of DNS updates which completed with an error other than timeout -Per TSIG key DNS Update Statistics +Per-TSIG-Key DNS Update Statistics ---------------------------------- The per TSIG key DNS update statistics are: -- ``update-sent`` - sent DNS updates -- ``update-success`` - DNS updates which completed with a success -- ``update-timeout`` - DNS updates which completed on timeout -- ``update-error`` - DNS updates which completed with an error other than +- ``update-sent`` - the number of DNS updates sent +- ``update-success`` - the number of DNS updates which successfully completed +- ``update-timeout`` - the number of DNS updates which completed on timeout +- ``update-error`` - the number of DNS updates which completed with an error other than timeout -The name of a per key statistics is ``key[].``, -for instance the name of the ``update-sent`` statistics for the +The name format for per-key statistics is ``key[].``: +for instance, the name of the ``update-sent`` statistics for the ``key.example.com.`` TSIG key is ``key[key.example.com.].update-sent``. DHCP-DDNS Server Limitations ============================ -The following are the current limitations of the DHCP-DDNS Server. +The following are the current limitations of the DHCP-DDNS server. - Requests received from the DHCP servers are placed in a queue until they are processed. Currently, all queued requests are lost if the @@ -987,19 +993,19 @@ Supported Standards The following RFCs are supported by the DHCP-DDNS server: - *Secret Key Transaction Authentication for DNS (TSIG)*, `RFC 2845 - `__: All DNS Update packets sent and - received by DHCP-DDNS server can be protected by TSIG signatures. + `__: All DNS update packets sent and + received by the DHCP-DDNS server can be protected by TSIG signatures. - *Dynamic Updates in the Domain Name System (DNS UPDATE)*, `RFC 2136 - `__: The whole DNS Update mechanism is + `__: The complete DNS update mechanism is supported. - *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients*, `RFC 4703 - `__: The DHCP-DDNS takes care of the - conflict resolution. This capability is used by DHCPv4 and DHCPv6 servers. + `__: DHCP-DDNS takes care of + conflict resolution, for both DHCPv4 and DHCPv6 servers. - *A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)*, `RFC 4701 - `__: The DHCP-DDNS server uses the DHCID + `__: The DHCP-DDNS server uses DHCID records. diff -pruN 2.0.2-3/doc/sphinx/arm/dhcp4-srv.rst 2.2.0-1/doc/sphinx/arm/dhcp4-srv.rst --- 2.0.2-3/doc/sphinx/arm/dhcp4-srv.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/dhcp4-srv.rst 2022-07-26 06:08:02.000000000 +0000 @@ -11,26 +11,26 @@ Starting and Stopping the DHCPv4 Server It is recommended that the Kea DHCPv4 server be started and stopped using ``keactrl`` (described in :ref:`keactrl`); however, it is also -possible to run the server directly. It accepts the following -command-line switches: +possible to run the server directly via the ``kea-dhcp4`` command, which accepts +the following command-line switches: - ``-c file`` - specifies the configuration file. This is the only mandatory switch. - ``-d`` - specifies whether the server logging should be switched to - debug/verbose mode. In verbose mode, the logging severity and - debuglevel specified in the configuration file are ignored; - "debug" severity and the maximum debuglevel (99) are assumed. The - flag is convenient for temporarily switching the server into maximum - verbosity, e.g. when debugging. + debug/verbose mode. In verbose mode, the logging severity and debuglevel + specified in the configuration file are ignored; "debug" severity + and the maximum debuglevel (99) are assumed. The flag is convenient + for temporarily switching the server into maximum verbosity, e.g. + when debugging. - ``-p server-port`` - specifies the local UDP port on which the server - will listen. This is only useful during testing, as a DHCPv4 server + listens. This is only useful during testing, as a DHCPv4 server listening on ports other than the standard ones is not able to handle regular DHCPv4 queries. - ``-P client-port`` - specifies the remote UDP port to which the - server will send all responses. This is only useful during testing, + server sends all responses. This is only useful during testing, as a DHCPv4 server sending responses to ports other than the standard ones is not able to handle regular DHCPv4 queries. @@ -53,32 +53,32 @@ command-line switches: it is embedded in the executable binary. On startup, the server detects available network interfaces and -attempts to open UDP sockets on all interfaces mentioned in the -configuration file. Since the DHCPv4 server opens privileged ports, -this daemon must be run as root. +attempts to open UDP sockets on all interfaces listed in the +configuration file. Since the DHCPv4 server opens privileged ports, it +requires root access; this daemon must be run as root. During startup, the server attempts to create a PID file of the -form ``[runstatedir]/kea/[conf name].kea-dhcp4.pid``, where: +form: ``[runstatedir]/kea/[conf name].kea-dhcp4.pid``, where: -- ``runstatedir`` is the value as passed into the build configure +- ``runstatedir``: The value as passed into the build configure script; it defaults to ``/usr/local/var/run``. Note that this value may be overridden at runtime by setting the environment variable ``KEA_PIDFILE_DIR``, although this is intended primarily for testing purposes. -- ``conf name`` is the configuration file name used to start the server, +- ``conf name``: The configuration file name used to start the server, minus all preceding paths and the file extension. For example, given a pathname of ``/usr/local/etc/kea/myconf.txt``, the portion used would be ``myconf``. If the file already exists and contains the PID of a live process, the -server issues a DHCP4_ALREADY_RUNNING log message and exits. It is +server issues a ``DHCP4_ALREADY_RUNNING`` log message and exits. It is possible, though unlikely, that the file is a remnant of a system crash and the process to which the PID belongs is unrelated to Kea. In such a case, it would be necessary to manually delete the PID file. The server can be stopped using the ``kill`` command. When running in a -console, the server can also be shut down by pressing ctrl-c. Kea detects +console, the server can also be shut down by pressing Ctrl-c. Kea detects the key combination and shuts down gracefully. .. _dhcp4-configuration: @@ -124,7 +124,7 @@ be created. The basic configuration is a "subnet": "192.0.2.0/24", "pools": [ { - "pool": "192.0.2.1 - 192.0.2.200" + "pool": "192.0.2.1 - 192.0.2.200" } ] } @@ -146,25 +146,17 @@ curly bracket (or brace). Each configura specifying the configuration of the Kea module using it. In the example above, this object is called ``Dhcp4``. -.. note:: - - In the current Kea release it is possible to specify configurations - of multiple modules within a single configuration file, but this is - not recommended. Support for this type of configuration was removed in the 1.7.10 release, - including the ``Logging`` object; its previous content, the list - of loggers, must now be inside the ``Dhcp4`` object. - -The Dhcp4 configuration starts with the ``"Dhcp4": {`` line and ends +The ``Dhcp4`` configuration starts with the ``"Dhcp4": {`` line and ends with the corresponding closing brace (in the above example, the brace after the last comment). Everything defined between those lines is -considered to be the Dhcp4 configuration. +considered to be the ``Dhcp4`` configuration. In general, the order in which those parameters appear does not matter, but there are two caveats. The first one is that the configuration file must be well-formed JSON, meaning that the parameters for any given scope must be separated by a comma, and there must not be a comma after the last parameter. When reordering a -configuration file, keep in mind that moving a parameter to or from the +configuration file, moving a parameter to or from the last position in a given scope may also require moving the comma. The second caveat is that it is uncommon — although legal JSON — to repeat the same parameter multiple times. If that happens, the last occurrence @@ -184,10 +176,10 @@ client begins the renewal and rebind pro .. note:: - Beginning with Kea 1.6.0, the lease valid-lifetime is extended from a - single value to a triplet with minimum, default, and maximum values using + The lease valid lifetime is expressed as a triplet with minimum, default, and + maximum values using configuration entries ``min-valid-lifetime``, ``valid-lifetime``, and ``max-valid-lifetime``. - As of Kea 1.9.5, these values may be specified in client classes. The procedure + Since Kea 1.9.5, these values may be specified in client classes. The procedure the server uses to select which lifetime value to use is as follows: If the client query is a BOOTP query, the server always uses the @@ -224,13 +216,13 @@ client begins the renewal and rebind pro See section :ref:`dhcp4-t1-t2-times` for more details on generating T1 and T2. -The ``interfaces-config`` map specifies the server configuration -concerning the network interfaces on which the server should listen to -the DHCP messages. The ``interfaces`` parameter specifies a list of +The ``interfaces-config`` map specifies the +network interfaces on which the server should listen to +DHCP messages. The ``interfaces`` parameter specifies a list of network interfaces on which the server should listen. Lists are opened and closed with square brackets, with elements separated by commas. To -listen on two interfaces, the ``interfaces-config`` command should look -like this: +listen on two interfaces, the ``interfaces-config`` element should look like +this: :: @@ -238,17 +230,17 @@ like this: "interfaces": [ "eth0", "eth1" ] }, -The next couple of lines define the lease database, the place where the +The next lines define the lease database, the place where the server stores its lease information. This particular example tells the -server to use ``memfile``, which is the simplest and fastest database +server to use memfile, which is the simplest and fastest database backend. It uses an in-memory database and stores leases on disk in a -CSV (comma-separated values) file. This is a very simple configuration example; usually the lease -database configuration is more extensive and contains additional -parameters. Note that ``lease-database`` is an object and opens up a new -scope, using an opening brace. Its parameters (just one in this example: +CSV (comma-separated values) file. This is a very simple configuration example; +usually the lease database configuration is more extensive and contains +additional parameters. Note that ``lease-database`` is an object and opens up a +new scope, using an opening brace. Its parameters (just one in this example: ``type``) follow. If there were more than one, they would be separated by commas. This scope is closed with a closing brace. As more parameters -for the Dhcp4 definition follow, a trailing comma is present. +for the ``Dhcp4`` definition follow, a trailing comma is present. Finally, we need to define a list of IPv4 subnets. This is the most important DHCPv4 configuration structure, as the server uses that @@ -257,7 +249,7 @@ which the server is expected to receive specified with the ``subnet4`` parameter. It is a list, so it starts and ends with square brackets. Each subnet definition in the list has several attributes associated with it, so it is a structure and is -opened and closed with braces. At a minimum, a subnet definition has to +opened and closed with braces. At a minimum, a subnet definition must have at least two parameters: ``subnet``, which defines the whole subnet; and ``pools``, which is a list of dynamically allocated pools that are governed by the DHCP server. @@ -288,15 +280,15 @@ Note that indentation is optional and is only. In some cases it may be preferable to use more compact notation. After all the parameters have been specified, there are two contexts open: -global and Dhcp4; thus, two closing curly brackets are needed to close +``global`` and ``Dhcp4``; thus, two closing curly brackets must be used to close them. Lease Storage ------------- All leases issued by the server are stored in the lease database. -Currently there are four database backends available: memfile -(the default), MySQL, PostgreSQL, and Cassandra (deprecated). +There are three database backends available: memfile +(the default), MySQL, PostgreSQL. Memfile - Basic Storage for Leases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -310,10 +302,10 @@ less administration, an advantage of usi eliminates a dependency on third-party database software. The configuration of the memfile backend is controlled through -the Dhcp4/lease-database parameters. The ``type`` parameter is mandatory +the ``Dhcp4``/``lease-database`` parameters. The ``type`` parameter is mandatory and specifies which storage for leases the server should use, through -the ``memfile`` value. The following list gives additional optional parameters that -can be used to configure the memfile backend. +the ``"memfile"`` value. The following list gives additional optional parameters +that can be used to configure the memfile backend. - ``persist``: controls whether the new leases and updates to existing leases are written to the file. It is strongly recommended that the @@ -327,7 +319,7 @@ can be used to configure the memfile bac writing lease updates to the lease file. - ``name``: specifies an absolute location of the lease file in which - new leases and lease updates will be recorded. The default value for + new leases and lease updates are recorded. The default value for this parameter is ``"[kea-install-dir]/var/lib/kea/kea-leases4.csv"``. - ``lfc-interval``: specifies the interval, in seconds, at which the @@ -335,8 +327,7 @@ can be used to configure the memfile bac redundant (historical) information from the lease file and effectively reduces the lease file size. The cleanup process is described in more detail later in this section. The default - value of the ``lfc-interval`` is ``3600``. A value of 0 disables the - LFC. + value of the ``lfc-interval`` is ``3600``. A value of ``0`` disables the LFC. - ``max-row-errors``: specifies the number of row errors before the server stops attempting to load a lease file. When the server loads a lease file, it is processed @@ -344,10 +335,12 @@ can be used to configure the memfile bac cannot be processed correctly the server logs it, discards the row, and goes on to the next row. This parameter can be used to set a limit on the number of such discards that can occur, after which the server - abandons the effort and exits. The default value of 0 disables the limit + abandons the effort and exits. The default value of ``0`` disables the limit and allows the server to process the entire file, regardless of how many rows are discarded. +An example configuration of the memfile backend is presented below: + :: "Dhcp4": { @@ -363,8 +356,8 @@ can be used to configure the memfile bac This configuration selects ``/tmp/kea-leases4.csv`` as the storage for lease information and enables persistence (writing lease updates to this file). It also configures the backend to perform a periodic cleanup -of the lease file every 1800 seconds (30 minutes) and sets the maximum number of row -errors to 100. +of the lease file every 1800 seconds (30 minutes) and sets the maximum number of +row errors to 100. Why Is Lease File Cleanup Necessary? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -431,8 +424,8 @@ Lease Database Configuration :ref:`pgsql-database-create`. Lease database configuration is controlled through the -Dhcp4/``lease-database`` parameters. The database type must be set to -``memfile``, ``mysql``, ``postgresql``, or `cql``, e.g.: +``Dhcp4``/``lease-database`` parameters. The database type must be set to +``memfile``, ``mysql`` or ``postgresql``, e.g.: :: @@ -440,8 +433,7 @@ Dhcp4/``lease-database`` parameters. The Next, the name of the database to hold the leases must be set; this is the name used when the database was created (see -:ref:`mysql-database-create`, :ref:`pgsql-database-create`, or -:ref:`cql-database-create`). +:ref:`mysql-database-create` or :ref:`pgsql-database-create`). For MySQL or PostgreSQL: @@ -449,12 +441,6 @@ For MySQL or PostgreSQL: "Dhcp4": { "lease-database": { "name": "database-name" , ... }, ... } -For Cassandra: - -:: - - "Dhcp4": { "lease-database": { "keyspace": "database-name" , ... }, ... } - If the database is located on a different system from the DHCPv4 server, the database host name must also be specified: @@ -462,8 +448,6 @@ the database host name must also be spec "Dhcp4": { "lease-database": { "host": "remote-host-name", ... }, ... } -(It should be noted that this configuration may have a severe impact on server performance.) - Normally, the database is on the same machine as the DHCPv4 server. In this case, set the value to the empty string: @@ -498,12 +482,10 @@ specified: "Dhcp4": { "lease-database": { "max-reconnect-tries" : number-of-tries, ... }, ... } If the server is unable to reconnect to the database after making the -maximum number of attempts, the server will exit. A value of zero (the +maximum number of attempts, the server will exit. A value of 0 (the default) disables automatic recovery and the server will exit immediately upon detecting a loss of connectivity (MySQL and PostgreSQL -only). For Cassandra, Kea uses an interface that connects to -all nodes in a cluster at the same time. Any connectivity issues should -be handled by internal Cassandra mechanisms. +only). The number of milliseconds the server waits between attempts to reconnect to the lease database after connectivity has been lost may @@ -515,7 +497,7 @@ also be specified: The default value for MySQL and PostgreSQL is 0, which disables automatic recovery and causes the server to exit immediately upon detecting the -loss of connectivity. The default value for Cassandra is 2000 ms. +loss of connectivity. :: @@ -537,11 +519,11 @@ The possible values are: .. note:: Automatic reconnection to database backends is configured individually per - backend. This allows users to tailor the recovery parameters to each backend - they use. We do suggest that users enable it either for all backends or none, + backend; this allows users to tailor the recovery parameters to each backend + they use. We suggest that users enable it either for all backends or none, so behavior is consistent. - Losing connectivity to a backend for which reconnect is disabled results + Losing connectivity to a backend for which reconnection is disabled results (if configured) in the server shutting itself down. This includes cases when the lease database backend and the hosts database backend are connected to the same database instance. @@ -552,13 +534,6 @@ The possible values are: exclusively as a configuration tool. The host parameter is used by the MySQL and PostgreSQL backends. -Cassandra has a concept of contact points that can be used to -contact the cluster, instead of a single IP or hostname. It takes a -list of comma-separated IP addresses, which may be specified as: - -:: - - "Dhcp4": { "lease-database": { "contact-points" : "192.0.2.1,192.0.2.2", ... }, ... } Finally, the credentials of the account under which the server will access the database should be set: @@ -573,82 +548,6 @@ access the database should be set: If there is no password to the account, set the password to the empty string ``""``. (This is the default.) -.. _cassandra-database-configuration4: - -Cassandra-Specific Parameters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Cassandra backend is configured slightly differently. Cassandra has -a concept of contact points that can be used to contact the cluster, -instead of a single IP or hostname. It takes a list of comma-separated -IP addresses, which may be specified as: - -:: - - "Dhcp4": { - "lease-database": { - "type": "cql", - "contact-points": "ip-address1, ip-address2 [,...]", - ... - }, - ... - } - -Cassandra also supports a number of optional parameters: - -- ``reconnect-wait-time`` - governs how long Kea waits before - attempting to reconnect. Expressed in milliseconds. The default is - 2000 [ms]. - -- ``connect-timeout`` - sets the timeout for connecting to a node. - Expressed in milliseconds. The default is 5000 [ms]. - -- ``request-timeout`` - sets the timeout for waiting for a response - from a node. Expressed in milliseconds. The default is 12000 [ms]. - -- ``tcp-keepalive`` - governs the TCP keep-alive mechanism. Expressed - in seconds of delay. If the parameter is not present, the mechanism - is disabled. - -- ``tcp-nodelay`` - enables/disables Nagle's algorithm on connections. - The default is ``true``. - -- ``consistency`` - configures the consistency level. The default is - "quorum". Supported values: any, one, two, three, quorum, all, - local-quorum, each-quorum, serial, local-serial, local-one. See - `Cassandra - consistency `__ - for more details. - -- ``serial-consistency`` - configures the serial consistency level, which - manages lightweight transaction isolation. The default is "serial". - Supported values: any, one, two, three, quorum, all, local-quorum, - each-quorum, serial, local-serial, local-one. See `Cassandra serial - consistency `__ - for more details. - -For example, a complex Cassandra configuration with most parameters -specified could look as follows: - -:: - - "Dhcp4": { - "lease-database": { - "type": "cql", - "keyspace": "keatest", - "contact-points": "192.0.2.1, 192.0.2.2, 192.0.2.3", - "port": 9042, - "reconnect-wait-time": 2000, - "connect-timeout": 5000, - "request-timeout": 12000, - "tcp-keepalive": 1, - "tcp-nodelay": true - }, - ... - } - -Similar parameters can be specified for the hosts database. - .. _hosts4-storage: Hosts Storage @@ -660,7 +559,7 @@ lease database. In fact, the Kea server each purpose, be it lease or hosts information, which gives the most flexibility. Kea can keep leases and host reservations separately, but can also point to the same database. Currently the -supported hosts database types are MySQL, PostgreSQL, and Cassandra. +supported hosts database types are MySQL and PostgreSQL. The following configuration can be used to configure a connection to MySQL: @@ -678,6 +577,9 @@ connection to MySQL: } } +Depending on the database configuration, many of the +parameters may be optional. + Please note that usage of hosts storage is optional. A user can define all host reservations in the configuration file, and that is the recommended way if the number of reservations is small. However, when @@ -706,7 +608,7 @@ DHCPv4 Hosts Database Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hosts database configuration is controlled through the -Dhcp4/``hosts-database`` parameters. If enabled, the type of database must +``Dhcp4``/``hosts-database`` parameters. If enabled, the type of database must be set to ``mysql`` or ``postgresql``. :: @@ -729,8 +631,6 @@ the database host name must also be spec "Dhcp4": { "hosts-database": { "host": remote-host-name, ... }, ... } -(Again, it should be noted that this configuration may have a severe impact on server performance.) - Normally, the database is on the same machine as the DHCPv4 server. In this case, set the value to the empty string: @@ -754,7 +654,7 @@ specified: "Dhcp4": { "hosts-database": { "max-reconnect-tries" : number-of-tries, ... }, ... } If the server is unable to reconnect to the database after making the -maximum number of attempts, the server will exit. A value of zero (the +maximum number of attempts, the server will exit. A value of 0 (the default) disables automatic recovery and the server will exit immediately upon detecting a loss of connectivity (MySQL and PostgreSQL only). @@ -769,7 +669,7 @@ be specified: The default value for MySQL and PostgreSQL is 0, which disables automatic recovery and causes the server to exit immediately upon detecting the -loss of connectivity. The default value for Cassandra is 2000 ms. +loss of connectivity. :: @@ -792,10 +692,10 @@ The possible values are: Automatic reconnection to database backends is configured individually per backend. This allows users to tailor the recovery parameters to each backend - they use. We do suggest that users enable it either for all backends or none, + they use. We suggest that users enable it either for all backends or none, so behavior is consistent. - Losing connectivity to a backend for which reconnect is disabled results + Losing connectivity to a backend for which reconnection is disabled results (if configured) in the server shutting itself down. This includes cases when the lease database backend and the hosts database backend are connected to the same database instance. @@ -813,7 +713,7 @@ access the database should be set: If there is no password to the account, set the password to the empty string ``""``. (This is the default.) -The multiple storage extension uses a similar syntax; a configuration is +The multiple-storage extension uses a similar syntax; a configuration is placed into a ``hosts-databases`` list instead of into a ``hosts-database`` entry, as in: @@ -821,8 +721,6 @@ entry, as in: "Dhcp4": { "hosts-databases": [ { "type": "mysql", ... }, ... ], ... } -For Cassandra-specific parameters, see :ref:`cassandra-database-configuration4`. - If the same host is configured both in-file and in-database, Kea does not issue a warning, as it would if both were specified in the same data source. Instead, the host configured in-file has priority over the one configured @@ -844,7 +742,7 @@ create a view of a Kea hosts database an read-only. Kea host-database backends operate with an implicit configuration to -both read from and write to the database. If the database user does not +both read from and write to the database. If the user does not have write access to the host database, the backend will fail to start and the server will refuse to start (or reconfigure). However, if access to a read-only host database is required for retrieving reservations @@ -883,7 +781,6 @@ server to listen on all available interf ... }, - The asterisk plays the role of a wildcard and means "listen on all interfaces." However, it is usually a good idea to explicitly specify interface names: @@ -910,8 +807,7 @@ with explicit interface names: ... } - -This form of usage should only be used when it is +This format should only be used when it is desired to temporarily override a list of interface names and listen on all interfaces. @@ -1011,7 +907,7 @@ that link. To use a single address on su that raw sockets will be used! The use of raw sockets to handle traffic from the directly connected clients is currently supported on Linux and BSD systems only. If raw sockets are not - supported on the particular OS in use, the server will issue a warning and + supported on the particular OS in use, the server issues a warning and fall back to using IP/UDP sockets. In a typical environment, the DHCP server is expected to send back a @@ -1056,7 +952,7 @@ disabled by setting the ``re-detect`` va Note that interfaces are not re-detected during ``config-test``. -Usually loopback interfaces (e.g. the `lo` or `lo0` interface) are not +Usually loopback interfaces (e.g. the ``lo`` or ``lo0`` interface) are not configured, but if a loopback interface is explicitly configured and IP/UDP sockets are specified, the loopback interface is accepted. @@ -1073,6 +969,50 @@ loopback interface, to service a relayed ... } +Kea binds the service sockets for each interface on startup. If another +process is already using a port, then Kea logs the message and suppresses an +error. DHCP service runs, but it is unavailable on some interfaces. + +The "service-sockets-require-all" option makes Kea require all sockets to +be successfully bound. If any opening fails, Kea interrupts the +initialization and exits with a non-zero status. (Default is false). + +:: + + "Dhcp4": { + "interfaces-config": { + "interfaces": [ "eth1", "eth3" ], + "service-sockets-require-all": true + }, + ... + } + +Sometimes, immediate interruption isn't a good choice. The port can be +unavailable only temporary. In this case, retrying the opening may resolve +the problem. Kea provides two options to specify the retrying: +``service-sockets-max-retries`` and ``service-sockets-retry-wait-time``. + +The first defines a maximal number of retries that Kea makes to open a socket. +The zero value (default) means that the Kea doesn't retry the process. + +The second defines a wait time (in milliseconds) between attempts. The default +value is 5000 (5 seconds). + +:: + + "Dhcp4": { + "interfaces-config": { + "interfaces": [ "eth1", "eth3" ], + "service-sockets-max-retries": 5, + "service-sockets-retry-wait-time": 5000 + }, + ... + } + +If "service-sockets-max-retries" is non-zero and "service-sockets-require-all" +is false, then Kea retries the opening (if needed) but does not fail if any +socket is still not opened. + .. _dhcpinform-unicast-issues: Issues With Unicast Responses to DHCPINFORM @@ -1130,7 +1070,7 @@ subnet. In principle, it is used to asso respective subnets. When a subnet identifier is not specified for a subnet being configured, it is automatically assigned by the configuration mechanism. The identifiers are assigned starting at 1 and are -monotonically increased for each subsequent subnet: 1, 2, 3 .... +monotonically increased for each subsequent subnet: 1, 2, 3, .... If there are multiple subnets configured with auto-generated identifiers and one of them is removed, the subnet identifiers may be renumbered. @@ -1169,8 +1109,8 @@ of the subnet identifier. IPv4 Subnet Prefix ------------------ -The subnet prefix is the second way to identify a subnet. It does not -need to have the address part to match the prefix length; for instance, +The subnet prefix is the second way to identify a subnet. Kea can +accept non-canonical subnet addresses; for instance, this configuration is accepted: :: @@ -1184,8 +1124,8 @@ this configuration is accepted: ] } -This works even if there is another subnet with the "192.0.2.0/24" prefix; only the -textual form of subnets are compared to avoid duplicates. +This works even if there is another subnet with the "192.0.2.0/24" prefix; +only the textual form of subnets are compared to avoid duplicates. .. note:: @@ -1201,8 +1141,8 @@ The main role of a DHCPv4 server is addr server must be configured with at least one subnet and one pool of dynamic addresses to be managed. For example, assume that the server is connected to a network segment that uses the 192.0.2.0/24 prefix. The -administrator of that network decides that addresses from range -192.0.2.10 to 192.0.2.20 are going to be managed by the Dhcp4 server. +administrator of that network decides that addresses from the range +192.0.2.10 to 192.0.2.20 are going to be managed by the DHCPv4 server. Such a configuration can be achieved in the following way: :: @@ -1232,8 +1172,8 @@ It is possible to define more than one p previous example, further assume that 192.0.2.64/26 should also be managed by the server. It could be written as 192.0.2.64 to 192.0.2.127, or it can be expressed more simply as 192.0.2.64/26. Both -formats are supported by Dhcp4 and can be mixed in the pool list. For -example, one could define the following pools: +formats are supported by ``Dhcp4`` and can be mixed in the pool list. For +example, the following pools could be defined: :: @@ -1257,7 +1197,8 @@ the hyphen are optional. They can be use The number of pools is not limited, but for performance reasons it is recommended to use as few as possible. -The server may be configured to serve more than one subnet: +The server may be configured to serve more than one subnet. To add a +second subnet, use a command similar to the following: :: @@ -1288,7 +1229,29 @@ can use a given pool, it is also able to address) address from that pool. In the aforementioned example of pool 192.0.3.0/24, both the 192.0.3.0 and 192.0.3.255 addresses may be assigned as well. This may be invalid in some network configurations. To -avoid this, use the "min-max" notation. +avoid this, use the ``min-max`` notation. + +.. note:: + + Here are some liberties and limits to the values that subnets and pools can + take in Kea configurations that are out of the ordinary: + + +-------------------------------------------------------------+---------+--------------------------------------------------------------------------------------+ + | Kea configuration case | Allowed | Comment | + +=============================================================+=========+======================================================================================+ + | Overlapping subnets | Yes | Administrator should consider how clients are matched to these subnets. | + +-------------------------------------------------------------+---------+--------------------------------------------------------------------------------------+ + | Overlapping pools in one subnet | No | Startup error: DHCP4_PARSER_FAIL | + +-------------------------------------------------------------+---------+--------------------------------------------------------------------------------------+ + | Overlapping address pools in different subnets | Yes | Specifying the same address pool in different subnets can be used as an equivalent | + | | | of the global address pool. In that case, the server can assign addresses from the | + | | | same range regardless of the client's subnet. If an address from such a pool is | + | | | assigned to a client in one subnet, the same address will be renewed for this | + | | | client if it moves to another subnet. Another client in a different subnet will | + | | | not be assigned an address already assigned to the client in any of the subnets. | + +-------------------------------------------------------------+---------+--------------------------------------------------------------------------------------+ + | Pools not matching the subnet prefix | No | Startup error: DHCP4_PARSER_FAIL | + +-------------------------------------------------------------+---------+--------------------------------------------------------------------------------------+ .. _dhcp4-t1-t2-times: @@ -1325,8 +1288,6 @@ Calculating the values is controlled by T2. It is expressed as a real number between 0.0 and 1.0 and must be greater than ``t1-percent``. The default value is .875, per RFC 2131. -.. - .. note:: In the event that both explicit values are specified and @@ -1384,9 +1345,9 @@ subnets. Note that either ``name`` or ``code`` is required; there is no need to -specify both. ``space`` has a default value of "dhcp4", so this can be skipped +specify both. ``space`` has a default value of ``dhcp4``, so this can be skipped as well if a regular (not encapsulated) DHCPv4 option is defined. -Finally, ``csv-format`` defaults to "true", so it too can be skipped, unless +Finally, ``csv-format`` defaults to ``true``, so it too can be skipped, unless the option value is specified as a hexadecimal string. Therefore, the above example can be simplified to: @@ -1405,7 +1366,7 @@ the above example can be simplified to: Defined options are added to the response when the client requests them, with a few exceptions which are always added. To enforce the addition of -a particular option, set the ``always-send`` flag to "true" as in: +a particular option, set the ``always-send`` flag to ``true`` as in: :: @@ -1461,7 +1422,7 @@ The ``name`` parameter specifies the opt currently supported names, see :ref:`dhcp4-std-options-list` below. The ``code`` parameter specifies the option code, which must match one of the values from that list. The next line specifies the -option space, which must always be set to "dhcp4" as these are standard +option space, which must always be set to ``dhcp4`` as these are standard DHCPv4 options. For other option spaces, including custom option spaces, see :ref:`dhcp4-option-spaces`. The next line specifies the format in which the data will be entered; use of CSV (comma-separated values) is @@ -1470,10 +1431,10 @@ clients. The data parameter is specified commas if more than one value is allowed. Options can also be configured as hexadecimal values. If ``csv-format`` -is set to "false", option data must be specified as a hexadecimal string. +is set to ``false``, option data must be specified as a hexadecimal string. The following commands configure the ``domain-name-servers`` option for all subnets with the following addresses: 192.0.3.1 and 192.0.3.2. Note that -``csv-format`` is set to "false". +``csv-format`` is set to ``false``. :: @@ -1494,20 +1455,20 @@ subnets with the following addresses: 19 Kea supports the following formats when specifying hexadecimal data: - ``Delimited octets`` - one or more octets separated by either colons or - spaces (':' or ' '). While each octet may contain one or two digits, + spaces (":" or " "). While each octet may contain one or two digits, we strongly recommend always using two digits. Valid examples are - `ab:cd:ef` and `ab cd ef`. + "ab:cd:ef" and "ab cd ef". - ``String of digits`` - a continuous string of hexadecimal digits with - or without a `0x` prefix. Valid examples are `0xabcdef` and `abcdef`. + or without a "0x" prefix. Valid examples are "0xabcdef" and "abcdef". Care should be taken to use proper encoding when using hexadecimal format; Kea's ability to validate data correctness in hexadecimal is limited. -As of Kea 1.6.0, it is also possible to specify data for binary options as +It is also possible to specify data for binary options as a single-quoted text string within double quotes as shown (note that -``csv-format`` must be set to false): +``csv-format`` must be set to ``false``): :: @@ -1597,21 +1558,15 @@ obtains an address from the given pool: ... } -Options can also be specified in class or host reservation scope. The +Options can also be specified in class or host-reservation scope. The current Kea options precedence order is (from most important to least): host reservation, pool, subnet, shared network, class, global. -The currently supported standard DHCPv4 options are listed in -:ref:`dhcp4-std-options-list`. "Name" and "Code" are the -values that should be used as a name/code in the option-data structures. -"Type" designates the format of the data; the meanings of the various -types are given in :ref:`dhcp-types`. - -When a data field is a string and that string contains the comma (,; -U+002C) character, the comma must be escaped with two backslashes (\; +When a data field is a string and that string contains the comma (``,``; +U+002C) character, the comma must be escaped with two backslashes (``\\,``; U+005C). This double escape is required because both the routine splitting of CSV data into fields and JSON use the same escape character; a -single escape (\,) would make the JSON invalid. For example, the string +single escape (``\,``) would make the JSON invalid. For example, the string "foo,bar" must be represented as: :: @@ -1650,14 +1605,20 @@ option format defined in the RFCs. There for standard options for which Kea currently does not provide a definition. To use such options, a server administrator must create a definition as described in -:ref:`dhcp4-custom-options` in the "dhcp4" option space. This +:ref:`dhcp4-custom-options` in the ``dhcp4`` option space. This definition should match the option format described in the relevant RFC, but the configuration mechanism will allow any option format as it currently has no means to validate it. +The currently supported standard DHCPv4 options are listed in +the table below. "Name" and "Code" are the +values that should be used as a name/code in the option-data structures. +"Type" designates the format of the data; the meanings of the various +types are given in :ref:`dhcp-types`. + .. _dhcp4-std-options-list: -.. table:: List of Standard DHCPv4 Options Configurable by an Administrator +.. table:: List of standard DHCPv4 options configurable by an administrator +----------------------------------------+------+---------------------------+-------------+-------------+ | Name | Code | Type | Array? | Returned if | @@ -1836,7 +1797,7 @@ currently has no means to validate it. +----------------------------------------+------+---------------------------+-------------+-------------+ | netinfo-server-tag | 113 | string | false | false | +----------------------------------------+------+---------------------------+-------------+-------------+ - | default-url | 114 | string | false | false | + | v4-captive-portal | 114 | string | false | false | +----------------------------------------+------+---------------------------+-------------+-------------+ | auto-config | 116 | uint8 | false | false | +----------------------------------------+------+---------------------------+-------------+-------------+ @@ -1862,8 +1823,6 @@ currently has no means to validate it. +----------------------------------------+------+---------------------------+-------------+-------------+ | v4-portparams | 159 | record (uint8, psid) | false | false | +----------------------------------------+------+---------------------------+-------------+-------------+ - | v4-captive-portal | 160 | string | false | false | - +----------------------------------------+------+---------------------------+-------------+-------------+ | option-6rd | 212 | record (uint8, uint8, | true | false | | | | ipv6-address, | | | | | | ipv4-address) | | | @@ -1871,11 +1830,19 @@ currently has no means to validate it. | v4-access-domain | 213 | fqdn | false | false | +----------------------------------------+------+---------------------------+-------------+-------------+ +.. note:: + + The ``default-url`` option was replaced with ``v4-captive-portal`` in Kea 2.1.2, as introduced by + `RFC 8910 `_. The new option has exactly the same format as the + old one. The general perception is that ``default-url`` was seldom used. If you used it and migrating, + please replace ``default-url`` with ``v4-captive-portal`` and your configuration will continue to work + as before. + Kea also supports other options than those listed above; the following options are returned by the Kea engine itself and in general should not be configured manually. -.. table:: List of Standard DHCPv4 Options Managed by Kea on Its Own and Not Directly Configurable by an Administrator +.. table:: List of standard DHCPv4 options managed by Kea on its own and not directly configurable by an administrator +--------------------------------+-------+---------------------------------------+-------------------------------------------------------------------+ | Name | Code | Type | Description | @@ -1902,9 +1869,9 @@ manually. | fqdn | 81 | record (uint8, uint8, uint8, fqdn) | part of the DDNS and D2 configuration. | +--------------------------------+-------+---------------------------------------+-------------------------------------------------------------------+ | dhcp-agent-options | 82 | empty | sent by the relay agent. This is an empty container option; see | - | | | | RAI option detail in later part of this section. | + | | | | RAI option detail later in this section. | +--------------------------------+-------+---------------------------------------+-------------------------------------------------------------------+ - | authenticate | 90 | binary | sent by client, kea does not validate it yet. | + | authenticate | 90 | binary | sent by client, Kea does not yet validate it. | +--------------------------------+-------+---------------------------------------+-------------------------------------------------------------------+ | client-last-transaction-time | 91 | uint32 | sent by client, server does not set it. | +--------------------------------+-------+---------------------------------------+-------------------------------------------------------------------+ @@ -1919,7 +1886,7 @@ what values are accepted for them. .. _dhcp-types: -.. table:: List of Standard DHCP Option Types +.. table:: List of standard DHCP option types +-----------------+-------------------------------------------------------+ | Name | Meaning | @@ -1975,33 +1942,33 @@ what values are accepted for them. | string | Any text. Please note that Kea | | | silently discards any | | | terminating/trailing nulls from | - | | the end of 'string' options when | + | | the end of "string" options when | | | unpacking received packets. This | | | is in keeping with `RFC 2132, | | | Section | | | 2 `__. | +-----------------+-------------------------------------------------------+ - | tuple | A length encoded as an 8- (16- | - | | for DHCPv6) bit unsigned integer | + | tuple | A length encoded as an 8-bit (16-bit | + | | for DHCPv6) unsigned integer | | | followed by a string of this | | | length. | +-----------------+-------------------------------------------------------+ - | uint8 | 8-bit unsigned integer with | + | uint8 | An 8-bit unsigned integer with | | | allowed values 0 to 255. | +-----------------+-------------------------------------------------------+ - | uint16 | 16-bit unsigned integer with | + | uint16 | A 16-bit unsigned integer with | | | allowed values 0 to 65535. | +-----------------+-------------------------------------------------------+ - | uint32 | 32-bit unsigned integer with | + | uint32 | A 32-bit unsigned integer with | | | allowed values 0 to 4294967295. | +-----------------+-------------------------------------------------------+ - | int8 | 8-bit signed integer with allowed | + | int8 | An 8-bit signed integer with allowed | | | values -128 to 127. | +-----------------+-------------------------------------------------------+ - | int16 | 16-bit signed integer with | + | int16 | A 16-bit signed integer with | | | allowed values -32768 to 32767. | +-----------------+-------------------------------------------------------+ - | int32 | 32-bit signed integer with | + | int32 | A 32-bit signed integer with | | | allowed values -2147483648 to | | | 2147483647. | +-----------------+-------------------------------------------------------+ @@ -2012,7 +1979,7 @@ on its own. The following table contains and its sub-options are inserted by the relay agent and received by Kea; there is no need for Kea to be configured with those options. -.. table:: List of RAI Sub-options That Kea Can Understand. +.. table:: List of RAI sub-options that Kea can understand +--------------------+------+----------------------------------------------------------------------+ | Name | Code | Comment | @@ -2025,11 +1992,13 @@ to be configured with those options. +--------------------+------+----------------------------------------------------------------------+ | subscriber-id | 6 | Can be used with flex-id to identify hosts. | +--------------------+------+----------------------------------------------------------------------+ + | server-id-override | 11 | If sent by the relay, Kea accepts it as the `server-id`. | + +--------------------+------+----------------------------------------------------------------------+ | relay-source-port | 19 | If sent by the relay, Kea sends back its responses to this port. | +--------------------+------+----------------------------------------------------------------------+ All other RAI sub-options can be used in client classification to classify incoming packets to specific classes -and/or by flex-id to construct a unique device identifier. +and/or by ``flex-id`` to construct a unique device identifier. .. _dhcp4-custom-options: @@ -2037,9 +2006,9 @@ Custom DHCPv4 Options --------------------- Kea supports custom (non-standard) DHCPv4 options. Let's say that we want -to define a new DHCPv4 option called "foo", which will have code 222 -and will convey a single, unsigned, 32-bit integer value. We can define -such an option by putting the following entry in the configuration file: +to define a new DHCPv4 option called ``foo``, which will have code 222 +and will convey a single, unsigned, 32-bit integer value. +Such an option can be defined by putting the following entry in the configuration file: :: @@ -2059,7 +2028,7 @@ such an option by putting the following } The ``false`` value of the ``array`` parameter determines that the -option does NOT comprise an array of "uint32" values but is, instead, a +option does NOT comprise an array of ``uint32`` values but is, instead, a single value. Two other parameters have been left blank: ``record-types`` and ``encapsulate``. The former specifies the comma-separated list of option data fields, if the option comprises a @@ -2074,7 +2043,7 @@ not set its value(s). The ``name``, ``code``, and ``type`` parameters are required; all others are optional. The ``array`` default value is ``false``. The ``record-types`` and ``encapsulate`` default values are blank (``""``). -The default ``space`` is "dhcp4". +The default ``space`` is ``dhcp4``. Once the new option format is defined, its value is set in the same way as for a standard option. For example, the following commands set a @@ -2121,12 +2090,12 @@ defined in the following way: ... } -The ``type`` is set to "record" to indicate that the option contains +The ``type`` is set to ``"record"`` to indicate that the option contains multiple values of different types. These types are given as a comma-separated list in the ``record-types`` field and should be ones from those listed in :ref:`dhcp-types`. -The values of the option are set in an ``option-data`` statement as follows: +The option's values are set in an ``option-data`` statement as follows: :: @@ -2143,12 +2112,12 @@ The values of the option are set in an ` ... } -``csv-format`` is set to ``true`` to indicate that the ``data`` field +``csv-format`` is set to ``"true"`` to indicate that the ``data`` field comprises a comma-separated list of values. The values in ``data`` must correspond to the types set in the ``record-types`` field of the option definition. -When ``array`` is set to ``true`` and ``type`` is set to "record", the +When ``array`` is set to ``"true"`` and ``type`` is set to ``"record"``, the last field is an array, i.e. it can contain more than one value, as in: :: @@ -2168,8 +2137,8 @@ last field is an array, i.e. it can cont ... } -The new option content is one IPv4 address followed by one or more 16- -bit unsigned integers. +The new option content is one IPv4 address followed by one or more 16-bit +unsigned integers. .. note:: @@ -2214,7 +2183,7 @@ PXEClient vendor: ... } -As the Vendor-Specific Information (VSI) option (code 43) has vendor-specific +As the Vendor-Specific Information (VSI) option (code 43) has a vendor-specific format, i.e. can carry either raw binary value or sub-options, this mechanism is also available for this option. @@ -2332,7 +2301,7 @@ The definition used to decode a VSI opti - If not defined at global scope nor in a client class to which the packet belongs, the built-in last resort definition is used. This definition only says the sub-option space is - "vendor-encapsulated-options-space". + ``"vendor-encapsulated-options-space"``. The output definition selection is a bit simpler: @@ -2356,13 +2325,13 @@ DHCPv4 Vendor-Specific Options ------------------------------ Currently there are two option spaces defined for the DHCPv4 daemon: -"dhcp4" (for the top-level DHCPv4 options) and -"vendor-encapsulated-options-space", which is empty by default but in +``dhcp4`` (for the top-level DHCPv4 options) and +``"vendor-encapsulated-options-space"``, which is empty by default but in which options can be defined. Those options are carried in the Vendor-Specific Information option (code 43). The following examples -show how to define an option "foo" with code 1 that +show how to define an option ``foo`` with code 1 that comprises an IPv4 address, an unsigned 16-bit integer, and a string. The -"foo" option is conveyed in a Vendor-Specific Information option. +``foo`` option is conveyed in a Vendor-Specific Information option. The first step is to define the format of the option: @@ -2384,7 +2353,7 @@ The first step is to define the format o } (Note that the option space is set to -``vendor-encapsulated-options-space``.) Once the option format is defined, +``"vendor-encapsulated-options-space"``.) Once the option format is defined, the next step is to define actual values for that option: :: @@ -2403,7 +2372,7 @@ the next step is to define actual values } In this example, we also include the Vendor-Specific Information option, which -conveys our sub-option "foo". This is required; otherwise, the option +conveys our sub-option ``foo``. This is required; otherwise, the option will not be included in messages sent to the client. :: @@ -2432,12 +2401,24 @@ Alternatively, the option can be specifi Another popular option that is often somewhat imprecisely called the "vendor option" is option 125. Its proper name is the "vendor-independent -vendor-specific information option" or "vivso". The idea behind vivso -options is that each vendor has its own unique set of options with their -own custom formats. The vendor is identified by a 32-bit unsigned integer -called `enterprise-id` or `vendor-id`. For example, vivso with vendor-id -4491 represents DOCSIS options, and they are often seen -when dealing with cable modems. +vendor-specific information option" or "vivso". The idea behind vivso options +is that each vendor has its own unique set of options with their own custom +formats. The vendor is identified by a 32-bit unsigned integer called +``enterprise-number`` or ``vendor-id``. + + +The standard spaces defined in Kea and their options are: + +- ``vendor-4491``: Cable Television Laboratories, Inc. for DOCSIS3 options: + ++-------------+--------------+------------------------------------------------------------------------+ +| option code | option name | option description | ++=============+==============+========================================================================+ +| 1 | oro | ORO (or Option Request Option) is used by clients to request a list of | +| | | options they are interested in. | ++-------------+--------------+------------------------------------------------------------------------+ +| 2 | tftp-servers | a list of IPv4 addresses of TFTP servers to be used by the cable modem | ++-------------+--------------+------------------------------------------------------------------------+ In Kea each vendor is represented by its own vendor space. Since there are hundreds of vendors and sometimes they use different option @@ -2506,17 +2487,21 @@ following: } ] } -By default Kea sends back +By default, Kea sends back only those options that are requested by a client, unless there are protocol rules that tell the DHCP server to always send an option. This approach works nicely in most cases and avoids problems with clients -refusing responses with options they don't understand. Unfortunately, -this is more complex when we consider vendor options. Some vendors (such +refusing responses with options they do not understand. However, +the situation with vendor options is more complex, as they +are not requested the same way as other options, are +not well-documented in official RFCs, or vary by vendor. + +Some vendors (such as DOCSIS, identified by vendor option 4491) have a mechanism to request specific vendor options and Kea is able to honor those. -Unfortunately, for many other vendors, such as Genexis (25167) as discussed -above, Kea does not have such a mechanism, so it cannot send any -sub-options on its own. To solve this issue, we came up with the concept of +Unfortunately, for many other vendors, such as Genexis (25167, discussed +above), Kea does not have such a mechanism, so it cannot send any +sub-options on its own. To solve this issue, we devised the concept of persistent options. Kea can be told to always send options, even if the client did not request them. This can be achieved by adding ``"always-send": true`` to the option definition. Note that in this @@ -2532,8 +2517,8 @@ and ``doc/examples/kea6/vivso.json`` in .. note:: - Currently only one vendor is supported for vivco-suboptions (code 124) - and vivso-suboptions (code 125) options. Specifying + Currently only one vendor is supported for the ``vivco-suboptions`` (code 124) + and ``vivso-suboptions`` (code 125) options. Specifying multiple enterprise numbers within a single option instance or multiple options with different enterprise numbers is not supported. @@ -2544,7 +2529,7 @@ Nested DHCPv4 Options (Custom Option Spa It is sometimes useful to define a completely new option space, such as when a user creates a new option in the standard option space -("dhcp4") and wants this option to convey sub-options. Since they are in +(``dhcp4``) and wants this option to convey sub-options. Since they are in a separate space, sub-option codes have a separate numbering scheme and may overlap with the codes of standard options. @@ -2553,7 +2538,7 @@ defining sub-options for a standard opti default if the standard option is meant to convey any sub-options (see :ref:`dhcp4-vendor-opts`). -If we want a DHCPv4 option called "container" with code +If we want a DHCPv4 option called ``container`` with code 222, that conveys two sub-options with codes 1 and 2, we first need to define the new sub-options: @@ -2608,7 +2593,7 @@ and specify that it should include optio } The name of the option space in which the sub-options are defined is set -in the ``encapsulate`` field. The ``type`` field is set to ``empty``, to +in the ``encapsulate`` field. The ``type`` field is set to ``"empty"``, to indicate that this option does not carry any data other than sub-options. @@ -2641,14 +2626,14 @@ Finally, we can set values for the new o It is possible to create an option which carries some data in addition to the sub-options defined in the encapsulated option space. -For example, if the ``"container"`` option from the previous example were +For example, if the ``container`` option from the previous example were required to carry a uint16 value as well as the sub-options, the ``type`` value would have to be set to ``"uint16"`` in the option definition. (Such an option would then have the following data structure: DHCP header, uint16 value, sub-options.) The value specified with the ``data`` parameter — which should be a valid integer enclosed -in quotes, e.g. ``"123"`` — would then be assigned to the uint16 field in -the ``"container"`` option. +in quotes, e.g. ``"123"`` — would then be assigned to the ``uint16`` field in +the ``container`` option. .. _dhcp4-option-data-defaults: @@ -2667,17 +2652,17 @@ specified: must be specified. - ``code`` - the server requires either an option name or an option code to - identify an option. This parameter may be left unspecified if the + identify an option; this parameter may be left unspecified if the ``name`` parameter is specified. However, this also requires that the - particular option has a definition (either as a standard option or + particular option have a definition (either as a standard option or an administrator-created definition for the option using an - ``'option-def'`` structure), as the option definition associates an + ``option-def`` structure), as the option definition associates an option with a particular name. It is possible to configure an option for which there is no definition (unspecified option format). Configuration of such options requires the use of the option code. - ``space`` - if the option space is unspecified it defaults to - ``'dhcp4'``, which is an option space holding standard DHCPv4 options. + ``dhcp4``, which is an option space holding standard DHCPv4 options. - ``data`` - if the option data is unspecified it defaults to an empty value. The empty value is mostly used for the options which have no @@ -2690,6 +2675,74 @@ specified: assumes that the option data is specified as a list of comma-separated values to be assigned to individual fields of the DHCP option. +.. _dhcp4-support-for-long-options: + +Support for Long Options +------------------------ + +The kea-dhcp4 server partially supports long options (RFC3396). +Since Kea 2.1.6, the server accepts configuring long options and suboptions +(longer than 255 bytes). The options and suboptions are stored internally +in their unwrapped form and they can be processed as usual using the parser +language. On send, the server splits long options and suboptions into multiple +options and suboptions, using the respective option code. + +:: + + "option-def": [ + { + "array": false, + "code\": 240, + "encapsulate": "", + "name": "my-option", + "space": "dhcp4", + "type": "string" + } + ], + "subnet4": [ + { + "subnet": "192.0.2.0/24", + "reservations": [ + { + "hw-address": "aa:bb:cc:dd:ee:ff", + "option-data": [ + { + "always-send": false, + "code": 240, + "name": "my-option", + "csv-format": true, + "data": "data + -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 + -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 + -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 + -data", + "space": "dhcp4" + } + ] + } + ] + } + ] + +.. note:: + + For this example, the data has been split on several lines, but Kea does not + support this in the configuration file. + +This example illustrates configuring a custom long option in a reservation. +The server, when sending a response, will split this option into several options +with the same code (11 options with option code 240). + +.. note:: + + Currently the server does not support storing long options in the databases, + either host reservations or configuration backend. + +The server is also able to receive packets with split options (options using +the same option code) and to fuse the data chunks into one option. This is +also supported for suboptions if each suboption data chunk also contains the +suboption code and suboption length. + .. _dhcp4-stateless-configuration: Stateless Configuration of DHCPv4 Clients @@ -2703,7 +2756,7 @@ obtain the stateless configuration param DHCPINFORM message to the server with the ``ciaddr`` set to the address that the client is currently using. The server unicasts the DHCPACK message to the client that includes the stateless configuration -(`"yiaddr"` not set). +("yiaddr" not set). The server responds to the DHCPINFORM when the client is associated with a subnet defined in the server's configuration. An example subnet @@ -2770,7 +2823,7 @@ devices share the same link and are expe different subnets. The primary use case for such a scenario is cable networks, where there are two classes of devices: the cable modem itself, which should be handed a lease from subnet A; and all other -devices behind the modem, which should get a lease from subnet B. That +devices behind the modem, which should get leases from subnet B. That segregation is essential to prevent overly curious end-users from playing with their cable modems. For details on how to set up class restrictions on subnets, see :ref:`classification-subnets`. @@ -2778,7 +2831,7 @@ on subnets, see :ref:`classification-sub When subnets belong to a shared network, the classification applies to subnet selection but not to pools; that is, a pool in a subnet limited to a particular class can still be used by clients which do not belong to the -class, if the pool they are expected to use is exhausted. So the limit +class, if the pool they are expected to use is exhausted. The limit on access based on class information is also available at the pool level within a subnet: see :ref:`classification-pools`. This is useful when segregating clients belonging to the same subnet into @@ -2787,7 +2840,7 @@ different address ranges. In a similar way, a pool can be constrained to serve only known clients, i.e. clients which have a reservation, using the built-in ``KNOWN`` or ``UNKNOWN`` classes. Addresses can be assigned to registered clients -without giving a different address per reservation, for instance when +without giving a different address per reservation: for instance, when there are not enough available addresses. The determination whether there is a reservation for a given client is made after a subnet is selected, so it is not possible to use ``KNOWN``/``UNKNOWN`` classes to select a @@ -2802,7 +2855,7 @@ The next step is to evaluate class expre the built-in ``KNOWN``/``UNKNOWN`` classes after host reservation lookup, using them for pool selection and assigning classes from host reservations. The list of required classes is then built and each class -of the list has its expression evaluated; when it returns ``true`` the +of the list has its expression evaluated; when it returns ``true``, the packet is added as a member of the class. The last step is to assign options, again possibly based on the class information. More complete and detailed information is available in :ref:`classify`. @@ -2811,12 +2864,23 @@ There are two main methods of classifica relies on examining the values in the vendor class options or the existence of a host reservation. Information from these options is extracted, and a class name is constructed from it and added to the -class list for the packet. The second specifies an expression that is +class list for the packet. The second method specifies an expression that is evaluated for each packet. If the result is ``true``, the packet is a member of the class. .. note:: + The new ``early-global-reservations-lookup`` global parameter flag + enables a lookup for global reservations before the subnet selection + phase. This lookup is similar to the general lookup described above + with two differences: + + - the lookup is limited to global host reservations + + - the ``UNKNOWN`` class is never set + +.. note:: + Care should be taken with client classification, as it is easy for clients that do not meet class criteria to be denied all service. @@ -2870,19 +2934,19 @@ Using Vendor Class Information in Classi The server checks whether an incoming packet includes the vendor class identifier option (60). If it does, the content of that option is -prepended with ``VENDOR_CLASS\_``, and it is interpreted as a class. For +prepended with ``VENDOR_CLASS_``, and it is interpreted as a class. For example, modern cable modems send this option with value ``docsis3.0``, so the packet belongs to the class ``VENDOR_CLASS_docsis3.0``. .. note:: - Certain special actions for clients in `VENDOR_CLASS_docsis3.0` can be - achieved by defining `VENDOR_CLASS_docsis3.0` and setting its + Certain special actions for clients in ``VENDOR_CLASS_docsis3.0`` can be + achieved by defining ``VENDOR_CLASS_docsis3.0`` and setting its ``next-server`` and ``boot-file-name`` values appropriately. This example shows a configuration using an automatically generated -``VENDOR_CLASS\_`` class. The administrator of the network has decided that +``VENDOR_CLASS_`` class. The administrator of the network has decided that addresses from the range 192.0.2.10 to 192.0.2.20 are going to be managed by the Dhcp4 server and only clients belonging to the DOCSIS 3.0 client class are allowed to use that pool. @@ -3005,7 +3069,7 @@ DDNS for DHCPv4 As mentioned earlier, ``kea-dhcp4`` can be configured to generate requests to the DHCP-DDNS server, ``kea-dhcp-ddns``, (referred to herein as "D2") to -update DNS entries. These requests are known as Name Change Requests or +update DNS entries. These requests are known as NameChangeRequests or NCRs. Each NCR contains the following information: 1. Whether it is a request to add (update) or remove DNS entries. @@ -3016,9 +3080,7 @@ NCRs. Each NCR contains the following in 3. The Fully Qualified Domain Name (FQDN), lease address, and DHCID (information identifying the client associated with the FQDN). -Prior to Kea 1.7.1, all parameters for controlling DDNS were within the -global ``dhcp-ddns`` section of ``kea-dhcp4``. Beginning with Kea 1.7.1, -DDNS-related parameters were split into two groups: +DDNS-related parameters are split into two groups: 1. Connectivity Parameters @@ -3060,8 +3122,8 @@ DDNS-related parameters were split into .. note:: For backward compatibility, configuration parsing still recognizes - the original behavioral parameters specified in ``dhcp-ddns``. It - does so by translating the parameter into its global equivalent. If a + the original behavioral parameters specified in ``dhcp-ddns``, + by translating the parameter into its global equivalent. If a parameter is specified both globally and in ``dhcp-ddns``, the latter value is ignored. In either case, a log is emitted explaining what has occurred. Specifying these values within ``dhcp-ddns`` is @@ -3098,7 +3160,7 @@ The default configuration and values wou ... } -As of Kea 1.7.1, there are two parameters which determine if ``kea-dhcp4`` +There are two parameters which determine if ``kea-dhcp4`` can generate DDNS requests to D2: the existing ``dhcp-ddns:enable-updates`` parameter, which now only controls whether ``kea-dhcp4`` connects to D2; and the new behavioral parameter, ``ddns-send-updates``, which determines @@ -3106,52 +3168,52 @@ whether DDNS updates are enabled at a gi or subnet). The following table shows how the two parameters function together: -.. table:: Enabling and Disabling DDNS Updates +.. table:: Enabling and disabling DDNS updates - +-----------------+--------------------+-------------------------------+ - | dhcp-ddns: | Global | Outcome | - | enable-updates | ddns-send-updates | | - +=================+====================+===============================+ - | false (default) | false | no updates at any scope | - +-----------------+--------------------+-------------------------------+ - | false | true (default) | no updates at any scope | - +-----------------+--------------------+-------------------------------+ - | true | false | updates only at scopes with | - | | | a local value of true for | - | | | ddns-enable-updates | - +-----------------+--------------------+-------------------------------+ - | true | true | updates at all scopes except | - | | | those with a local value of | - | | | false for ddns-enable-updates | - +-----------------+--------------------+-------------------------------+ + +-----------------+--------------------+-------------------------------------+ + | dhcp-ddns: | Global | Outcome | + | enable-updates | ddns-send-updates | | + +=================+====================+=====================================+ + | false (default) | false | no updates at any scope | + +-----------------+--------------------+-------------------------------------+ + | false | true (default) | no updates at any scope | + +-----------------+--------------------+-------------------------------------+ + | true | false | updates only at scopes with | + | | | a local value of ``true`` for | + | | | ``ddns-enable-updates`` | + +-----------------+--------------------+-------------------------------------+ + | true | true | updates at all scopes except those | + | | | with a local value of ``false`` | + | | | for ``ddns-enable-updates`` | + +-----------------+--------------------+-------------------------------------+ Kea 1.9.1 added two new parameters; the first is ``ddns-update-on-renew``. -Normally, when leases are renewed the server only updates DNS if the DNS +Normally, when leases are renewed, the server only updates DNS if the DNS information for the lease (e.g. FQDN, DNS update direction flags) has changed. -Setting ``ddns-update-on-renew`` to `true` instructs the server to always update +Setting ``ddns-update-on-renew`` to ``true`` instructs the server to always update the DNS information when a lease is renewed, even if its DNS information has not changed. This allows Kea to "self-heal" if it was previously unable to add DNS entries or they were somehow lost by the DNS server. .. note:: - Setting ``ddns-update-on-renew`` to `true` may impact performance, especially + Setting ``ddns-update-on-renew`` to ``true`` may impact performance, especially for servers with numerous clients that renew often. The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. The value of this parameter is passed by ``kea-dhcp4`` to D2 with each DNS update -request. When `true`, (the default value), D2 employs conflict resolution, +request. When ``true`` (the default value), D2 employs conflict resolution, as described in `RFC 4703 `__, when -attempting to fulfill the update request. When false, D2 simply attempts +attempting to fulfill the update request. When ``false``, D2 simply attempts to update the DNS entries per the request, regardless of whether they -conflict with existing entries owned by other DHCP4 clients. +conflict with existing entries owned by other DHCPv4 clients. .. note:: - Setting ``ddns-use-conflict-resolution`` to `false` disables the overwrite - safeguards that the rules of conflict resolution ( + Setting ``ddns-use-conflict-resolution`` to ``false`` disables the overwrite + safeguards that the rules of conflict resolution (from `RFC 4703 `__) are intended to - prevent. This means that existing entries for a FQDN or an + prevent. This means that existing entries for an FQDN or an IP address made for Client-A can be deleted or replaced by entries for Client-B. Furthermore, there are two scenarios by which entries for multiple clients for the same key (e.g. FQDN or IP) can be created. @@ -3165,10 +3227,10 @@ conflict with existing entries owned by 2. Client-B uses the same IP address as Client-A but a different FQDN. In this case the reverse DNS entries (PTR and DHCID RRs) for Client-A - will be deleted as they match the IP address and new entries for + will be deleted as they match the IP address, and new entries for Client-B will be added. The forward DNS entries (A and DHCID RRs) for Client-A, however, will not be deleted, as they belong to a different - FQDN while new entries for Client-B will still be added. + FQDN, while new entries for Client-B will still be added. Disabling conflict resolution should be done only after careful review of specific use cases. The best way to avoid unwanted DNS entries is to @@ -3179,8 +3241,8 @@ conflict with existing entries owned by .. note:: - The DNS entries Kea creates contain a value for TTL (time to live). As of - Kea 1.9.3, kea-dhcp4 calculates that value based on + The DNS entries Kea creates contain a value for TTL (time to live). Since + Kea 1.9.3, ``kea-dhcp4`` calculates that value based on `RFC 4702, Section 5 `__, which suggests that the TTL value be 1/3 of the lease's lifetime, with a minimum value of 10 minutes. In earlier versions, the server set the TTL value @@ -3195,10 +3257,10 @@ For NCRs to reach the D2 server, ``kea-d with it. ``kea-dhcp4`` uses the following configuration parameters to control this communication: -- ``enable-updates`` - As of Kea 1.7.1, this parameter only enables - connectivity to ``kea-dhcp-ddns`` such that DDNS updates can be constructed - and sent. It must be `true` for NCRs to be generated and sent to D2. - It defaults to `false`. +- ``enable-updates`` - Enables connectivity to ``kea-dhcp-ddns`` such that DDNS + updates can be constructed and sent. + It must be ``true`` for NCRs to be generated and sent to D2. + It defaults to ``false``. - ``server-ip`` - This is the IP address on which D2 listens for requests. The default is the local loopback interface at address 127.0.0.1. @@ -3215,10 +3277,10 @@ control this communication: The default value of 0 instructs ``kea-dhcp4`` to select a suitable port. - ``max-queue-size`` - This is the maximum number of requests allowed to queue - waiting to be sent to D2. This value guards against requests + while waiting to be sent to D2. This value guards against requests accumulating uncontrollably if they are being generated faster than they can be delivered. If the number of requests queued for - transmission reaches this value, DDNS updating will be turned off + transmission reaches this value, DDNS updating is turned off until the queue backlog has been sufficiently reduced. The intent is to allow the ``kea-dhcp4`` server to continue lease operations without running the risk that its memory usage grows without limit. The @@ -3263,7 +3325,7 @@ resolution are within the purview of D2 generates NCRs and the configuration parameters that can be used to influence this decision. It assumes that both the connectivity parameter ``enable-updates`` and the behavioral parameter ``ddns-send-updates``, -are `true`. +are ``true``. In general, ``kea-dhcp4`` generates DDNS update requests when: @@ -3287,7 +3349,7 @@ server uses the FQDN option. By default, FQDN N and S flags specified by the client as shown in the following table: -.. table:: Default FQDN Flag Behavior +.. table:: Default FQDN flag behavior +------------+---------------------+-----------------+-------------+ | Client | Client Intent | Server Response | Server | @@ -3316,7 +3378,7 @@ the server should do the reverse updates honors the client's wishes and generates a DDNS request to the D2 server to update only reverse DNS data. The parameter ``ddns-override-client-update`` can be used to instruct the server to -override client delegation requests. When this parameter is `"true"`, +override client delegation requests. When this parameter is ``true``, ``kea-dhcp4`` disregards requests for client delegation and generates a DDNS request to update both forward and reverse DNS data. In this case, the N-S-O flags in the server's response to the client will be 0-1-1 @@ -3340,7 +3402,7 @@ configuration file: The third row in the table above describes the case in which the client requests that no DNS updates be done. The parameter ``ddns-override-no-update`` can be used to instruct the server to disregard -the client's wishes. When this parameter is true, ``kea-dhcp4`` +the client's wishes. When this parameter is ``true``, ``kea-dhcp4`` generates DDNS update requests to ``kea-dhcp-ddns`` even if the client requests that no updates be done. The N-S-O flags in the server's response to the client will be 0-1-1. @@ -3366,7 +3428,7 @@ is the name submitted to D2 in the DDNS ``kea-dhcp4`` Name Generation for DDNS Update Requests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Each Name Change Request must of course include the fully qualified domain +Each NameChangeRequest must of course include the fully qualified domain name whose DNS entries are to be affected. ``kea-dhcp4`` can be configured to supply a portion or all of that name, based on what it receives from the client in the DHCPREQUEST. @@ -3407,7 +3469,7 @@ parameter, which provides the following values of ``true`` and ``false``. Boolean values have been deprecated and are no longer accepted. Administrators currently using booleans must replace them with the desired mode name. A value of ``true`` - maps to ``"when-present"``, while ``false`` maps to ``"never"``. + maps to ``when-present``, while ``false`` maps to ``never``. For example, to instruct ``kea-dhcp4`` to always generate the FQDN for a client, set the parameter ``ddns-replace-client-name`` to ``always`` as @@ -3422,7 +3484,7 @@ follows: } The prefix used in the generation of an FQDN is specified by the -``generated-prefix`` parameter. The default value is `"myhost"`. To alter +``ddns-generated-prefix`` parameter. The default value is "myhost". To alter its value, simply set it to the desired string: :: @@ -3449,11 +3511,11 @@ meaningful default. When generating a name, ``kea-dhcp4`` constructs the name in the format: -``[ddns-generated-prefix]-[address-text].[ddns-qualifying-suffix]`` +``[ddns-generated-prefix]-[address-text].[ddns-qualifying-suffix].`` where ``address-text`` is simply the lease IP address converted to a hyphenated string. For example, if the lease address is 172.16.1.10, the -qualifying suffix "example.com", and the default value is used for +qualifying suffix is "example.com", and the default value is used for ``ddns-generated-prefix``, the generated FQDN is: ``myhost-172-16-1-10.example.com.`` @@ -3474,23 +3536,16 @@ and "-". This may be accomplished with t character set. This can be any valid, regular expression using POSIX extended expression syntax. Embedded nulls (0x00) are always considered an invalid character to be replaced (or omitted). + The default is ``"[^A-Za-z0-9.-]"``. This matches any character that is not + a letter, digit, dot, hyphen, or null. - ``hostname-char-replacement`` - a string of zero or more characters with which to replace each invalid character in the host name. An empty string causes invalid characters to be OMITTED rather than replaced. - -.. note:: - - Starting with Kea 1.7.5, the default values are as follows: - - - "hostname-char-set": "[^A-Za-z0-9.-]", - - "hostname-char-replacement": "" - - This enables sanitizing and omits any character that is not - a letter, digit, hyphen, dot, or null. + The default is ``""``. The following configuration replaces anything other than a letter, -digit, hyphen, or dot with the letter 'x': +digit, dot, or hyphen with the letter "x": :: "Dhcp4": { @@ -3507,7 +3562,6 @@ qualifying suffix (if one is defined and .. note:: - The following are some considerations to keep in mind: Name sanitizing is meant to catch the more common cases of invalid characters through a relatively simple character-replacement scheme. It is difficult to devise a scheme that works well in all cases, for @@ -3520,13 +3574,13 @@ qualifying suffix (if one is defined and If clients include domain names in the Host Name option and the administrator wants these preserved, they need to make sure that the dot, ".", is considered a valid character by the ``hostname-char-set`` expression, - such as this: `"[^A-Za-z0-9.-]"`. This does not affect dots in FQDN + such as this: ``"[^A-Za-z0-9.-]"``. This does not affect dots in FQDN Option values. When scrubbing FQDNs, dots are treated as delimiters and used to separate the option value into individual domain labels that are scrubbed and then re-assembled. If clients are sending values that differ only by characters - considered as invalid by the hostname-char-set, be aware that + considered as invalid by the ``hostname-char-set``, be aware that scrubbing them will yield identical values. In such cases, DDNS conflict rules will permit only one of them to register the name. @@ -3539,7 +3593,7 @@ qualifying suffix (if one is defined and .. note:: - Since the 1.6.0 Kea release, it is possible to specify ``hostname-char-set`` + It is possible to specify ``hostname-char-set`` and/or ``hostname-char-replacement`` at the global scope. This allows host names to be sanitized without requiring a ``dhcp-ddns`` entry. When a ``hostname-char`` parameter is defined at both the global scope and @@ -3556,14 +3610,14 @@ Although there is a dedicated option for can be configured using the ``next-server`` directive. It is possible to define it in the global scope or for a given subnet only. If both are defined, the subnet value takes precedence. The value in the subnet can be -set to `0.0.0.0`, which means that ``next-server`` should not be sent. It +set to "0.0.0.0", which means that ``next-server`` should not be sent. It can also be set to an empty string, which is equivalent to it not being defined at all; that is, it uses the global value. The ``server-hostname`` (which conveys a server hostname, can be up to -64 bytes long, and is in the sname field) and +64 bytes long, and is in the ``sname`` field) and ``boot-file-name`` (which conveys the configuration file, can be up to -128 bytes long, and is sent using the file field) directives are +128 bytes long, and is sent using the ``file`` field) directives are handled the same way as ``next-server``. :: @@ -3637,7 +3691,10 @@ ones are: information stored in DHCPv4 and DHCPv6 servers for a particular host. Using common identification information by the DHCPv4 and DHCPv6 clients allows the network administrator to achieve this - correlation and better administer the network. + correlation and better administer the network. Beginning with + release 2.1.2, Kea supports DHCPv6 DUIDs embedded within DHCPv4 + Client Identifier options as described in + `RFC 4361 `__. DHCPv4 uses two distinct identifiers which are placed by the client in the queries sent to the server and copied by the server to its responses @@ -3800,9 +3857,9 @@ configuration of the DHCPv4 side (the DH .. note:: DHCPv4-over-DHCPv6 support is experimental and the details of the - inter-process communication may change; both the DHCPv4 and DHCPv6 - sides should be running the same version of Kea. For instance, the + inter-process communication may change; for instance, the support of port relay (RFC 8357) introduced an incompatible change. + Both the DHCPv4 and DHCPv6 sides should be running the same version of Kea. The ``dhcp4o6-port`` global parameter specifies the first of the two consecutive ports of the UDP sockets used for the communication between @@ -3824,7 +3881,7 @@ DHCPv4-over-DHCPv6. These entries are: - ``4o6-interface``: takes an interface name which is matched against the incoming interface name. -The following configuration was used during some tests: +ISC tested the following configuration: :: @@ -3871,12 +3928,12 @@ Sanity Checks in DHCPv4 ----------------------- An important aspect of a well-running DHCP system is an assurance that -the data remain consistent. However, in some cases it may be convenient +the data remains consistent; however, in some cases it may be convenient to tolerate certain inconsistent data. For example, a network -administrator that temporarily removes a subnet from a configuration +administrator who temporarily removes a subnet from a configuration would not want all the leases associated with it to disappear from the -lease database. Kea has a mechanism to control sanity checks such -as this. +lease database. Kea has a mechanism to implement sanity checks for situations +like this. Kea supports a configuration scope called ``sanity-checks``. It currently allows only a single parameter, called ``lease-checks``, which @@ -3885,8 +3942,8 @@ lease file. This mechanism permits Kea t Every subnet has a ``subnet-id`` value; this is how Kea internally identifies subnets. Each lease has a ``subnet-id`` parameter as well, which -identifies which subnet it belongs to. However, if the configuration has -changed, it is possible that a lease could exist with a ``subnet-id``, but +identifies the subnet it belongs to. However, if the configuration has +changed, it is possible that a lease could exist with a ``subnet-id`` but without any subnet that matches it. Also, it is possible that the subnet's configuration has changed and the ``subnet-id`` now belongs to a subnet that does not match the lease. @@ -3938,14 +3995,10 @@ Storing Extended Lease Information ---------------------------------- To support such features as DHCP Leasequery -(`RFC 4388 `__) -additional information must be stored with each lease. Kea does not -currently offer a Leasequery hook library, but other hook libraries -may already be using ``user-context``. - -Because the amount +(`RFC 4388 `__), +additional information must be stored with each lease. Because the amount of information for each lease has ramifications in terms of -performance and system resource consumption, storing this additional +performance and system resource consumption, storage of this additional information is configurable through the ``store-extended-info`` parameter. It defaults to ``false`` and may be set at the global, shared-network, and subnet levels. @@ -3958,23 +4011,24 @@ subnet levels. } When set to ``true``, information relevant to the DHCPREQUEST asking for the lease is -added into the lease's user-context as a map element labeled `"ISC"`. Currently, +added into the lease's user-context as a map element labeled "ISC". Currently, the map contains a single value, the ``relay-agent-info`` option (DHCP Option 82), when the DHCPREQUEST received contains it. Since DHCPREQUESTs sent as renewals will likely not contain this -information, the values taken from the last DHCPREQUEST that did contain it will -be retained on the lease. The lease's user-context will look something like this: +information, the values taken from the last DHCPREQUEST that did contain it are +retained on the lease. The lease's user-context looks something like this: :: { "ISC": { "relay-agent-info": "0x52050104AABBCCDD" } } .. note:: - As mentioned above, it is possible that other hook libraries are already using ``user-context``. + + It is possible that other hook libraries are already using ``user-context``. Enabling ``store-extended-info`` should not interfere with any other ``user-context`` - content, as long as it does not also use an element labeled `"ISC"`. In other + content, as long as it does not also use an element labeled "ISC". In other words, ``user-context`` is intended to be a flexible container serving multiple - purposes. As long as no other purpose also writes an `"ISC"` element to - user-context there should not be a conflict. + purposes. As long as no other purpose also writes an "ISC" element to + ``user-context`` there should not be a conflict. .. _dhcp4-multi-threading-settings: @@ -3986,7 +4040,7 @@ threads. These settings can be found und represented by: - ``enable-multi-threading`` - use multiple threads to process packets in - parallel (default false). + parallel. The default is ``false``. - ``thread-pool-size`` - specify the number of threads to process packets in parallel. It may be set to 0 (auto-detect), or any positive number explicitly sets @@ -4009,15 +4063,15 @@ An example configuration that sets these ... } -Multi-Threading Settings in Different Backends ----------------------------------------------- +Multi-Threading Settings With Different Database Backends +--------------------------------------------------------- -Both ``kea-dhcp4`` and ``kea-dhcp6`` are tested internally to determine which settings -give the best performance. Although this section describes our results, they are just -recommendations and are very dependent on the particular hardware that was used +Both ``kea-dhcp4`` and ``kea-dhcp6`` are tested by ISC to determine which settings +give the best performance. Although this section describes our results, they are merely +recommendations and are very dependent on the particular hardware used for testing. We strongly advise that administrators run their own performance tests. -A full report of performance results for the latest stable Kea can be found +A full report of performance results for the latest stable Kea version can be found `here `_. This includes hardware and test scenario descriptions, as well as current results. @@ -4033,7 +4087,7 @@ parameter. Results from our tests show t - ``thread-pool-size``: 8 when using ``postgresql``. Another very important parameter is ``packet-queue-size``; in our tests we -used it as a multiplier of ``thread-pool-size``. So the actual setting strongly depends +used it as a multiplier of ``thread-pool-size``. The actual setting strongly depends on ``thread-pool-size``. We saw the best results in our tests with the following settings: @@ -4100,8 +4154,8 @@ does not require disk operations. The two parameters are the ``cache-threshold`` double and the ``cache-max-age`` integer; they have no default setting, i.e. the lease caching feature must be explicitly enabled. These parameters can be configured -at the global, shared network, and subnet levels. The subnet level has -precedence over the shared network level, while the global level is used +at the global, shared-network, and subnet levels. The subnet level has +precedence over the shared-network level, while the global level is used as a last resort. For example: :: @@ -4117,7 +4171,7 @@ as a last resort. For example: } ], -When an already assigned lease can fulfill a client query: +When an already-assigned lease can fulfill a client query: - any important change, e.g. for DDNS parameter, hostname, or valid lifetime reduction, makes the lease not reusable. @@ -4136,7 +4190,7 @@ When an already assigned lease can fulfi In our example, a lease with a valid lifetime of 2000 seconds can be reused if it was committed less than 500 seconds ago. With a lifetime -of 3000 seconds, the maximum age of 600 seconds applies. +of 3000 seconds, a maximum age of 600 seconds applies. In outbound client responses (e.g. DHCPACK messages), the ``dhcp-lease-time`` option is set to the reusable valid lifetime, @@ -4146,15 +4200,15 @@ also depend on the reusable lifetime. .. _host-reservation-v4: -Host Reservation in DHCPv4 -========================== +Host Reservations in DHCPv4 +=========================== There are many cases where it is useful to provide a configuration on a per-host basis. The most obvious one is to reserve a specific, static address for exclusive use by a given client (host); the returning client receives the same address from the server every time, and other -clients generally do not receive that address. Another situation when -host reservations are applicable is when a host has +clients generally do not receive that address. Host +reservations are also convenient when a host has specific requirements, e.g. a printer that needs additional DHCP options. Yet another possible use case is to define unique names for hosts. @@ -4162,8 +4216,8 @@ hosts. There may be cases when a new reservation has been made for a client for an address currently in use by another client. We call this situation a "conflict." -These conflicts get resolved automatically over time as described in -subsequent sections. Once the conflict is resolved, the correct client will +These conflicts get resolved automatically over time, as described in +subsequent sections. Once a conflict is resolved, the correct client will receive the reserved configuration when it renews. Host reservations are defined as parameters for each subnet. Each host @@ -4171,7 +4225,7 @@ must have its own unique identifier, suc address. There is an optional ``reservations`` array in the ``subnet4`` structure; each element in that array is a structure that holds information about reservations for a single host. In particular, the -structure must have a unique host identifier. In +structure has an identifier that uniquely identifies a host. In the DHCPv4 context, the identifier is usually a hardware or MAC address. In most cases an IP address will be specified. It is also possible to specify a hostname, host-specific options, or fields carried within the @@ -4179,8 +4233,7 @@ DHCPv4 message such as ``siaddr``, ``sna .. note:: - Kea versions 1.7.10 and newer require that the reserved address must - be within the subnet. + The reserved address must be within the subnet. The following example shows how to reserve addresses for specific hosts in a subnet: @@ -4216,12 +4269,12 @@ in a subnet: The first entry reserves the 192.0.2.202 address for the client that uses a MAC address of 1a:1b:1c:1d:1e:1f. The second entry reserves the -address 192.0.2.100 and the hostname of `alice-laptop` for the client +address 192.0.2.100 and the hostname of "alice-laptop" for the client using a DUID 0a:0b:0c:0d:0e:0f. (If DNS updates are planned, it is strongly recommended that the hostnames be unique.) The third example reserves address 192.0.3.203 for a client whose request would be relayed by a relay agent that inserts a ``circuit-id`` option with -the value `"charter950"`. The fourth entry reserves address 192.0.2.204 +the value "charter950". The fourth entry reserves address 192.0.2.204 for a client that uses a client identifier with value 01:11:22:33:44:55:66. @@ -4250,7 +4303,7 @@ reservation for it). That additional che Address Reservation Types ------------------------- -In a typical scenario there is an IPv4 subnet defined, e.g. +In a typical Kea scenario there is an IPv4 subnet defined, e.g. 192.0.2.0/24, with a certain part of it dedicated for dynamic allocation by the DHCPv4 server. That dynamic part is referred to as a dynamic pool or simply a pool. In principle, a host reservation can reserve any @@ -4262,9 +4315,9 @@ the reservation syntax and both reservat Kea supports global host reservations. These are reservations that are specified at the global level within the configuration and that do not -belong to any specific subnet. Kea will still match inbound client +belong to any specific subnet. Kea still matches inbound client packets to a subnet as before, but when the subnet's reservation mode is -set to ``"global"``, Kea looks for host reservations only among the +set to "global", Kea looks for host reservations only among the global reservations defined. Typically, such reservations would be used to reserve hostnames for clients which may move from one subnet to another. @@ -4278,8 +4331,8 @@ another. .. note:: Since Kea 1.9.1, reservation mode has been replaced by three - boolean flags, ``"reservations-global"``, ``"reservations-in-subnet"``, - and ``"reservations-out-of-pool"``, which allow the configuration of + boolean flags, ``reservations-global``, ``reservations-in-subnet``, + and ``reservations-out-of-pool``, which allow the configuration of host reservations both globally and in a subnet. In such cases a subnet host reservation has preference over a global reservation when both exist for the same client. @@ -4299,7 +4352,7 @@ else is not recommended, but there are v operation is warranted. The server now has a conflict to resolve. If Host B boots up and -requests an address, the server is not able to assign the reserved +requests an address, the server cannot immediately assign the reserved address 192.0.2.10. A naive approach would to be immediately remove the existing lease for Host A and create a new one for Host B. That would not solve the problem, though, because as soon as Host B gets the @@ -4343,7 +4396,7 @@ where reservations conflict with existin takes roughly as long as the value set for ``renew-timer``. The best way to avoid such a recovery is not to define new reservations that conflict with existing leases. Another recommendation is to use -out-of-pool reservations. If the reserved address does not belong to a +out-of-pool reservations; if the reserved address does not belong to a pool, there is no way that other clients can get it. .. note:: @@ -4395,7 +4448,7 @@ configuration: } } -will result in assigning the `"alice-laptop.example.isc.org."` hostname to +will result in the "alice-laptop.example.isc.org." hostname being assigned to the client using the MAC address "aa:bb:cc:dd:ee:ff". If the ``ddns-qualifying-suffix`` is not specified, the default (empty) value will be used, and in this case the value specified as a ``hostname`` will be @@ -4426,6 +4479,11 @@ different clients with different domain } } +The above example results in the assignment of the +"alice-laptop.isc.org." hostname to the client using the MAC +address "aa:bb:cc:dd:ee:ff", and the hostname "mark-desktop.example.org." +to the client using the MAC address "12:34:56:78:99:AA". + .. _reservation4-options: Including Specific DHCPv4 Options in Reservations @@ -4492,10 +4550,10 @@ class, and host levels, the host-specifi Reserving Next Server, Server Hostname, and Boot File Name ---------------------------------------------------------- -BOOTP/DHCPv4 messages include `"siaddr"`, `"sname"`, and `"file"` fields. Even +BOOTP/DHCPv4 messages include "siaddr", "sname", and "file" fields. Even though DHCPv4 includes corresponding options, such as option 66 and option 67, some clients may not support these options. For this reason, -server administrators often use the `"siaddr"`, `"sname"`, and `"file"` fields +server administrators often use the "siaddr", "sname", and "file" fields instead. With Kea, it is possible to make static reservations for these DHCPv4 @@ -4529,7 +4587,7 @@ Reserving Client Classes in DHCPv4 the server to assign classes to a client, based on the content of the options that this client sends to the server. Host reservation mechanisms also allow for the static assignment of classes to clients. -The definitions of these classes are placed in the Kea configuration or +The definitions of these classes are placed in the Kea configuration file or a database. The following configuration snippet shows how to specify that a client belongs to the classes ``reserved-class1`` and ``reserved-class2``. Those classes are associated with specific options sent to the clients which belong @@ -4574,11 +4632,11 @@ to them. In some cases the host reservations can be used in conjunction with client classes specified within the Kea configuration. In particular, when a -host reservation exists for a client within a given subnet, the `"KNOWN"` +host reservation exists for a client within a given subnet, the "KNOWN" built-in class is assigned to the client. Conversely, when there is no -static assignment for the client, the `"UNKNOWN"` class is assigned to the +static assignment for the client, the "UNKNOWN" class is assigned to the client. Class expressions within the Kea configuration file can -refer to `"KNOWN"` or `"UNKNOWN"` classes using the `"member"` operator. +refer to "KNOWN" or "UNKNOWN" classes using the "member" operator. For example: :: @@ -4593,17 +4651,18 @@ For example: ] } -Note that the ``only-if-required`` parameter is needed here to force +The ``only-if-required`` parameter is needed here to force evaluation of the class after the lease has been allocated and thus the reserved class has been also assigned. .. note:: + The classes specified in non-global host reservations are assigned to the processed packet after all classes with the ``only-if-required`` parameter set to ``false`` have been evaluated. This means that these classes must not depend on the - statically assigned classes from the host reservations. If there - is a need to create such a dependency, the ``only-if-required`` parameter must + statically assigned classes from the host reservations. If + such a dependency is needed, the ``only-if-required`` parameter must be set to ``true`` for the dependent classes. Such classes are evaluated after the static classes have been assigned to the packet. This, however, imposes additional configuration overhead, because @@ -4611,23 +4670,24 @@ reserved class has been also assigned. ``require-client-classes`` list for every subnet where they are used. .. note:: + Client classes specified within the Kea configuration file may depend on the classes specified within the global host reservations. In such a case the ``only-if-required`` parameter is not needed. Refer to :ref:`pool-selection-with-class-reservations4` and :ref:`subnet-selection-with-class-reservations4` - for the specific use cases. + for specific use cases. -.. _reservations4-mysql-pgsql-cql: +.. _reservations4-mysql-pgsql: -Storing Host Reservations in MySQL, PostgreSQL, or Cassandra ------------------------------------------------------------- +Storing Host Reservations in MySQL or PostgreSQL +------------------------------------------------ -Kea can store host reservations in MySQL, PostgreSQL, or -Cassandra. See :ref:`hosts4-storage` for information on how to -configure Kea to use reservations stored in MySQL, PostgreSQL, or -Cassandra. Kea provides a dedicated hook for managing reservations in a -database; section :ref:`host-cmds` provides detailed information. +Kea can store host reservations in MySQL or PostgreSQL. +See :ref:`hosts4-storage` for information on how to +configure Kea to use reservations stored in MySQL or PostgreSQL. +Kea provides a dedicated hook for managing reservations in a +database; section :ref:`hooks-host-cmds` provides detailed information. The `Kea wiki `__ provides some examples of how to conduct common host reservation @@ -4635,7 +4695,7 @@ operations. .. note:: - In Kea, the maximum length of an option specified per-host is + In Kea, the maximum length of an option specified per-host-reservation is arbitrarily set to 4096 bytes. .. _reservations4-tuning: @@ -4648,7 +4708,7 @@ the allocation engine (the component of a client) during lease selection and renewal. In particular, three major checks are necessary. First, when selecting a new lease, it is not sufficient for a candidate lease to simply not be in use by another DHCP -client; it also must not be reserved for another client. Second, when +client; it also must not be reserved for another client. Similarly, when renewing a lease, an additional check must be performed to see whether the address being renewed is reserved for another client. Finally, when a host renews an address, the server must check whether there is a @@ -4660,7 +4720,8 @@ performing them may improve performance. ``reservation-mode`` configuration parameter to select the types of reservations allowed for a particular subnet. Each reservation type has different constraints for the checks to be performed by the server when -allocating or renewing a lease for the client. Allowed values are: +allocating or renewing a lease for the client. Although ``reservation-mode`` +was deprecated in Kea 1.9.1, it is still available; the allowed values are: - ``all`` - enables both in-pool and out-of-pool host reservation types. This setting is the default value, and is the safest and most @@ -4668,7 +4729,7 @@ allocating or renewing a lease for the c It does not check against global reservations. - ``out-of-pool`` - allows only out-of-pool host reservations. With - this setting in place, the server may assume that all host + this setting in place, the server assumes that all host reservations are for addresses that do not belong to the dynamic pool. Therefore, it can skip the reservation checks when dealing with in-pool addresses, thus improving performance. Do not use this mode @@ -4679,7 +4740,7 @@ allocating or renewing a lease for the c - ``global`` - allows only global host reservations. With this setting in place, the server searches for reservations for a client only among the defined global reservations. If an address is specified, - the server skips the reservation checks carried out when dealing in + the server skips the reservation checks carried out in other modes, thus improving performance. Caution is advised when using this setting; Kea does not sanity-check reservations when ``global`` is set, and misconfiguration may cause problems. @@ -4709,7 +4770,7 @@ The ``reservation-mode`` parameter can b ``.Dhcp4["shared-networks"][].subnet4[]["reservation-mode"]`` (highest priority: overrides all others) -To decide which ``"reservation-mode"`` to choose, the +To decide which ``reservation-mode`` to choose, the following decision diagram may be useful: :: @@ -4823,7 +4884,7 @@ The meaning of the reservation flags are - ``reservations-out-of-pool``: this makes sense only when the ``reservations-in-subnet`` flag is ``true``. When ``reservations-out-of-pool`` - is ``true``, the server may assume that all host reservations are for addresses + is ``true``, the server assumes that all host reservations are for addresses that do not belong to the dynamic pool. Therefore, it can skip the reservation checks when dealing with in-pool addresses, thus improving performance. The server will not assign reserved addresses that are inside the dynamic @@ -4902,9 +4963,9 @@ be used: } } -Note that enabling ``out-of-pool`` and disabling ``in-subnet`` at the same time +Enabling ``out-of-pool`` and disabling ``in-subnet`` at the same time is not recommended because ``out-of-pool`` applies to host reservations in a -subnet, which are fetched only when the ``in-subnet`` flag is true. +subnet, which are fetched only when the ``in-subnet`` flag is ``true``. The parameter can be specified at the global, subnet, and shared-network levels. @@ -5015,7 +5076,7 @@ addresses. However, global reservations whole topology determination provided by the DHCP logic implemented in Kea. It is very easy to misuse this feature and get a configuration that is inconsistent. To give a specific example, imagine a global reservation -for address 192.0.2.100 and two subnets 192.0.2.0/24 and 192.0.5.0/24. +for the address 192.0.2.100 and two subnets 192.0.2.0/24 and 192.0.5.0/24. If global reservations are used in both subnets and a device matching global host reservations visits part of the network that is serviced by 192.0.5.0/24, it will get an IP address 192.0.2.100, a subnet 192.0.5.0, @@ -5081,7 +5142,7 @@ following can be used: When using database backends, the global host reservations are distinguished from regular reservations by using a ``subnet-id`` value of -zero. +0. .. _pool-selection-with-class-reservations4: @@ -5141,8 +5202,8 @@ within the subnet as follows: The ``reserved_class`` is declared without the ``test`` parameter because it may only be assigned to the client via the host reservation mechanism. The -second class, ``unreserved_class``, is assigned to the clients which do not -belong to the ``reserved_class``. The first pool within the subnet is only +second class, ``unreserved_class``, is assigned to clients which do not +belong to the ``reserved_class``. The first pool within the subnet is only used for clients having a reservation for the ``reserved_class``. The second pool is used for clients not having such a reservation. The configuration snippet includes one host reservation which causes the client @@ -5236,7 +5297,7 @@ reservations for the same IP address wit having two different clients compete for the same address. When using the default settings, the server returns a configuration error when it finds two or more reservations for the same IP address within -a subnet in the Kea configuration file. The :ref:`host-cmds` hook +a subnet in the Kea configuration file. The :ref:`hooks-host-cmds` hook library returns an error in response to the ``reservation-add`` command when it detects that the reservation exists in the database for the IP address for which the new reservation is being added. @@ -5253,18 +5314,18 @@ interface for communication with the ser is in use. This causes a need to create multiple host reservations for a single -IP address within a subnet; this is supported beginning with the Kea 1.9.1 +IP address within a subnet; this is supported since the Kea 1.9.1 release as an optional mode of operation, enabled with the ``ip-reservations-unique`` global parameter. -``ip-reservations-unique`` is a boolean parameter that defaults to +The ``ip-reservations-unique`` is a boolean parameter that defaults to ``true``, which forbids the specification of more than one reservation for the same IP address within a given subnet. Setting this parameter to ``false`` allows such reservations to be created both in the Kea configuration file and in the host database backend, via the ``host-cmds`` hook library. This setting is currently supported by the most popular host database -backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra, +backends, i.e. MySQL and PostgreSQL. Host Cache (see :ref:`hooks-host-cache`), or the RADIUS backend (see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique`` to ``false`` when any of these three backends is in use yields a @@ -5303,7 +5364,7 @@ the same IP address but different MAC ad It is possible to control the ``ip-reservations-unique`` parameter via the :ref:`dhcp4-cb`. If the new setting of this parameter conflicts with -the currently used backends (backends do not support the new setting), +the currently used backends (i.e. backends do not support the new setting), the new setting is ignored and a warning log message is generated. The backends continue to use the default setting, expecting that IP reservations are unique within each subnet. To allow the @@ -5312,7 +5373,7 @@ the backends which lack support for them Administrators must be careful when they have been using multiple reservations for the same IP address and later decide to return to -the default mode in which this is no longer allowed. Admins +the default mode in which this is no longer allowed. They must make sure that at most one reservation for a given IP address exists within a subnet, prior to switching back to the default mode. If such duplicates are left in the configuration file, the server @@ -5323,13 +5384,19 @@ finds multiple reservations for the same .. note:: - Currently the server does not verify whether multiple reservations for - the same IP address exist in MySQL and/or - PostgreSQL host databases when ``ip-reservations-unique`` is updated from - ``true`` to ``false``. This may cause issues with lease allocations. - The administrator must ensure that there is at most one reservation - for each IP address within each subnet, prior to the configuration - update. + Currently the Kea server does not verify whether multiple reservations for + the same IP address exist in MySQL and/or PostgreSQL host databases when + ``ip-reservations-unique`` is updated from ``true`` to ``false``. This may + cause issues with lease allocations. The administrator must ensure that there + is at most one reservation for each IP address within each subnet, prior to + the configuration update. + +The ``reservations-lookup-first`` is a boolean parameter which controls whether +host reservations lookup should be performed before lease lookup. This parameter +has effect only when multi-threading is disabled. When multi-threading is +enabled, host reservations lookup is always performed first to avoid lease +lookup resource locking. The ``reservations-lookup-first`` defaults to ``false`` +when multi-threading is disabled. .. _shared-network4: @@ -5340,16 +5407,16 @@ DHCP servers use subnet information in t both determine the point of attachment, i.e. where the client is connected to the network, and to group information pertaining to a specific location in the network. -However, it is sometimes useful to have more than one +Sometimes it is useful to have more than one logical IP subnet deployed on the same physical link. Understanding that two or more subnets are used on the same link requires additional logic in the DHCP server. This capability is called "shared networks" in Kea, and sometimes also "shared subnets"; in Microsoft's nomenclature it is called "multinet." -There are many use cases where the feature is useful; here we +There are many cases where the shared networks feature is useful; here we explain just a handful of the most common ones. The first and by far -most common use case is an existing network that has grown and is +most common use case is an existing IPv4 network that has grown and is running out of available address space. Rather than migrating all devices to a new, larger subnet, it is easier to simply configure additional subnets on top of the existing one. Sometimes, due to address @@ -5386,7 +5453,7 @@ default. all the addresses from the first subnet in a shared network before allocating addresses from other subnets. -In order to define a shared network an additional configuration scope is +To define a shared network, an additional configuration scope is introduced: :: @@ -5445,12 +5512,12 @@ of two or more subnets. However, for tes or a network with just a single subnet is allowed. This is not a recommended practice in production networks, as the shared network logic requires additional processing and thus lowers the server's performance. -To avoid unnecessary performance degradation, the shared subnets should +To avoid unnecessary performance degradation, shared subnets should only be defined when required by the deployment. Shared networks provide the ability to specify many parameters in the shared network scope that apply to all subnets within it. If -necessary, it is possible to specify a parameter in the shared network scope and +necessary, it is possible to specify a parameter in the shared-network scope and then override its value in the subnet scope. For example: :: @@ -5504,16 +5571,16 @@ then override its value in the subnet sc ] } ] -In this example, there is a `"log-servers"` option defined that is available +In this example, there is a ``log-servers`` option defined that is available to clients in both subnets in this shared network. Also, the valid lifetime is set to 10 minutes (600s). However, the first subnet overrides some of the values (the valid lifetime is 20 minutes, there is a different IP -address for `"log-servers"`), but also adds its own option (the router address). -Assuming a client asking for router and `"log-servers"` options is assigned +address for ``log-servers``), but also adds its own option (the router address). +Assuming a client asking for router and ``log-servers`` options is assigned a lease from this subnet, it will get a lease for 20 minutes and a -`"log-servers"` and routers value of 10.0.0.254. If the same client is +``log-servers`` and routers value of 10.0.0.254. If the same client is assigned to the second subnet, it will get a 10-minute lease, a -`"log-servers"` value of 1.2.3.4, and routers set to 192.0.2.1. +``log-servers`` value of 1.2.3.4, and routers set to 192.0.2.1. Local and Relayed Traffic in Shared Networks -------------------------------------------- @@ -5525,7 +5592,7 @@ subnets in a shared network are expected link, it is a configuration error to attempt to define a shared network using subnets that are reachable over different interfaces. In other words, all subnets within the shared network must have the same value -of the `"interface"` parameter. The following configuration is an +for the ``interface`` parameter. The following configuration is an example of what **NOT** to do: :: @@ -5552,7 +5619,7 @@ example of what **NOT** to do: } ] To minimize the chance of configuration errors, it is often more convenient -to simply specify the interface name once, at the shared network level, as +to simply specify the interface name once, at the shared-network level, as shown in the example below. :: @@ -5616,7 +5683,7 @@ of what **NOT** to do: } ] -Again, it is better to specify the relay address at the shared network +Again, it is better to specify the relay address at the shared-network level; this value will be inherited by all subnets belonging to the shared network. @@ -5653,7 +5720,7 @@ host reservation in this subnet, or simp more addresses available. Therefore, it is strongly recommended to always specify subnet selectors (interface or relay address) at the shared-network level if the subnets belong to a shared network, as it is rarely useful to -specify them at the subnet level and it may lead to the configuration errors +specify them at the subnet level and may lead to the configuration errors described above. Client Classification in Shared Networks @@ -5671,7 +5738,7 @@ appropriate subnet is selected for a giv If a subnet is associated with a class, only the clients belonging to this class can use this subnet. If there are no classes specified for a subnet, any client connected to a given shared network can use this -subnet. A common mistake is to assume that a subnet including a client +subnet. A common mistake is to assume that a subnet that includes a client class is preferred over subnets without client classes. Consider the following example: @@ -5703,14 +5770,14 @@ following example: ] } -If the client belongs to the `"b-devices"` class (because it includes +If the client belongs to the "b-devices" class (because it includes option 93 with a value of 0x0002), that does not guarantee that the subnet 10.0.0.0/24 will be used (or preferred) for this client. The server can use either of the two subnets, because the subnet 192.0.2.0/26 is also allowed for this client. The client classification used in this case should be perceived as a way to restrict access to certain subnets, -rather than a way to express subnet preference. For example, if the -client does not belong to the `"b-devices"` class, it may only use the +rather than as a way to express subnet preference. For example, if the +client does not belong to the "b-devices" class, it may only use the subnet 192.0.2.0/26 and will never use the subnet 10.0.0.0/24. A typical use case for client classification is in a cable network, @@ -5755,22 +5822,22 @@ on option 93 values. } In this example each class has its own restriction. Only clients that -belong to class `"a-devices"` are able to use subnet 192.0.2.0/26 and -only clients belonging to `"b-devices"` are able to use subnet +belong to class "a-devices" are able to use subnet 192.0.2.0/26 and +only clients belonging to "b-devices" are able to use subnet 10.0.0.0/24. Care should be taken not to define too-restrictive classification rules, as clients that are unable to use any subnets will be refused service. However, this may be a desired outcome if one wishes to provide service only to clients with known properties (e.g. only VoIP phones allowed on a given link). -Note that it is possible to achieve an effect similar to the one +It is possible to achieve an effect similar to the one presented in this section without the use of shared networks. If the subnets are placed in the global subnets scope, rather than in the shared network, the server will still use classification rules to pick the right subnet for a given class of devices. The major benefit of placing subnets within the shared network is that common parameters for the logically grouped subnets can be specified once in the -shared-network scope, e.g. the `"interface"` or `"relay"` parameter. All subnets +shared-network scope, e.g. the ``interface`` or ``relay`` parameter. All subnets belonging to this shared network will inherit those parameters. Host Reservations in Shared Networks @@ -5827,7 +5894,7 @@ reservations for the same host in multip shared network. While not strictly mandatory, it is strongly recommended to use explicit -`"id"` values for subnets if database storage will be used for host +"id" values for subnets if database storage will be used for host reservations. If an ID is not specified, the values for it are auto-generated, i.e. Kea assigns increasing integer values starting from 1. Thus, the auto-generated IDs are not stable across configuration @@ -5846,10 +5913,10 @@ has been received. A single server insta identifiers if it is receiving queries on multiple interfaces. It is possible to override the default server identifier values by specifying -the `"dhcp-server-identifier"` option. This option configuration is only +the ``dhcp-server-identifier`` option. This option configuration is only supported at the subnet, shared network, client class, and global levels. It must not be specified at the host-reservation level. -When configuring the `"dhcp-server-identifier"` option at client-class level, the +When configuring the ``dhcp-server-identifier`` option at client-class level, the class must not set the ``only-if-required`` flag, because this class would not be evaluated before the server determines if the received DHCP message should be accepted for processing. Such classes are evaluated after subnet selection. @@ -5878,7 +5945,7 @@ for a subnet: How the DHCPv4 Server Selects a Subnet for the Client ===================================================== -The DHCPv4 server differentiates between directly connected clients, +The DHCPv4 server differentiates among directly connected clients, clients trying to renew leases, and clients sending their messages through relays. For directly connected clients, the server checks the configuration for the interface on which the message has been @@ -5914,9 +5981,7 @@ configurations, e.g. shared networks. Se .. note:: - Starting with Kea 1.7.9, the order used to find a subnet which matches - required conditions to be selected is the ascending subnet identifier - order. When the selected subnet is a member of a shared network, the + When the selected subnet is a member of a shared network, the whole shared network is selected. .. _dhcp4-relay-override: @@ -5934,8 +5999,8 @@ packet) to select the appropriate subnet However, that is not always the case. In certain uncommon — but valid — deployments, the relay address may not match the subnet. This usually means that there is more than one subnet allocated for a given link. The -two most common examples where this is the case are long-lasting network -renumbering (where both old and new address space is still being used) +two most common examples of this are long-lasting network +renumbering (where both old and new address spaces are still being used) and a cable network. In a cable network, both cable modems and the devices behind them are physically connected to the same link, yet they use distinct addressing. In such a case, the DHCPv4 server needs @@ -5962,8 +6027,8 @@ selects that subnet for a relay with add ], } -If `"relay"` is specified, the `"ip-addresses"` parameter within it is -mandatory. The `"ip-addresses"` parameter supports specifying a list of addresses. +If ``relay`` is specified, the ``ip-addresses`` parameter within it is +mandatory. The ``ip-addresses`` parameter supports specifying a list of addresses. .. _dhcp4-srv-example-client-class-relay: @@ -5971,17 +6036,17 @@ Segregating IPv4 Clients in a Cable Netw ------------------------------------------- In certain cases, it is useful to mix relay address information -(introduced in :ref:`dhcp4-relay-override`), with client classification (explained +(introduced in :ref:`dhcp4-relay-override`) with client classification (explained in :ref:`classify`). One specific example is in a cable network, where modems typically get addresses from a different subnet than all the devices connected behind them. -Let us assume that there is one Cable Modem Termination System (CMTS)) +Let us assume that there is one Cable Modem Termination System (CMTS) with one CM MAC (a physical link that modems are connected to). We want the modems to get addresses from the 10.1.1.0/24 subnet, while everything connected behind the modems should get addresses from the 192.0.2.0/24 subnet. The CMTS that acts as a relay uses address -10.1.1.1. The following configuration can serve that configuration: +10.1.1.1. The following configuration can serve that situation: :: @@ -6029,7 +6094,7 @@ triggered. After that is complete, the a declined (which indicates that it is used by an unknown entity and thus not available for assignment) and a probation time is set on it. Unless otherwise configured, the probation period lasts 24 hours; after -that period, the server will recover the lease (i.e. put it back into +that time, the server will recover the lease (i.e. put it back into the available state) and the address will be available for assignment again. It should be noted that if the underlying issue of a misconfigured device is not resolved, the duplicate-address scenario @@ -6066,15 +6131,15 @@ additional steps. In particular, both `` ``reclaimed-declined-addresses`` statistics (again in two variants, global and subnet-specific) are increased. -A note about statistics: The server does not decrease the +A note about statistics: The Kea server does not decrease the ``assigned-addresses`` statistics when a DHCPDECLINE is received and processed successfully. While technically a declined address is no longer assigned, the primary usage of the ``assigned-addresses`` statistic is to monitor pool utilization. Most people would forget to include -``declined-addresses`` in the calculation, and simply use +``declined-addresses`` in the calculation, and would simply use ``assigned-addresses``/``total-addresses``. This would cause a bias towards -under-representing pool utilization. As this has a potential to cause major -issues, ISC decided not to decrease ``assigned-addresses`` immediately after +under-representing pool utilization. As this has a potential to cause serious +confusion, ISC decided not to decrease ``assigned-addresses`` immediately after receiving DHCPDECLINE, but to do it later when Kea recovers the address back to the available pool. @@ -6087,485 +6152,452 @@ The DHCPv4 server supports the following .. tabularcolumns:: |p{0.2\linewidth}|p{0.1\linewidth}|p{0.7\linewidth}| -.. table:: DHCPv4 Statistics +.. table:: DHCPv4 statistics :class: longtable :widths: 20 10 70 - +-------------------------------------------+----------------+------------------------------------+ - | Statistic | Data Type | Description | - +===========================================+================+====================================+ - | pkt4-received | integer | Number of DHCPv4 packets | - | | | received. This includes all | - | | | packets: valid, bogus, | - | | | corrupted, rejected, etc. This | - | | | statistic is expected to grow | - | | | rapidly. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-discover-received | integer | Number of | - | | | DHCPDISCOVER packets | - | | | received. This | - | | | statistic is expected | - | | | to grow; its increase | - | | | means that clients | - | | | that just booted | - | | | started their | - | | | configuration process | - | | | and their initial | - | | | packets reached the | - | | | Kea server. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-offer-received | integer | Number of DHCPOFFER | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | zero at all times, as | - | | | DHCPOFFER packets are | - | | | sent by the server | - | | | and the server is | - | | | never expected to | - | | | receive them. A | - | | | non-zero value | - | | | indicates an error. | - | | | One likely cause | - | | | would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | DHCPOFFER messages | - | | | towards the server, | - | | | rather than back to | - | | | the clients. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-request-received | integer | Number of DHCPREQUEST | - | | | packets received. | - | | | This statistic is | - | | | expected to grow. Its | - | | | increase means that | - | | | clients that just | - | | | booted received the | - | | | server's response | - | | | (DHCPOFFER) and | - | | | accepted it, and are | - | | | now requesting an | - | | | address | - | | | (DHCPREQUEST). | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-ack-received | integer | Number of DHCPACK | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | zero at all times, as | - | | | DHCPACK packets are | - | | | sent by the server | - | | | and the server is | - | | | never expected to | - | | | receive them. A | - | | | non-zero value | - | | | indicates an error. | - | | | One likely cause | - | | | would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | DHCPACK messages | - | | | towards the server, | - | | | rather than back to | - | | | the clients. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-nak-received | integer | Number of DHCPNAK | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | zero at all times, as | - | | | DHCPNAK packets are | - | | | sent by the server | - | | | and the server is | - | | | never expected to | - | | | receive them. A | - | | | non-zero value | - | | | indicates an error. | - | | | One likely cause | - | | | would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | DHCPNAK messages | - | | | towards the server, | - | | | rather than back to | - | | | the clients. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-release-received | integer | Number of DHCPRELEASE | - | | | packets received. | - | | | This statistic is | - | | | expected to grow. Its | - | | | increase means that | - | | | clients that had an | - | | | address are shutting | - | | | down or ceasing to | - | | | use their addresses. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-decline-received | integer | Number of DHCPDECLINE | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | close to zero. Its | - | | | increase means that a | - | | | client leased an | - | | | address, but | - | | | discovered that the | - | | | address is currently | - | | | used by an unknown | - | | | device elsewhere in the | - | | | network. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-inform-received | integer | Number of DHCPINFORM | - | | | packets received. | - | | | This statistic is | - | | | expected to grow. Its | - | | | increase means that | - | | | there are clients | - | | | that either do not | - | | | need an address or | - | | | already have an | - | | | address and are | - | | | interested only in | - | | | getting additional | - | | | configuration | - | | | parameters. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-unknown-received | integer | Number of packets | - | | | received of an | - | | | unknown type. A | - | | | non-zero value of | - | | | this statistic | - | | | indicates that the | - | | | server received a | - | | | packet that it was not | - | | | able to recognize, | - | | | either with an | - | | | unsupported type or | - | | | possibly malformed | - | | | (without a message-type | - | | | option). | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-sent | integer | Number of DHCPv4 | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow every time | - | | | the server transmits | - | | | a packet. In general, | - | | | it should roughly | - | | | match pkt4-received, | - | | | as most incoming | - | | | packets cause the | - | | | server to respond. | - | | | There are exceptions | - | | | (e.g. DHCPRELEASE), | - | | | so do not worry if it | - | | | is less than | - | | | pkt4-received. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-offer-sent | integer | Number of DHCPOFFER | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow in most cases | - | | | after a DHCPDISCOVER | - | | | is processed. There | - | | | are certain uncommon, | - | | | but valid, cases | - | | | where incoming | - | | | DHCPDISCOVER packets | - | | | are dropped, but in | - | | | general this | - | | | statistic is expected | - | | | to be close to | - | | | pkt4-discover-received. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-ack-sent | integer | Number of DHCPACK | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow in most cases | - | | | after a DHCPREQUEST | - | | | is processed. There | - | | | are certain cases | - | | | where DHCPNAK is sent | - | | | instead. In general, | - | | | the sum of | - | | | pkt4-ack-sent and | - | | | pkt4-nak-sent should | - | | | be close to | - | | | pkt4-request-received. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-nak-sent | integer | Number of DHCPNAK | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow when the | - | | | server chooses not to | - | | | honor the address | - | | | requested by a | - | | | client. In general, | - | | | the sum of | - | | | pkt4-ack-sent and | - | | | pkt4-nak-sent should | - | | | be close to | - | | | pkt4-request-received. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-parse-failed | integer | Number of incoming | - | | | packets that could | - | | | not be parsed. A | - | | | non-zero value of | - | | | this statistic | - | | | indicates that the | - | | | server received a | - | | | malformed or | - | | | truncated packet. | - | | | This may indicate | - | | | problems in the | - | | | network, faulty | - | | | clients, or a bug in | - | | | the server. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-receive-drop | integer | Number of incoming | - | | | packets that were | - | | | dropped. The exact | - | | | reason for dropping | - | | | packets is logged, | - | | | but the most common | - | | | reasons may be: an | - | | | unacceptable packet | - | | | type was received, direct | - | | | responses are | - | | | forbidden, or the | - | | | server-id sent by the | - | | | client does not match | - | | | the server's | - | | | server-id. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].total-addresses | integer | Total number of | - | | | addresses available | - | | | for DHCPv4 | - | | | management; in other | - | | | words, this is the | - | | | sum of all addresses | - | | | in all configured | - | | | pools. This statistic | - | | | changes only during | - | | | configuration | - | | | updates. It does | - | | | not take into account | - | | | any addresses that | - | | | may be reserved due | - | | | to host reservation. | - | | | The *id* is the | - | | | subnet-id of a given | - | | | subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-------------------------------------------+----------------+------------------------------------+ - | cumulative-assigned-addresses | integer | Cumulative number of | - | | | addresses that have been | - | | | assigned since | - | | | server startup. It is | - | | | incremented each time | - | | | an address is assigned and | - | | | is not reset when the server | - | | | is reconfigured. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].cumulative-assigned-addresses | integer | Cumulative number of assigned | - | | | addresses in a given | - | | | subnet. It increases | - | | | every time a new | - | | | lease is allocated | - | | | (as a result of | - | | | receiving a | - | | | DHCPREQUEST message) | - | | | and never decreases. | - | | | The *id* is the subnet-id | - | | | of the subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].assigned-addresses | integer | Number of assigned | - | | | addresses in a given | - | | | subnet. It increases | - | | | every time a new | - | | | lease is allocated | - | | | (as a result of | - | | | receiving a | - | | | DHCPREQUEST message) | - | | | and decreases | - | | | every time a lease is | - | | | released (a | - | | | DHCPRELEASE message | - | | | is received) or | - | | | expires. The *id* is | - | | | the subnet-id of the | - | | | subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-------------------------------------------+----------------+------------------------------------+ - | reclaimed-leases | integer | Number of expired | - | | | leases that have been | - | | | reclaimed since | - | | | server startup. It is | - | | | incremented each time | - | | | an expired lease is | - | | | reclaimed and never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual leases have been | - | | | reclaimed. | - | | | This is a global | - | | | statistic that covers | - | | | all subnets. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].reclaimed-leases | integer | Number of expired | - | | | leases associated | - | | | with a given subnet | - | | | (*id* is the | - | | | subnet-id) that have | - | | | been reclaimed since | - | | | server startup. It is | - | | | incremented each time | - | | | an expired lease is | - | | | reclaimed. | - | | | The *id* is the | - | | | subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately. | - +-------------------------------------------+----------------+------------------------------------+ - | declined-addresses | integer | Number of IPv4 | - | | | addresses that are | - | | | currently declined; a | - | | | count of the number | - | | | of leases currently | - | | | unavailable. Once a | - | | | lease is recovered, | - | | | this statistic is | - | | | decreased; | - | | | ideally, this | - | | | statistic should be | - | | | zero. If this | - | | | statistic is non-zero | - | | | or increasing, a | - | | | network administrator | - | | | should investigate | - | | | whether there is a | - | | | misbehaving device in | - | | | the network. This is | - | | | a global statistic | - | | | that covers all | - | | | subnets. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].declined-addresses | integer | Number of IPv4 | - | | | addresses that are | - | | | currently declined in | - | | | a given subnet; a | - | | | count of the number | - | | | of leases currently | - | | | unavailable. Once a | - | | | lease is recovered, | - | | | this statistic is | - | | | decreased; | - | | | ideally, this | - | | | statistic should be | - | | | zero. If this | - | | | statistic is non-zero | - | | | or increasing, a | - | | | network administrator | - | | | should investigate | - | | | whether there is a | - | | | misbehaving device in | - | | | the network. The *id* | - | | | is the subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately. | - +-------------------------------------------+----------------+------------------------------------+ - | reclaimed-declined-addresses | integer | Number of IPv4 | - | | | addresses that were | - | | | declined, but have | - | | | now been recovered. | - | | | Unlike | - | | | declined-addresses, | - | | | this statistic never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual valid declines | - | | | were processed and | - | | | recovered from. This | - | | | is a global statistic | - | | | that covers all | - | | | subnets. | - +-------------------------------------------+----------------+------------------------------------+ - | subnet[id].reclaimed-declined-addresses | integer | Number of IPv4 | - | | | addresses that were | - | | | declined, but have | - | | | now been recovered. | - | | | Unlike | - | | | declined-addresses, | - | | | this statistic never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual valid declines | - | | | were processed and | - | | | recovered from. The | - | | | *id* is the subnet-id | - | | | of a given subnet. | - | | | This statistic is | - | | | exposed for each | - | | | subnet separately. | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-lease-query-received | integer | Number of IPv4 DHCPLEASEQUERY | - | | | packets received. (Only exists if | - | | | Leasequery hook library is | - | | | loaded.) | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-lease-query-response-unknown-sent | integer | Number of IPv4 DHCPLEASEUNKNOWN | - | | | responses sent. (Only exists if | - | | | Leasequery hook library is | - | | | loaded.) | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-lease-query-response-unassigned-sent | integer | Number of IPv4 DHCPLEASEUNASSIGNED | - | | | responses sent. (Only exists if | - | | | Leasequery hook library is | - | | | loaded.) | - +-------------------------------------------+----------------+------------------------------------+ - | pkt4-lease-query-response-active-sent | integer | Number of IPv4 DHCPLEASEACTIVE | - | | | responses sent. (Only exists if | - | | | Leasequery hook library is | - | | | loaded.) | - +-------------------------------------------+----------------+------------------------------------+ + +----------------------------------------------+----------------+------------------------------------+ + | Statistic | Data Type | Description | + +==============================================+================+====================================+ + | pkt4-received | integer | Number of DHCPv4 packets received. | + | | | This includes all packets: valid, | + | | | bogus, corrupted, rejected, etc. | + | | | This statistic is expected to grow | + | | | rapidly. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-discover-received | integer | Number of DHCPDISCOVER packets | + | | | received. This statistic is | + | | | expected to grow; its increase | + | | | means that clients that just | + | | | booted started their configuration | + | | | process and their initial packets | + | | | reached the Kea server. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-offer-received | integer | Number of DHCPOFFER packets | + | | | received. This statistic is | + | | | expected to remain zero at all | + | | | times, as DHCPOFFER packets are | + | | | sent by the server and the server | + | | | is never expected to receive them. | + | | | A non-zero value indicates an | + | | | error. One likely cause would be a | + | | | misbehaving relay agent that | + | | | incorrectly forwards DHCPOFFER | + | | | messages towards the server, | + | | | rather than back to the clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-request-received | integer | Number of DHCPREQUEST packets | + | | | received. This statistic is | + | | | expected to grow. Its increase | + | | | means that clients that just | + | | | booted received the server's | + | | | response (DHCPOFFER) and accepted | + | | | it, and are now requesting an | + | | | address (DHCPREQUEST). | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-ack-received | integer | Number of DHCPACK packets | + | | | received. This statistic is | + | | | expected to remain zero at all | + | | | times, as DHCPACK packets are sent | + | | | by the server and the server is | + | | | never expected to receive them. A | + | | | non-zero value indicates an error. | + | | | One likely cause would be a | + | | | misbehaving relay agent that | + | | | incorrectly forwards DHCPACK | + | | | messages towards the server, | + | | | rather than back to the clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-nak-received | integer | Number of DHCPNAK packets | + | | | received. This statistic is | + | | | expected to remain zero at all | + | | | times, as DHCPNAK packets are sent | + | | | by the server and the server is | + | | | never expected to receive them. A | + | | | non-zero value indicates an error. | + | | | One likely cause would be a | + | | | misbehaving relay agent that | + | | | incorrectly forwards DHCPNAK | + | | | messages towards the server, | + | | | rather than back to the clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-release-received | integer | Number of DHCPRELEASE packets | + | | | received. This statistic is | + | | | expected to grow. Its increase | + | | | means that clients that had an | + | | | address are shutting down or | + | | | ceasing to use their addresses. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-decline-received | integer | Number of DHCPDECLINE packets | + | | | received. This statistic is | + | | | expected to remain close to zero. | + | | | Its increase means that a client | + | | | leased an address, but discovered | + | | | that the address is currently | + | | | used by an unknown device | + | | | elsewhere in the network. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-inform-received | integer | Number of DHCPINFORM packets | + | | | received. This statistic is | + | | | expected to grow. Its increase | + | | | means that there are clients | + | | | that either do not need an address | + | | | or already have an address and are | + | | | interested only in getting | + | | | additional configuration | + | | | parameters. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-unknown-received | integer | Number of packets received of an | + | | | unknown type. A non-zero value of | + | | | this statistic indicates that the | + | | | server received a packet that it | + | | | was not able to recognize, either | + | | | with an unsupported type or | + | | | possibly malformed (without a | + | | | message-type option). | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-sent | integer | Number of DHCPv4 packets sent. | + | | | This statistic is expected to grow | + | | | every time the server transmits a | + | | | packet. In general, it should | + | | | roughly match pkt4-received, as | + | | | most incoming packets cause the | + | | | server to respond. There are | + | | | exceptions (e.g. DHCPRELEASE), so | + | | | do not worry if it is less than | + | | | pkt4-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-offer-sent | integer | Number of DHCPOFFER packets sent. | + | | | This statistic is expected to grow | + | | | in most cases after a DHCPDISCOVER | + | | | is processed. There are certain | + | | | uncommon, but valid, cases where | + | | | incoming DHCPDISCOVER packets are | + | | | dropped, but in general this | + | | | statistic is expected to be close | + | | | to pkt4-discover-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-ack-sent | integer | Number of DHCPACK packets sent. | + | | | This statistic is expected to grow | + | | | in most cases after a DHCPREQUEST | + | | | is processed. There are certain | + | | | cases where DHCPNAK is sent | + | | | instead. In general, the sum of | + | | | pkt4-ack-sent and pkt4-nak-sent | + | | | should be close to | + | | | pkt4-request-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-nak-sent | integer | Number of DHCPNAK packets sent. | + | | | This statistic is expected to grow | + | | | when the server chooses not to | + | | | honor the address requested by a | + | | | client. In general, the sum of | + | | | pkt4-ack-sent and pkt4-nak-sent | + | | | should be close to | + | | | pkt4-request-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-parse-failed | integer | Number of incoming packets that | + | | | could not be parsed. A non-zero | + | | | value of this statistic indicates | + | | | that the server received a | + | | | malformed or truncated packet. | + | | | This may indicate problems in the | + | | | network, faulty clients, or a bug | + | | | in the server. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-receive-drop | integer | Number of incoming packets that | + | | | were dropped. The exact reason for | + | | | dropping packets is logged, but | + | | | the most common reasons may be: an | + | | | unacceptable packet type was | + | | | received, direct responses are | + | | | forbidden, or the server-id sent | + | | | by the client does not match the | + | | | server's server-id. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].total-addresses | integer | Total number of addresses | + | | | available for DHCPv4 management; | + | | | in other words, this is the sum of | + | | | all addresses in all configured | + | | | pools. This statistic changes only | + | | | during configuration updates. It | + | | | does not take into account any | + | | | addresses that may be reserved due | + | | | to host reservation. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | cumulative-assigned-addresses | integer | Cumulative number of addresses | + | | | that have been assigned since | + | | | server startup. It is incremented | + | | | each time an address is assigned | + | | | and is not reset when the server | + | | | is reconfigured. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].cumulative-assigned-addresses | integer | Cumulative number of assigned | + | | | addresses in a given subnet. It | + | | | increases every time a new lease | + | | | is allocated (as a result of | + | | | receiving a DHCPREQUEST message) | + | | | and never decreases. The *id* is | + | | | the subnet-id of the subnet. This | + | | | statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].assigned-addresses | integer | Number of assigned addresses in a | + | | | given subnet. It increases every | + | | | time a new lease is allocated (as | + | | | a result of receiving a | + | | | DHCPREQUEST message) and decreases | + | | | every time a lease is released (a | + | | | DHCPRELEASE message is received) | + | | | or expires. The *id* is the | + | | | subnet-id of the subnet. This | + | | | statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | reclaimed-leases | integer | Number of expired leases that have | + | | | been reclaimed since server | + | | | startup. It is incremented each | + | | | time an expired lease is reclaimed | + | | | and never decreases. It can be | + | | | used as a long-term indicator of | + | | | how many actual leases have been | + | | | reclaimed. This is a global | + | | | statistic that covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].reclaimed-leases | integer | Number of expired leases | + | | | associated with a given subnet | + | | | (*id* is the subnet-id) that have | + | | | been reclaimed since server | + | | | startup. It is incremented each | + | | | time an expired lease is | + | | | reclaimed. The *id* is the | + | | | subnet-id of a given subnet. This | + | | | statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | declined-addresses | integer | Number of IPv4 addresses that are | + | | | currently declined; a count of the | + | | | number of leases currently | + | | | unavailable. Once a lease is | + | | | recovered, this statistic is | + | | | decreased; ideally, this statistic | + | | | should be zero. If this statistic | + | | | is non-zero or increasing, a | + | | | network administrator should | + | | | investigate whether there is a | + | | | misbehaving device in the network. | + | | | This is a global statistic that | + | | | covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].declined-addresses | integer | Number of IPv4 addresses that are | + | | | currently declined in a given | + | | | subnet; a count of the number of | + | | | leases currently unavailable. Once | + | | | a lease is recovered, this | + | | | statistic is decreased; ideally, | + | | | this statistic should be zero. If | + | | | this statistic is non-zero or | + | | | increasing, a network | + | | | administrator should investigate | + | | | whether there is a misbehaving | + | | | device in the network. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | reclaimed-declined-addresses | integer | Number of IPv4 addresses that were | + | | | declined, but have now been | + | | | recovered. Unlike | + | | | declined-addresses, this statistic | + | | | never decreases. It can be used as | + | | | a long-term indicator of how many | + | | | actual valid declines were | + | | | processed and recovered from. This | + | | | is a global statistic that covers | + | | | all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].reclaimed-declined-addresses | integer | Number of IPv4 addresses that were | + | | | declined, but have now been | + | | | recovered. Unlike | + | | | declined-addresses, this statistic | + | | | never decreases. It can be used as | + | | | a long-term indicator of how many | + | | | actual valid declines were | + | | | processed and recovered from. The | + | | | *id* is the subnet-id of a given | + | | | subnet. This statistic is exposed | + | | | for each subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-lease-query-received | integer | Number of IPv4 DHCPLEASEQUERY | + | | | packets received. (Only exists if | + | | | Leasequery hook library is | + | | | loaded.) | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-lease-query-response-unknown-sent | integer | Number of IPv4 DHCPLEASEUNKNOWN | + | | | responses sent. (Only exists if | + | | | Leasequery hook library is | + | | | loaded.) | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-lease-query-response-unassigned-sent | integer | Number of IPv4 DHCPLEASEUNASSIGNED | + | | | responses sent. (Only exists if | + | | | Leasequery hook library is | + | | | loaded.) | + +----------------------------------------------+----------------+------------------------------------+ + | pkt4-lease-query-response-active-sent | integer | Number of IPv4 DHCPLEASEACTIVE | + | | | responses sent. (Only exists if | + | | | Leasequery hook library is | + | | | loaded.) | + +----------------------------------------------+----------------+------------------------------------+ + | v4-allocation-fail | integer | Number of total address allocation | + | | | failures for a particular client. | + | | | This consists in the number of | + | | | lease allocation attempts that the | + | | | server made before giving up and | + | | | was unable to use any of the | + | | | address pools. This is a global | + | | | statistic that covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-allocation-fail | integer | Number of total address allocation | + | | | failures for a particular client. | + | | | This consists in the number of | + | | | lease allocation attempts that the | + | | | server made before giving up and | + | | | was unable to use any of the | + | | | address pools. The *id* is the | + | | | subnet-id of a given subnet. This | + | | | statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | v4-allocation-fail-shared-network | integer | Number of address allocation | + | | | failures for a particular client | + | | | connected to a shared network. | + | | | This is a global statistic that | + | | | covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-allocation-fail-shared-network | integer | Number of address allocation | + | | | failures for a particular client | + | | | connected to a shared network. | + | | | The *id* is the subnet-id of a | + | | | given subnet. This statistic is | + | | | exposed for each subnet | + | | | separately. | + +----------------------------------------------+----------------+------------------------------------+ + | v4-allocation-fail-subnet | integer | Number of address allocation | + | | | failures for a particular client | + | | | connected to a subnet that does | + | | | not belong to a shared network. | + | | | This is a global statistic that | + | | | covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-allocation-fail-subnet | integer | Number of address allocation | + | | | failures for a particular client | + | | | connected to a subnet that does | + | | | not belong to a shared network. | + | | | The *id* is the subnet-id of a | + | | | given subnet. This statistic is | + | | | exposed for each subnet | + | | | separately. | + +----------------------------------------------+----------------+------------------------------------+ + | v4-allocation-fail-no-pools | integer | Number of address allocation | + | | | failures because the server could | + | | | not use any configured pools for | + | | | a particular client. It is also | + | | | possible that all of the subnets | + | | | from which the server attempted to | + | | | assign an address lack address | + | | | pools. In this case, it should be | + | | | considered misconfiguration if an | + | | | operator expects that some clients | + | | | should be assigned dynamic | + | | | addresses. This is a global | + | | | statistic that covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-allocation-fail-no-pools | integer | Number of address allocation | + | | | failures because the server could | + | | | not use any configured pools for | + | | | a particular client. It is also | + | | | possible that all of the subnets | + | | | from which the server attempted to | + | | | assign an address lack address | + | | | pools. In this case, it should be | + | | | considered misconfiguration if an | + | | | operator expects that some clients | + | | | should be assigned dynamic | + | | | addresses. The *id* is the | + | | | subnet-id of a given subnet. This | + | | | statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | v4-allocation-fail-classes | integer | Number of address allocation | + | | | failures when the client's packet | + | | | belongs to one or more classes. | + | | | There may be several reasons why a | + | | | lease was not assigned. One of | + | | | them may be a case when all pools | + | | | require packet to belong to | + | | | certain classes and the incoming | + | | | packet didn't belong to any of | + | | | them. Another case where this | + | | | information may be useful is to | + | | | point out that the pool reserved | + | | | to a given class has ran out of | + | | | addresses. This is a global | + | | | statistic that covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-allocation-fail-classes | integer | Number of address allocation | + | | | failures when the client's packet | + | | | belongs to one or more classes. | + | | | There may be several reasons why a | + | | | lease was not assigned. One of | + | | | them may be a case when all pools | + | | | require packet to belong to | + | | | certain classes and the incoming | + | | | packet didn't belong to any of | + | | | them. Another case where this | + | | | information may be useful is to | + | | | point out that the pool reserved | + | | | to a given class has ran out of | + | | | addresses. The *id* is the | + | | | subnet-id of a given subnet. This | + | | | statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | v4-reservation-conflicts | integer | Number of host reservation | + | | | allocation conflicts which have | + | | | occurred across every subnet. When | + | | | a client sends a DHCP Discover and | + | | | is matched to a host reservation | + | | | which is already leased to another | + | | | client, this counter is increased | + | | | by 1. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].v4-reservation-conflicts | integer | Number of host reservation | + | | | allocation conflicts which have | + | | | occurred in a specific subnet. | + | | | When a client sends a DHCP | + | | | Discover and is matched to a host | + | | | reservation which is already | + | | | leased to another client, this | + | | | counter is increased by 1. | + +----------------------------------------------+----------------+------------------------------------+ .. note:: This section describes DHCPv4-specific statistics. For a general overview and usage of statistics, see :ref:`stats`. -Since Kea 1.7.7, the DHCPv4 server provides two global -parameters to control statistics default sample limits: +The DHCPv4 server provides two global parameters to control the default sample +limits of statistics: - ``statistic-default-sample-count`` - determines the default maximum - number of samples which are kept. The special value of zero + number of samples which are kept. The special value of 0 indicates that a default maximum age should be used. - ``statistic-default-sample-age`` - determines the default maximum @@ -6668,12 +6700,12 @@ library, it is typically defined as a pa However, sometimes there is a need to specify parameters that are different for each pool. -See :ref:`user-context` for additional background regarding the user -context idea. See :ref:`user-context-hooks` for a discussion from the +See :ref:`user-context` for additional background regarding the +user-context idea. See :ref:`user-context-hooks` for a discussion from the hooks perspective. -User contexts can be specified at global scope; at the shared network, subnet, -pool, client class, option data, or definition level; and via host +User contexts can be specified at global scope; at the shared-network, subnet, +pool, client-class, option-data, or definition level; and via host reservation. One other useful feature is the ability to store comments or descriptions. @@ -6712,7 +6744,7 @@ of LED devices could be configured in th Kea does not interpret or use the user-context information; it simply stores it and makes it available to the hook libraries. It is up to each hook library to -extract that information and use it. The parser translates a "comment" +extract that information and use it. The parser translates a ``comment`` entry into a user context with the entry, which allows a comment to be attached inside the configuration itself. @@ -6721,30 +6753,29 @@ attached inside the configuration itself Supported DHCP Standards ======================== -The following standards are currently supported: +The following standards are currently supported in Kea: -- *BOOTP Vendor Information Extensions*, `RFC - 1497 `__: This requires the open - source BOOTP hook to be loaded. See :ref:`hooks-bootp` for details. +- *BOOTP Vendor Information Extensions*, `RFC 1497 + `__: This requires the open source + BOOTP hook to be loaded. See :ref:`hooks-bootp` for details. -- *Dynamic Host Configuration Protocol*, `RFC - 2131 `__: Supported messages are +- *Dynamic Host Configuration Protocol*, `RFC 2131 + `__: Supported messages are DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPRELEASE (7), DHCPINFORM (8), DHCPACK (5), and DHCPNAK(6). -- *DHCP Options and BOOTP Vendor Extensions*, `RFC - 2132 `__: Supported options are - PAD (0), END(255), Message Type(53), DHCP Server Identifier (54), - Domain Name (15), DNS Servers (6), IP Address Lease Time (51), Subnet - Mask (1), and Routers (3). - -- *The IPv4 Subnet Selection Option for DHCP*, `RFC - 3011 `__: The subnet selection option - is supported. If received in a packet, it is used in the subnet selection +- *DHCP Options and BOOTP Vendor Extensions*, `RFC 2132 + `__: Supported options are PAD (0), + END(255), Message Type(53), DHCP Server Identifier (54), Domain Name (15), + DNS Servers (6), IP Address Lease Time (51), Subnet Mask (1), and Routers (3). + +- *The IPv4 Subnet Selection Option for DHCP*, `RFC 3011 + `__: The subnet-selection option is + supported; if received in a packet, it is used in the subnet-selection process. -- *DHCP Relay Agent Information Option*, `RFC - 3046 `__: Relay Agent Information, +- *DHCP Relay Agent Information Option*, `RFC 3046 + `__: Relay Agent Information, Circuit ID, and Remote ID options are supported. - *Link Selection sub-option for the Relay Agent Option*, `RFC 3527 @@ -6752,41 +6783,49 @@ The following standards are currently su is supported. - *Vendor-Identifying Vendor Options for Dynamic Host Configuration - Protocol version 4*, `RFC - 3925 `__: Vendor-Identifying - Vendor Class and Vendor-Identifying Vendor-Specific Information - options are supported. - -- *Subscriber-ID Suboption for the DHCP Relay Agent Option*, `RFC - 3993 `__: The Subscriber-ID - option is supported. + Protocol version 4*, `RFC 3925 + `__: The Vendor-Identifying Vendor Class + and Vendor-Identifying Vendor-Specific Information options are supported. + +- *Subscriber-ID Suboption for the DHCP Relay Agent Option*, `RFC 3993 + `__: The Subscriber-ID option is + supported. - *The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option*, `RFC 4702 - `__: The Kea server is able to - handle the Client FQDN option. Also, it is able to use the - ``kea-dhcp-ddns`` component to initiate appropriate DNS Update - operations. + `__: The Kea server is able to handle + the Client FQDN option. Also, it is able to use the ``kea-dhcp-ddns`` + component to initiate appropriate DNS Update operations. -- *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host - Configuration Protocol (DHCP) Clients*, `RFC 4703 +- *Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic + Host Configuration Protocol (DHCP) Clients*, `RFC 4703 `__: The DHCPv6 server uses a DHCP-DDNS server to resolve conflicts. -- *Client Identifier Option in DHCP Server Replies*, `RFC - 6842 `__: The server by default sends - back the ``client-id`` option. That capability may be disabled. See :ref:`dhcp4-echo-client-id` for details. - -- *Generalized UDP Source Port for DHCP Relay*, `RFC 8357 - `__: The Kea server - handles the Relay Agent Information Source Port sub-option in a received - message, remembers the UDP port, and sends back reply to the same relay - agent using this UDP port. +- *Client Identifier Option in DHCP Server Replies*, `RFC 6842 + `__: The server by default sends back + the ``client-id`` option. That capability can be disabled. See + :ref:`dhcp4-echo-client-id` for details. + +- *Generalized UDP Source Port for the DHCP Relay Agent Option*, `RFC 8357 + `__: The Kea server handles the Relay + Agent Information Source Port sub-option in a received message, remembers the + UDP port, and sends back a reply to the same relay agent using this UDP port. + +- *Captive-Portal Identification in DHCP and Router Advertisements (RAs)*, `RFC + 8910 `__: The Kea server can configure + both v4 and v6 versions of the captive portal options. - *IPv6-Only Preferred Option for DHCPv4*, `RFC 8925 - `__: The Kea - server is able to designate its pools and subnets as IPv6-Only Preferred and send - back the ``v6-only-preferred`` option to clients that requested it. + `__: The Kea server is able to designate + its pools and subnets as IPv6-Only Preferred and send back the + ``v6-only-preferred`` option to clients that requested it. + +- *Server Identifier Override sub-option for the Relay Agent Option*, `RFC 5107 + `__: The server identifier override + sub-option is supported. The implementation is not complete according to the + RFC, because the server does not store the RAI, but the functionality handles + expected use cases. Known RFC Violations -------------------- @@ -6795,8 +6834,8 @@ In principle, Kea aspires to be a refere However, in some cases there are practical aspects that prevent Kea from completely adhering to the text of the RFC documents. - `RFC 2131 `__, page 30, says that if the incoming DHCPREQUEST packet has no - `requested IP address` option and ``ciaddr`` is not set, the server is supposed to respond with NAK. However, - broken clients exist that will always send a DHCPREQUEST without those indicated. In that event, Kea accepts the DHCPREQUEST, + "requested IP address" option and ``ciaddr`` is not set, the server is supposed to respond with NAK. However, + broken clients exist that will always send a DHCPREQUEST without those options indicated. In that event, Kea accepts the DHCPREQUEST, assigns an address, and responds with an ACK. - `RFC 2131 `__, table 5, says that messages @@ -6820,9 +6859,9 @@ are clearly marked as such. headers (including data link layer, IP, and UDP headers) are created and parsed by Kea, rather than by the system kernel. Currently, Kea can only parse the data-link layer headers with a format adhering to - the IEEE 802.3 standard, and assumes this data link layer header + the IEEE 802.3 standard, and assumes this data-link-layer header format for all interfaces. Thus, Kea does not work on interfaces - which use different data-link layer header formats (e.g. Infiniband). + which use different data-link-layer header formats (e.g. Infiniband). - The DHCPv4 server does not verify that an assigned address is unused. According to `RFC 2131 `__, the @@ -6835,7 +6874,7 @@ Kea DHCPv4 Server Examples ========================== A collection of simple-to-use examples for the DHCPv4 component of Kea -is available with the source files, located in the `doc/examples/kea4` +is available with the source files, located in the ``doc/examples/kea4`` directory. .. _dhcp4-cb: @@ -6863,19 +6902,10 @@ the DHCPv4 server parameters can be conf parameters must be specified in the JSON configuration file, if required. -The following table lists DHCPv4-specific parameters supported by the -Configuration Backend, with an indication of the level of the hierarchy -at which it is currently supported. "n/a" marks cases when a -given parameter is not applicable at the particular level of the -hierarchy or in cases when the server does not support the parameter -at this level of the hierarchy. "no" is used when a parameter is -supported at the given level of the hierarchy but is not -configurable via the Configuration Backend. - All supported parameters can be configured via the ``cb_cmds`` hook library -described in the :ref:`cb-cmds-library` section. The general rule is that +described in the :ref:`hooks-cb-cmds` section. The general rule is that scalar global parameters are set using -``remote-global-parameter4-set``; shared network-specific parameters +``remote-global-parameter4-set``; shared-network-specific parameters are set using ``remote-network4-set``; and subnet- and pool-level parameters are set using ``remote-subnet4-set``. Whenever there is an exception to this general rule, it is highlighted in the @@ -6892,11 +6922,15 @@ and DHCPv6), the shareable configuration networks. Thus, they can be explicitly associated with multiple server tags. The global parameters, option definitions, and global options are non-shareable and can be associated with only one server tag. This rule does not apply -to the configuration elements associated with `"all"` servers. Any configuration -element associated with `"all"` servers (using the `"all"` keyword as a server tag) is +to the configuration elements associated with ``all`` servers. Any configuration +element associated with ``all`` servers (using the ``all`` keyword as a server tag) is used by all servers connecting to the configuration database. -.. table:: List of DHCPv4 Parameters Supported by the Configuration Backend +The following table lists DHCPv4-specific parameters supported by the +Configuration Backend, with an indication of the level of the hierarchy +at which it is currently supported. + +.. table:: List of DHCPv4 parameters supported by the Configuration Backend +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ | Parameter | Global | Client | Shared | Subnet | Pool | @@ -6910,9 +6944,9 @@ used by all servers connecting to the co +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ | boot-file-name | yes | yes | yes | yes | n/a | +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ - | cache-max-age | yes | n/a | todo | todo | n/a | + | cache-max-age | yes | n/a | no | no | n/a | +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ - | cache-threshold | yes | n/a | todo | todo | n/a | + | cache-threshold | yes | n/a | no | no | n/a | +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ | calculate-tee-times | yes | n/a | yes | yes | n/a | +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ @@ -6981,12 +7015,23 @@ used by all servers connecting to the co | t2-percent | yes | n/a | yes | yes | n/a | +-----------------------------+----------------------------+--------------+-------------+-------------+-------------+ +- ``yes`` - indicates that the parameter is supported at the given + level of the hierarchy and can be configured via the Configuration Backend. + +- ``no`` - indicates that a parameter is supported at the given level + of the hierarchy but cannot be configured via the Configuration Backend. + +- ``n/a`` - indicates that a given parameter is not applicable + at the particular level of the hierarchy or that the + server does not support the parameter at that level. + .. _dhcp4-cb-json: Enabling the Configuration Backend ---------------------------------- -Consider the following configuration snippet: +Consider the following configuration snippet, which uses a MySQL configuration +database: :: @@ -7011,7 +7056,7 @@ Consider the following configuration sni } The ``config-control`` command contains two parameters. ``config-databases`` -is a list which contains one element comprising database type, location, +is a list that contains one element, which includes the database type, its location, and the credentials to be used to connect to this database. (Note that the parameters specified here correspond to the database specification for the lease database backend and hosts database backend.) Currently @@ -7021,6 +7066,30 @@ during startup or reconfiguration, and f available for this server from the database. This configuration is merged into the configuration read from the configuration file. +The following snippet illustrates the use of a PostgreSQL database: + +:: + + "Dhcp4": { + "server-tag": "my DHCPv4 server", + "config-control": { + "config-databases": [{ + "type": "postgresql", + "name": "kea", + "user": "kea", + "password": "kea", + "host": "192.0.2.1", + "port": 5432 + }], + "config-fetch-wait-time": 20 + }, + "hooks-libraries": [{ + "library": "/usr/local/lib/kea/hooks/libdhcp_pgsql_cb.so" + }, { + "library": "/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so" + }], + } + .. note:: Whenever there is a conflict between the parameters specified in the @@ -7055,19 +7124,19 @@ default value of ``config-fetch-wait-tim The ``config-backend-pull`` command can be used to force the server to immediately poll any configuration changes from the database and avoid -waiting for the next fetch cycle. (This command was added in Kea release -1.7.1 for both DHCPv4 and DHCPv6 servers.) +waiting for the next fetch cycle. -Finally, in the configuration example above, two hook libraries are -loaded. The first, ``libdhcp_mysql_cb.so``, is the implementation of -the Configuration Backend for MySQL. It must be always present when the -server uses MySQL as the configuration repository. Failing to load this -library will result in an error during the server configuration if the -`"mysql"` database is selected with the ``config-control`` parameter. +In the configuration examples above, two hook libraries are loaded. The first +is a library which implements the Configuration Backend for a specific database +type: ``libdhcp_mysql_cb.so`` provides support for MySQL and ``libdhcp_pgsql_cb.so`` +provides support for PostgreSQL. The library loaded must match the database +``type`` specified within the ``config-control`` parameter or an will error be +logged when the server attempts to load its configuration and the load will +fail. The second hook library, ``libdhcp_cb_cmds.so``, is optional. It should be loaded when the Kea server instance is to be used to manage the -configuration in the database. See the :ref:`cb-cmds-library` section for +configuration in the database. See the :ref:`hooks-cb-cmds` section for details. This hook library is only available to ISC customers with a paid support contract. @@ -7079,8 +7148,8 @@ Kea DHCPv4 Compatibility Configuration P ISC's intention is for Kea to follow the RFC documents to promote better standards compliance. However, many buggy DHCP implementations already exist that cannot be easily fixed or upgraded. Therefore, Kea provides an easy-to-use compatibility -mode for broken or non-compliant clients. For that purpose, flags must be -enabled to enable uncommon practices: +mode for broken or non-compliant clients. For that purpose, the compatibility option must be +enabled to permit uncommon practices: .. code-block:: json @@ -7098,7 +7167,7 @@ Lenient Option Parsing By default, tuple fields defined in custom options are parsed as a set of length-value pairs. -With ``lenient-option-parsing: "true"``, if a length ever exceeds the rest of +With ``"lenient-option-parsing": true``, if a length ever exceeds the rest of the option's buffer, previous versions of Kea returned a log message ``unable to parse the opaque data tuple, the buffer length is x, but the tuple length is y`` with ``x < y``; this no longer occurs. Instead, the value is considered to be the rest of the buffer, diff -pruN 2.0.2-3/doc/sphinx/arm/dhcp6-srv.rst 2.2.0-1/doc/sphinx/arm/dhcp6-srv.rst --- 2.0.2-3/doc/sphinx/arm/dhcp6-srv.rst 2022-02-27 22:10:59.000000000 +0000 +++ 2.2.0-1/doc/sphinx/arm/dhcp6-srv.rst 2022-07-26 06:08:02.000000000 +0000 @@ -11,8 +11,8 @@ Starting and Stopping the DHCPv6 Server It is recommended that the Kea DHCPv6 server be started and stopped using ``keactrl`` (described in :ref:`keactrl`); however, it is also -possible to run the server directly. It accepts the following -command-line switches: +possible to run the server directly via the ``kea-dhcp6`` command, which accepts +the following command-line switches: - ``-c file`` - specifies the configuration file. This is the only mandatory switch. @@ -25,20 +25,20 @@ command-line switches: when debugging. - ``-p server-port`` - specifies the local UDP port on which the server - will listen. This is only useful during testing, as a DHCPv6 server - listening on ports other than the standard ones will not be able to + listens. This is only useful during testing, as a DHCPv6 server + listening on ports other than the standard ones is not able to handle regular DHCPv6 queries. - ``-P client-port`` - specifies the remote UDP port to which the - server will send all responses. This is only useful during testing, + server sends all responses. This is only useful during testing, as a DHCPv6 server sending responses to ports other than the standard - ones will not be able to handle regular DHCPv6 queries. + ones is not able to handle regular DHCPv6 queries. -- ``-t file`` - specifies a configuration file to be tested. Kea-dhcp6 - will load it, check it, and exit. During the test, log messages are +- ``-t file`` - specifies a configuration file to be tested. ``kea-dhcp6`` + loads it, checks it, and exits. During the test, log messages are printed to standard output and error messages to standard error. The result of the test is reported through the exit code (0 = - configuration looks ok, 1 = error encountered). The check is not + configuration looks OK, 1 = error encountered). The check is not comprehensive; certain checks are possible only when running the server. @@ -52,33 +52,33 @@ command-line switches: is a copy of the ``config.report`` file produced by ``./configure``; it is embedded in the executable binary. -On startup, the server will detect available network interfaces and will -attempt to open UDP sockets on all interfaces mentioned in the +On startup, the server detects available network interfaces and +attempts to open UDP sockets on all interfaces listed in the configuration file. Since the DHCPv6 server opens privileged ports, it -requires root access. This daemon must be run as root. +requires root access; this daemon must be run as root. -During startup, the server will attempt to create a PID file of the -form: [**runstatedir**]/kea/[**conf name**].kea-dhcp6.pid where: +During startup, the server attempts to create a PID file of the +form: ``[runstatedir]/kea/[conf name].kea-dhcp6.pid``, where: - ``runstatedir``: The value as passed into the build configure - script; it defaults to "/usr/local/var/run". Note that this value may be + script; it defaults to ``/usr/local/var/run``. Note that this value may be overridden at runtime by setting the environment variable ``KEA_PIDFILE_DIR``, although this is intended primarily for testing purposes. - ``conf name``: The configuration file name used to start the server, minus all preceding paths and the file extension. For example, given - a pathname of "/usr/local/etc/kea/myconf.txt", the portion used would - be "myconf". + a pathname of ``/usr/local/etc/kea/myconf.txt``, the portion used would + be ``myconf``. If the file already exists and contains the PID of a live process, the -server will issue a DHCP6_ALREADY_RUNNING log message and exit. It is +server issues a ``DHCP6_ALREADY_RUNNING`` log message and exits. It is possible, though unlikely, that the file is a remnant of a system crash and the process to which the PID belongs is unrelated to Kea. In such a -case it would be necessary to manually delete the PID file. +case, it would be necessary to manually delete the PID file. The server can be stopped using the ``kill`` command. When running in a -console, the server can also be shut down by pressing ctrl-c. It detects +console, the server can also be shut down by pressing Ctrl-c. Kea detects the key combination and shuts down gracefully. .. _dhcp6-configuration: @@ -89,8 +89,10 @@ DHCPv6 Server Configuration Introduction ------------ -This section explains how to configure the DHCPv6 server using a -configuration file. Before DHCPv6 is started, its configuration file must +This section explains how to configure the Kea DHCPv6 server using a +configuration file. + +Before DHCPv6 is started, its configuration file must be created. The basic configuration is as follows: :: @@ -122,9 +124,9 @@ be created. The basic configuration is a { "subnet": "2001:db8:1::/64", "pools": [ - { - "pool": "2001:db8:1::1-2001:db8:1::ffff" - } + { + "pool": "2001:db8:1::1-2001:db8:1::ffff" + } ] } ] @@ -143,27 +145,19 @@ server; they do not impact its operation The configuration starts in the first line with the initial opening curly bracket (or brace). Each configuration must contain an object specifying the configuration of the Kea module using it. In the example -above this object is called ``Dhcp6``. - -.. note:: - - In the current Kea release it is possible to specify configurations - of multiple modules within a single configuration file, but this is - not recommended and support for it was removed in 1.7.10 release, - including the ``Logging`` object: its previous content, the list - of loggers, must now be inside the ``Dhcp6`` object. +above, this object is called ``Dhcp6``. -The Dhcp6 configuration starts with the ``"Dhcp6": {`` line and ends +The ``Dhcp6`` configuration starts with the ``"Dhcp6": {`` line and ends with the corresponding closing brace (in the above example, the brace after the last comment). Everything defined between those lines is -considered to be the Dhcp6 configuration. +considered to be the ``Dhcp6`` configuration. In general, the order in which those parameters appear does not -matter, but there are two caveats. The first one is to remember that the -configuration file must be well-formed JSON. That means that the +matter, but there are two caveats. The first one is that the +configuration file must be well-formed JSON, meaning that the parameters for any given scope must be separated by a comma, and there must not be a comma after the last parameter. When reordering a -configuration file, keep in mind that moving a parameter to or from the +configuration file, moving a parameter to or from the last position in a given scope may also require moving the comma. The second caveat is that it is uncommon — although legal JSON — to repeat the same parameter multiple times. If that happens, the last occurrence @@ -174,21 +168,21 @@ in the configuration file. The first few DHCPv6 configuration elements define some global parameters. ``valid-lifetime`` defines how long the -addresses (leases) given out by the server are valid. If nothing -changes, a client that got an address is allowed to use it for 4000 +addresses (leases) given out by the server are valid; the default +is for a client to be allowed to use a given address for 4000 seconds. (Note that integer numbers are specified as is, without any quotes around them.) The address will become deprecated in 3000 seconds, -i.e. clients are allowed to keep old connections, but can't use this -address for creating new connections. ``renew-timer`` and -``rebind-timer`` are values (also in seconds) that define T1 and T2 timers that govern -when the client will begin the renewal and rebind procedures. - -The ``interfaces-config`` map specifies the server configuration -concerning the network interfaces on which the server should listen to -the DHCP messages. The ``interfaces`` parameter specifies a list of +i.e. clients are allowed to keep old connections, but cannot use this +address to create new connections. ``renew-timer`` and +``rebind-timer`` are values (also in seconds) that define T1 and T2 timers, which govern +when the client begins the renewal and rebind procedures. + +The ``interfaces-config`` map specifies the +network interfaces on which the server should listen to +DHCP messages. The ``interfaces`` parameter specifies a list of network interfaces on which the server should listen. Lists are opened and closed with square brackets, with elements separated by commas. To -listen on two interfaces, the ``interfaces-config`` should look like +listen on two interfaces, the ``interfaces-config`` element should look like this: :: @@ -197,17 +191,17 @@ this: "interfaces": [ "eth0", "eth1" ] }, -The next couple of lines define the lease database, the place where the +The next lines define the lease database, the place where the server stores its lease information. This particular example tells the -server to use ``memfile``, which is the simplest (and fastest) database +server to use memfile, which is the simplest and fastest database backend. It uses an in-memory database and stores leases on disk in a -CSV (comma-separated values) file. This is a very simple configuration; usually the lease -database configuration is more extensive and contains additional -parameters. Note that ``lease-database`` is an object and opens up a new -scope, using an opening brace. Its parameters (just one in this example: +CSV (comma-separated values) file. This is a very simple configuration example; +usually the lease database configuration is more extensive and contains +additional parameters. Note that ``lease-database`` is an object and opens up a +new scope, using an opening brace. Its parameters (just one in this example: ``type``) follow. If there were more than one, they would be separated by commas. This scope is closed with a closing brace. As more parameters -for the Dhcp6 definition follow, a trailing comma is present. +for the ``Dhcp6`` definition follow, a trailing comma is present. Finally, we need to define a list of IPv6 subnets. This is the most important DHCPv6 configuration structure, as the server uses that @@ -216,10 +210,10 @@ which the server is expected to receive specified with the ``subnet6`` parameter. It is a list, so it starts and ends with square brackets. Each subnet definition in the list has several attributes associated with it, so it is a structure and is -opened and closed with braces. At a minimum, a subnet definition has to -have at least two parameters: ``subnet`` (which defines the whole -subnet) and ``pools`` (which is a list of dynamically allocated pools -that are governed by the DHCP server). +opened and closed with braces. At a minimum, a subnet definition must +have at least two parameters: ``subnet``, which defines the whole +subnet; and ``pools``, which is a list of dynamically allocated pools +that are governed by the DHCP server. The example contains a single subnet. If more than one were defined, additional elements in the ``subnet6`` parameter would be specified and @@ -242,33 +236,33 @@ syntax would be used: Note that indentation is optional and is used for aesthetic purposes only. In some cases it may be preferable to use more compact notation. -After all the parameters are specified, we have two contexts open: global -and Dhcp6; thus, we need two closing curly brackets to close them. +After all the parameters have been specified, there are two contexts open: +``global`` and ``Dhcp6``; thus, two closing curly brackets must be used to close +them. Lease Storage ------------- All leases issued by the server are stored in the lease database. -Currently there are four database backends available: memfile (which is -the default backend), MySQL, PostgreSQL, and Cassandra. +There are three database backends available: memfile +(the default), MySQL, PostgreSQL. Memfile - Basic Storage for Leases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The server is able to store lease data in different repositories. Larger -deployments may elect to store leases in a database. +deployments may elect to store leases in a database; :ref:`database-configuration6` describes this option. In -typical smaller deployments, though, the server will store lease +typical smaller deployments, though, the server stores lease information in a CSV file rather than a database. As well as requiring less administration, an advantage of using a file for storage is that it eliminates a dependency on third-party database software. -The configuration of the file backend (memfile) is controlled through -the Dhcp6/lease-database parameters. The ``type`` parameter is mandatory -and it specifies which storage for leases the server should use. The -value of ``"memfile"`` indicates that the file should be used as the -storage. The following list gives additional optional parameters that -can be used to configure the memfile backend. +The configuration of the memfile backend is controlled through +the ``Dhcp6``/``lease-database`` parameters. The ``type`` parameter is mandatory +and specifies which storage for leases the server should use, through +the ``"memfile"`` value. The following list gives additional optional parameters +that can be used to configure the memfile backend. - ``persist``: controls whether the new leases and updates to existing leases are written to the file. It is strongly recommended that the @@ -282,23 +276,23 @@ can be used to configure the memfile bac writing lease updates to the lease file. - ``name``: specifies an absolute location of the lease file in which - new leases and lease updates will be recorded. The default value for + new leases and lease updates are recorded. The default value for this parameter is ``"[kea-install-dir]/var/lib/kea/kea-leases6.csv"``. - ``lfc-interval``: specifies the interval, in seconds, at which the server will perform a lease file cleanup (LFC). This removes redundant (historical) information from the lease file and effectively reduces the lease file size. The cleanup process is - described in more detail later in this section. The - default value of the ``lfc-interval`` is ``3600``. A value of 0 - disables the LFC. + described in more detail later in this section. The default + value of the ``lfc-interval`` is ``3600``. A value of ``0`` disables the LFC. -- ``max-row-errors``: when the server loads a lease file, it is processed +- ``max-row-errors``: specifies the number of row errors before the server + stops attempting to load a lease file. When the server loads a lease file, it is processed row by row, each row containing a single lease. If a row is flawed and - cannot be processed correctly the server will log it, discard the row, - and go on to the next row. This parameter can be used to set a limit on - the number of such discards that may occur after which the server will - abandon the effort and exit. The default value of 0 disables the limit + cannot be processed correctly the server logs it, discards the row, + and goes on to the next row. This parameter can be used to set a limit on + the number of such discards that can occur, after which the server + abandons the effort and exits. The default value of ``0`` disables the limit and allows the server to process the entire file, regardless of how many rows are discarded. @@ -316,25 +310,27 @@ An example configuration of the memfile } } -This configuration selects the ``/tmp/kea-leases6.csv`` as the storage +This configuration selects ``/tmp/kea-leases6.csv`` as the storage file for lease information and enables persistence (writing lease updates to this file). It also configures the backend to perform a periodic cleanup -of the lease file every 30 minutes and sets the maximum number of row -errors to 100. +of the lease file every 1800 seconds (30 minutes) and sets the maximum number of +row errors to 100. +Why Is Lease File Cleanup Necessary? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is important to know how the lease file contents are organized to understand why the periodic lease file cleanup is needed. Every time the -server updates a lease or creates a new lease for the client, the new +server updates a lease or creates a new lease for a client, the new lease information must be recorded in the lease file. For performance reasons, the server does not update the existing client's lease in the file, as this would potentially require rewriting the entire file. Instead, it simply appends the new lease information to the end of the file; the previous lease entries for the client are not removed. When -the server loads leases from the lease file, e.g. at the server startup, +the server loads leases from the lease file, e.g. at server startup, it assumes that the latest lease entry for the client is the valid one. -The previous entries are discarded, meaning that the server can -re-construct the accurate information about the leases even though there +Previous entries are discarded, meaning that the server can +reconstruct accurate information about the leases even though there may be many lease entries for each client. However, storing many entries for each client results in a bloated lease file and impairs the performance of the server's startup and reconfiguration, as it needs to @@ -349,9 +345,9 @@ however, that the LFC takes time and thu unlikely) that, if the ``lfc-interval`` is too short, a new cleanup may be started while the previous one is still running. The server would recover from this by skipping the new cleanup when it detected that the -previous cleanup was still in progress. But it implies that the actual -cleanups will be triggered more rarely than configured. Moreover, -triggering a new cleanup adds overhead to the server, which will not be +previous cleanup was still in progress, but it implies that the actual +cleanups will be triggered more rarely than the configured interval. Moreover, +triggering a new cleanup adds overhead to the server, which is not able to respond to new requests for a short period of time when the new cleanup process is spawned. Therefore, it is recommended that the ``lfc-interval`` value be selected in a way that allows the LFC @@ -359,7 +355,7 @@ to complete the cleanup before a new cle Lease file cleanup is performed by a separate process (in the background) to avoid a performance impact on the server process. To -avoid conflicts between two processes both using the same lease +avoid conflicts between two processes using the same lease files, the LFC process starts with Kea opening a new lease file; the actual LFC process operates on the lease file that is no longer used by the server. There are also other files created as a side effect of the @@ -385,8 +381,8 @@ Lease Database Configuration :ref:`pgsql-database-create`. Lease database configuration is controlled through the -Dhcp6/lease-database parameters. The database type must be set to -"memfile", "mysql", "postgresql", or "cql", e.g.: +``Dhcp6``/``lease-database`` parameters. The database type must be set to +``memfile``, ``mysql`` or ``postgresql``, e.g.: :: @@ -394,18 +390,13 @@ Dhcp6/lease-database parameters. The dat Next, the name of the database to hold the leases must be set; this is the name used when the database was created (see -:ref:`mysql-database-create`, :ref:`pgsql-database-create`, or -:ref:`cql-database-create`). - -:: - - "Dhcp6": { "lease-database": { "name": "database-name" , ... }, ... } +:ref:`mysql-database-create` or :ref:`pgsql-database-create`). -For Cassandra: +For MySQL or PostgreSQL: :: - "Dhcp6": { "lease-database": { "keyspace": "database-name" , ... }, ... } + "Dhcp6": { "lease-database": { "name": "database-name" , ... }, ... } If the database is located on a different system from the DHCPv6 server, the database host name must also be specified: @@ -414,27 +405,13 @@ the database host name must also be spec "Dhcp6": { "lease-database": { "host": "remote-host-name", ... }, ... } -(It should be noted that this configuration may have a severe impact on server performance.) - -For Cassandra, multiple contact points can be provided: - -:: - - "Dhcp6": { "lease-database": { "contact-points": "remote-host-name[, ...]" , ... }, ... } - -Normally, the database will be on the same machine as the DHCPv6 server. +Normally, the database is on the same machine as the DHCPv6 server. In this case, set the value to the empty string: :: "Dhcp6": { "lease-database": { "host" : "", ... }, ... } -For Cassandra: - -:: - - "Dhcp6": { "lease-database": { "contact-points": "", ... }, ... } - Should the database use a port other than the default, it may be specified as well: @@ -453,7 +430,7 @@ The default value of five seconds should connections. If a timeout is given, though, it should be an integer greater than zero. -The maximum number of times the server will automatically attempt to +The maximum number of times the server automatically attempts to reconnect to the lease database after connectivity has been lost may be specified: @@ -462,12 +439,12 @@ specified: "Dhcp6": { "lease-database": { "max-reconnect-tries" : number-of-tries, ... }, ... } If the server is unable to reconnect to the database after making the -maximum number of attempts, the server will exit. A value of zero (the +maximum number of attempts, the server will exit. A value of 0 (the default) disables automatic recovery and the server will exit immediately upon detecting a loss of connectivity (MySQL and PostgreSQL only). -The number of milliseconds the server will wait between attempts to +The number of milliseconds the server waits between attempts to reconnect to the lease database after connectivity has been lost may also be specified: @@ -477,7 +454,7 @@ also be specified: The default value for MySQL and PostgreSQL is 0, which disables automatic recovery and causes the server to exit immediately upon detecting the -loss of connectivity. The default value for Cassandra is 2000 ms. +loss of connectivity. :: @@ -485,43 +462,35 @@ loss of connectivity. The default value The possible values are: -- ``stop-retry-exit`` disables the DHCP service while trying to automatically +- ``stop-retry-exit`` - disables the DHCP service while trying to automatically recover lost connections. Shuts down the server on failure after exhausting ``max-reconnect-tries``. This is the default value for MySQL and PostgreSQL. -- ``serve-retry-exit`` DHCP service continues while trying to automatically +- ``serve-retry-exit`` - continues the DHCP service while trying to automatically recover lost connections. Shuts down the server on failure after exhausting ``max-reconnect-tries``. -- ``serve-retry-continue`` DHCP service continues and does not shut down the +- ``serve-retry-continue`` - continues the DHCP service and does not shut down the server even if the recovery fails. .. note:: Automatic reconnection to database backends is configured individually per - backend. This allows users to tailor the recovery parameters to each backend - they use. We do suggest that users enable it either for all backends or none, + backend; this allows users to tailor the recovery parameters to each backend + they use. We suggest that users enable it either for all backends or none, so behavior is consistent. - Losing connectivity to a backend for which reconnect is disabled will result + + Losing connectivity to a backend for which reconnection is disabled results (if configured) in the server shutting itself down. This includes cases when the lease database backend and the hosts database backend are connected to the same database instance. - It is highly recommended to not change the ``stop-retry-exit`` default - setting for the lease manager as it is critical for the connection to be + + It is highly recommended not to change the ``stop-retry-exit`` default + setting for the lease manager, as it is critical for the connection to be active while processing DHCP traffic. Change this only if the server is used exclusively as a configuration tool. -.. - -.. note:: - - Note that the host parameter is used by the MySQL and PostgreSQL backends. - Cassandra has a concept of contact points that can be used to - contact the cluster, instead of a single IP or hostname. It takes a - list of comma-separated IP addresses, which may be specified as: - :: - - "Dhcp6": { "lease-database": { "contact-points" : "192.0.2.1,192.0.2.2", ... }, ... } +The host parameter is used by the MySQL and PostgreSQL backends. Finally, the credentials of the account under which the server will access the database should be set: @@ -534,15 +503,7 @@ access the database should be set: ... } If there is no password to the account, set the password to the empty -string "". (This is also the default.) - -.. _cassandra-database-configuration6: - -Cassandra-Specific Parameters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The parameters are the same for both DHCPv4 and DHCPv6. See -:ref:`cassandra-database-configuration4` for details. +string ``""``. (This is the default.) .. _hosts6-storage: @@ -551,13 +512,13 @@ Hosts Storage Kea is also able to store information about host reservations in the database. The hosts database configuration uses the same syntax as the -lease database. In fact, a Kea server opens independent connections for -each purpose, be it lease or hosts information. This arrangement gives +lease database. In fact, the Kea server opens independent connections for +each purpose, be it lease or hosts information, which gives the most flexibility. Kea can keep leases and host reservations separately, but can also point to the same database. Currently the -supported hosts database types are MySQL, PostgreSQL, and Cassandra. +supported hosts database types are MySQL and PostgreSQL. -For example, the following configuration can be used to configure a +The following configuration can be used to configure a connection to MySQL: :: @@ -573,22 +534,22 @@ connection to MySQL: } } -Note that depending on the database configuration, many of the +Depending on the database configuration, many of the parameters may be optional. Please note that usage of hosts storage is optional. A user can define all host reservations in the configuration file, and that is the recommended way if the number of reservations is small. However, when the number of reservations grows, it is more convenient to use host -storage. Please note that both storage methods (configuration file and +storage. Please note that both storage methods (the configuration file and one of the supported databases) can be used together. If hosts are defined in both places, the definitions from the configuration file are checked first and external storage is checked later, if necessary. -In fact, host information can be placed in multiple stores. Operations +Host information can be placed in multiple stores. Operations are performed on the stores in the order they are defined in the -configuration file, although this leads to a restriction in ordering in -the case of a host reservation addition; read-only stores must be +configuration file, although this leads to a restriction in ordering +in the case of a host reservation addition; read-only stores must be configured after a (required) read-write store, or the addition will fail. @@ -604,8 +565,8 @@ DHCPv6 Hosts Database Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hosts database configuration is controlled through the -Dhcp6/hosts-database parameters. If enabled, the type of database must -be set to "mysql" or "postgresql". +``Dhcp6``/``hosts-database`` parameters. If enabled, the type of database must +be set to ``mysql`` or ``postgresql``. :: @@ -627,20 +588,21 @@ the database host name must also be spec "Dhcp6": { "hosts-database": { "host": remote-host-name, ... }, ... } -(Again, it should be noted that this configuration may have a severe impact on server performance.) - -Normally, the database will be on the same machine as the DHCPv6 server. +Normally, the database is on the same machine as the DHCPv6 server. In this case, set the value to the empty string: :: "Dhcp6": { "hosts-database": { "host" : "", ... }, ... } +Should the database use a port different than the default, it may be +specified as well: + :: "Dhcp6": { "hosts-database": { "port" : 12345, ... }, ... } -The maximum number of times the server will automatically attempt to +The maximum number of times the server automatically attempts to reconnect to the host database after connectivity has been lost may be specified: @@ -649,14 +611,12 @@ specified: "Dhcp6": { "hosts-database": { "max-reconnect-tries" : number-of-tries, ... }, ... } If the server is unable to reconnect to the database after making the -maximum number of attempts, the server will exit. A value of zero (the +maximum number of attempts, the server will exit. A value of 0 (the default) disables automatic recovery and the server will exit immediately upon detecting a loss of connectivity (MySQL and PostgreSQL -only). For Cassandra, Kea uses a Cassandra interface that connects to -all nodes in a cluster at the same time. Any connectivity issues should -be handled by internal Cassandra mechanisms. +only). -The number of milliseconds the server will wait between attempts to +The number of milliseconds the server waits between attempts to reconnect to the host database after connectivity has been lost may also be specified: @@ -666,7 +626,7 @@ be specified: The default value for MySQL and PostgreSQL is 0, which disables automatic recovery and causes the server to exit immediately upon detecting the -loss of connectivity. The default value for Cassandra is 2000 ms. +loss of connectivity. :: @@ -674,24 +634,25 @@ loss of connectivity. The default value The possible values are: -- ``stop-retry-exit`` disables the DHCP service while trying to automatically +- ``stop-retry-exit`` - disables the DHCP service while trying to automatically recover lost connections. Shuts down the server on failure after exhausting ``max-reconnect-tries``. This is the default value for MySQL and PostgreSQL. -- ``serve-retry-exit`` DHCP service continues while trying to automatically +- ``serve-retry-exit`` - continues the DHCP service while trying to automatically recover lost connections. Shuts down the server on failure after exhausting ``max-reconnect-tries``. -- ``serve-retry-continue`` DHCP service continues and does not shut down the +- ``serve-retry-continue`` - continues the DHCP service and does not shut down the server even if the recovery fails. .. note:: Automatic reconnection to database backends is configured individually per backend. This allows users to tailor the recovery parameters to each backend - they use. We do suggest that users enable it either for all backends or none, + they use. We suggest that users enable it either for all backends or none, so behavior is consistent. - Losing connectivity to a backend for which reconnect is disabled will result + + Losing connectivity to a backend for which reconnection is disabled results (if configured) in the server shutting itself down. This includes cases when the lease database backend and the hosts database backend are connected to the same database instance. @@ -707,19 +668,16 @@ access the database should be set: ... } If there is no password to the account, set the password to the empty -string "". (This is also the default.) +string ``""``. (This is the default.) -The multiple storage extension uses a similar syntax; a configuration is -placed into a "hosts-databases" list instead of into a "hosts-database" +The multiple-storage extension uses a similar syntax; a configuration is +placed into a ``hosts-databases`` list instead of into a ``hosts-database`` entry, as in: :: "Dhcp6": { "hosts-databases": [ { "type": "mysql", ... }, ... ], ... } -For additional Cassandra-specific parameters, see -:ref:`cassandra-database-configuration4`. - If the same host is configured both in-file and in-database, Kea does not issue a warning, as it would if both were specified in the same data source. Instead, the host configured in-file has priority over the one configured @@ -730,7 +688,7 @@ in-database. Using Read-Only Databases for Host Reservations with DHCPv6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In some deployments the database user whose name is specified in the +In some deployments, the user whose name is specified in the database backend configuration may not have write privileges to the database. This is often required by the policy within a given network to secure the data from being unintentionally modified. In many cases @@ -740,8 +698,8 @@ reservations assigned to them. The inven create a view of a Kea hosts database and such a view is often read-only. -Kea host database backends operate with an implicit configuration to -both read from and write to the database. If the database user does not +Kea host-database backends operate with an implicit configuration to +both read from and write to the database. If the user does not have write access to the host database, the backend will fail to start and the server will refuse to start (or reconfigure). However, if access to a read-only host database is required for retrieving reservations @@ -759,7 +717,7 @@ the parameter is not specified. .. note:: - The ``readonly`` parameter is currently only supported for MySQL and + The ``readonly`` parameter is only supported for MySQL and PostgreSQL databases. .. _dhcp6-interface-configuration: @@ -794,7 +752,7 @@ interface names: } -It is possible to use a wildcard interface name (asterisk) concurrently +It is possible to use an interface wildcard (*) concurrently with explicit interface names: :: @@ -806,15 +764,14 @@ with explicit interface names: ... } - -It is anticipated that this form of usage will only be used when it is +This format should only be used when it is desired to temporarily override a list of interface names and listen on all interfaces. As with the DHCPv4 server, binding to specific addresses and disabling re-detection of interfaces are supported. But ``dhcp-socket-type`` is -not supported, because DHCPv6 uses UDP/IPv6 sockets only. The following example -shows how to disable the interface detection: +not supported, because DHCPv6 uses only UDP/IPv6 sockets. The following example +shows how to disable interface detection: :: @@ -827,7 +784,7 @@ shows how to disable the interface detec } -The loopback interfaces (i.e. the "lo" or "lo0" interface) are not +The loopback interfaces (i.e. the ``lo`` or ``lo0`` interface) are not configured by default, unless explicitly mentioned in the configuration. Note that Kea requires a link-local address (which does not exist on all systems) or a specified unicast address, as in: @@ -841,18 +798,61 @@ not exist on all systems) or a specified ... } +Kea binds the service sockets for each interface on startup. If another +process is already using a port, then Kea logs the message and suppresses an +error. DHCP service runs, but it is unavailable on some interfaces. + +The "service-sockets-require-all" option makes Kea require all sockets to +be successfully bound. If any opening fails, Kea interrupts the +initialization and exits with a non-zero status. (Default is false). + +:: + + "Dhcp6": { + "interfaces-config": { + "interfaces": [ "eth1", "eth3" ], + "service-sockets-require-all": true + }, + ... + } + +Sometimes, immediate interruption isn't a good choice. The port can be +unavailable only temporary. In this case, retrying the opening may resolve +the problem. Kea provides two options to specify the retrying: +``service-sockets-max-retries`` and ``service-sockets-retry-wait-time``. + +The first defines a maximal number of retries that Kea makes to open a socket. +The zero value (default) means that the Kea doesn't retry the process. + +The second defines a wait time (in milliseconds) between attempts. The default +value is 5000 (5 seconds). + +:: + + "Dhcp6": { + "interfaces-config": { + "interfaces": [ "eth1", "eth3" ], + "service-sockets-max-retries": 5, + "service-sockets-retry-wait-time": 5000 + }, + ... + } + +If "service-sockets-max-retries" is non-zero and "service-sockets-require-all" +is false, then Kea retries the opening (if needed) but does not fail if any +socket is still not opened. .. _ipv6-subnet-id: IPv6 Subnet Identifier ---------------------- -The subnet identifier is a unique number associated with a particular +The subnet identifier (subnet ID) is a unique number associated with a particular subnet. In principle, it is used to associate clients' leases with their respective subnets. When a subnet identifier is not specified for a -subnet being configured, it will be automatically assigned by the -configuration mechanism. The identifiers are assigned from 1 and are -monotonically increased for each subsequent subnet: 1, 2, 3 .... +subnet being configured, it is automatically assigned by the +configuration mechanism. The identifiers are assigned starting at 1 and are +monotonically increased for each subsequent subnet: 1, 2, 3, .... If there are multiple subnets configured with auto-generated identifiers and one of them is removed, the subnet identifiers may be renumbered. @@ -867,7 +867,7 @@ manually specify a unique identifier for Subnet IDs must be greater than zero and less than 4294967295. -The following configuration will assign the specified subnet identifier +The following configuration assigns the specified subnet identifier to a newly configured subnet: :: @@ -882,7 +882,7 @@ to a newly configured subnet: ] } -This identifier will not change for this subnet unless the "id" +This identifier will not change for this subnet unless the ``id`` parameter is removed or set to 0. The value of 0 forces auto-generation of the subnet identifier. @@ -891,8 +891,8 @@ of the subnet identifier. IPv6 Subnet Prefix ------------------ -The subnet prefix is the second way to identify a subnet. It does not -need to have the address part to match the prefix length, for instance +The subnet prefix is the second way to identify a subnet. Kea can +accept non-canonical subnet addresses; for instance, this configuration is accepted: :: @@ -906,7 +906,7 @@ this configuration is accepted: ] } -Even there is another subnet with the "2001:db8:1::/64" prefix: +This works even if there is another subnet with the "2001:db8:1::/64" prefix; only the textual form of subnets are compared to avoid duplicates. .. note:: @@ -925,12 +925,12 @@ configured to listen on (see :ref:`dhcp6 useful to configure a server to handle incoming traffic sent to global unicast addresses as well; the most common reason for this is to have relays send their traffic to the server directly. To configure the -server to listen on a specific unicast address, add a slash after the interface name, +server to listen on a specific unicast address, add a slash (/) after the interface name, followed by the global unicast address on which the server should listen. The server will listen to this address in addition to normal link-local binding and listening on the ff02::1:2 address. The sample configuration below shows how to listen on -2001:db8::1 (a global address) configured on the eth1 interface. +2001:db8::1 (a global address) configured on the ``eth1`` interface. :: @@ -948,21 +948,21 @@ ff02::1:2 address. The sample configurat } -This configuration will cause the server to listen on eth1 on the +This configuration will cause the server to listen on ``eth1`` on the link-local address, the multicast group (ff02::1:2), and 2001:db8::1. -Usually unicast support is associated with a server unicast option which +Usually, unicast support is associated with a server unicast option which allows clients to send unicast messages to the server. The example above -includes a server unicast option specification which will cause the +includes a server unicast option specification which causes the client to send messages to the specified unicast address. It is possible to mix interface names, wildcards, and interface names/addresses in the list of interfaces. It is not possible, however, to specify more than one unicast address on a given interface. -Care should be taken to specify proper unicast addresses. The server +Care should be taken to specify proper unicast addresses, as the server will attempt to bind to the addresses specified without any additional -checks. This approach was selected on purpose, to allow the software to +checks. This approach was selected intentionally, to allow the software to communicate over uncommon addresses if so desired. .. _dhcp6-address-config: @@ -974,8 +974,8 @@ The main role of a DHCPv6 server is addr server must be configured with at least one subnet and one pool of dynamic addresses to be managed. For example, assume that the server is connected to a network segment that uses the 2001:db8:1::/64 prefix. The -administrator of that network decides that addresses from range -2001:db8:1::1 to 2001:db8:1::ffff are going to be managed by the Dhcp6 +administrator of that network decides that addresses from the range +2001:db8:1::1 to 2001:db8:1::ffff are going to be managed by the DHCPv6 server. Such a configuration can be achieved in the following way: :: @@ -1006,10 +1006,10 @@ gives the range of addresses in the pool It is possible to define more than one pool in a subnet; continuing the previous example, further assume that 2001:db8:1:0:5::/80 should also be managed by the server. It could be written as 2001:db8:1:0:5:: to -2001:db8:1::5:ffff:ffff:ffff, but typing so many 'f's is cumbersome. It +2001:db8:1::5:ffff:ffff:ffff, but typing so many ``f``s is cumbersome. It can be expressed more simply as 2001:db8:1:0:5::/80. Both formats are -supported by Dhcp6 and can be mixed in the pool list. For example, one -could define the following pools: +supported by ``Dhcp6`` and can be mixed in the pool list. For example, +the following pools could be defined: :: @@ -1064,10 +1064,10 @@ danger in using gigantic address pools. When configuring a DHCPv6 server using prefix/length notation, please pay attention to the boundary values. When specifying that the server -can use a given pool, it will also be able to allocate the first +can use a given pool, it is also able to allocate the first (typically a network address) address from that pool. For example, for pool 2001:db8:2::/64, the 2001:db8:2:: address may be assigned as well. -To avoid this, use the "min-max" notation. +To avoid this, use the ``min-max`` notation. .. _dhcp6-prefix-config: @@ -1079,8 +1079,8 @@ Subnets may also be configured to delega have one or more prefix delegation pools. Each pool has a prefixed address, which is specified as a prefix (``prefix``) and a prefix length (``prefix-len``), as well as a delegated prefix length -(``delegated-len``). The delegated length must not be shorter than (that -is, it must be numerically greater than or equal to) the prefix length. +(``delegated-len``). The delegated length must not be shorter than +(i.e. it must be numerically greater than or equal to) the prefix length. If both the delegated and prefix lengths are equal, the server will be able to delegate only one prefix. The delegated prefix does not have to match the subnet prefix. @@ -1114,12 +1114,12 @@ Prefix Exclude Option For each delegated prefix, the delegating router may choose to exclude a single prefix out of the delegated prefix as specified in `RFC 6603 `__. The requesting router must -not assign the excluded prefix to any of its downstream interfaces, and -it is intended to be used on a link through which the delegating router +not assign the excluded prefix to any of its downstream interfaces. +The excluded prefix is intended to be used on a link through which the delegating router exchanges DHCPv6 messages with the requesting router. The configuration example below demonstrates how to specify an excluded prefix within a prefix pool definition. The excluded prefix -"2001:db8:1:8000:cafe:80::/72" will be sent to a requesting router which +``2001:db8:1:8000:cafe:80::/72`` will be sent to a requesting router which includes the Prefix Exclude option in the Option Request option (ORO), and which is delegated a prefix from this pool. @@ -1142,6 +1142,42 @@ and which is delegated a prefix from thi ] } +.. note:: + + Here are some liberties and limits to the values that subnets and pools can + take in Kea configurations that are out of the ordinary: + + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Kea configuration case | Allowed | Comment | + +===============================================================================+=========+====================================================================================+ + | Overlapping subnets | Yes | Administrator consideration needs to be given to how clients are matched to | + | | | these subnets. | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Overlapping address pools in one subnet | No | Startup error: DHCP6_PARSER_FAIL | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Overlapping address pools in different subnets | Yes | Specifying the same address pool in different subnets can be used as an equivalent | + | | | of the global address pool. In that case, the server can assign addresses from the | + | | | same range regardless of the client's subnet. If an address from such a pool is | + | | | assigned to a client in one subnet, the same address will be renewed for this | + | | | client if it moves to another subnet. Another client in a different subnet will | + | | | not be assigned an address already assigned to the client in any of the subnets. | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Address pools that are outside the subnet they are configured under | No | Startup error: DHCP6_PARSER_FAIL | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Overlapping prefix delegation pools in one subnet | No | Startup error: DHCP6_PARSER_FAIL | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Overlapping prefix delegation pools in different subnets | Yes | Specifying the same prefix delegation pool in different subnets can be used as an | + | | | equivalent of the global pool. In that case, the server can delegate the same | + | | | prefixes regardless of the client's subnet. If a prefix from such a pool is | + | | | delegated to a client in one subnet, the same prefix will be renewed for this | + | | | client if it moves to another subnet. Another client in a different subnet will | + | | | not be delegated a prefix already delegated to the client in any of the subnets. | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + | Prefix delegation pools not matching the subnet prefix | Yes | It is common in many deployments to configure the prefix delegation pools not | + | | | matching the subnet prefix, e.g. a prefix pool of 3000::/96 within the | + | | | 2001:db8:1::/64 subnet. Such use cases are supported by Kea DHCPv6 server. | + +-------------------------------------------------------------------------------+---------+------------------------------------------------------------------------------------+ + .. _dhcp6-std-options: Standard DHCPv6 Options @@ -1176,7 +1212,7 @@ option name. (For a complete list of cur :ref:`dhcp6-std-options-list`.) The next line specifies the option code, which must match one of the values from that list. The line beginning with ``space`` specifies the option space, which must always -be set to "dhcp6" as these are standard DHCPv6 options. For other name +be set to ``dhcp6`` as these are standard DHCPv6 options. For other name spaces, including custom option spaces, see :ref:`dhcp6-option-spaces`. The following line specifies the format in which the data will be entered; use of CSV (comma-separated values) is recommended. Finally, the ``data`` line @@ -1184,10 +1220,10 @@ gives the actual value to be sent to cli normal text, with values separated by commas if more than one value is allowed. -Options can also be configured as hexadecimal values. If "csv-format" is -set to false, the option data must be specified as a hexadecimal string. -The following commands configure the DNS-SERVERS option for all subnets -with the following addresses: 2001:db8:1::cafe and 2001:db8:1::babe. +Options can also be configured as hexadecimal values. If ``csv-format`` is +set to ``false``, the option data must be specified as a hexadecimal string. +The following commands configure the ``dns-servers`` option for all subnets +with the addresses 2001:db8:1::cafe and 2001:db8:1::babe. :: @@ -1205,19 +1241,16 @@ with the following addresses: 2001:db8:1 ] } - -.. - .. note:: - The value for the setting of the "data" element is split across two + The value for the setting of the ``data`` element is split across two lines in this example for clarity; when entering the command, the whole string should be entered on the same line. Kea supports the following formats when specifying hexadecimal data: - ``Delimited octets`` - one or more octets separated by either colons or - spaces (':' or ' '). While each octet may contain one or two digits, + spaces (":" or " "). While each octet may contain one or two digits, we strongly recommend always using two digits. Valid examples are "ab:cd:ef" and "ab cd ef". @@ -1228,9 +1261,9 @@ Care should be taken to use proper encod format; Kea's ability to validate data correctness in hexadecimal is limited. -As of Kea 1.6.0, it is also possible to specify data for binary options as -a single-quoted text string within double quotes as shown (note that -``csv-format`` must be set to false): +It is also possible to specify data for binary options as +a single-quoted text string within double quotes, as shown (note that +``csv-format`` must be set to ``false``): :: @@ -1248,12 +1281,12 @@ a single-quoted text string within doubl ... } -Most of the parameters in the "option-data" structure are optional and +Most of the parameters in the ``option-data`` structure are optional and can be omitted in some circumstances, as discussed in :ref:`dhcp6-option-data-defaults`. -Only one of name or code +Only one of ``name`` or ``code`` is required; it is not necessary to specify both. Space has a default value -of "dhcp6", so this can be skipped as well if a regular (not -encapsulated) DHCPv6 option is defined. Finally, csv-format defaults to "true", so it +of ``dhcp6``, so this can be skipped as well if a regular (not +encapsulated) DHCPv6 option is defined. Finally, ``csv-format`` defaults to ``true``, so it too can be skipped, unless the option value is specified as hexstring. Therefore, the above example can be simplified to: @@ -1274,7 +1307,7 @@ Defined options are added to the respons as well as any options required by a protocol. An administrator can also specify that an option is always sent, even if a client did not specifically request it. To enforce the addition of a particular option, -set the "always-send" flag to true as in: +set the ``always-send`` flag to ``true``, as in: :: @@ -1291,7 +1324,7 @@ set the "always-send" flag to true as in The effect is the same as if the client added the option code in the -Option Request option (or its equivalent for vendor options), as in: +Option Request Option (or its equivalent for vendor options), as in: :: @@ -1322,7 +1355,7 @@ Option Request option (or its equivalent } -The DNS servers option is always added to responses (the always-send is +The ``dns-servers`` option is always added to responses (the always-send is "sticky"), but the value is the subnet one when the client is localized in the subnet. @@ -1333,7 +1366,7 @@ specific values for a small number of su different values are used in each subnet, it does not make sense to specify global option values; rather, only subnet-specific ones should be set. -The following commands override the global DNS servers option for a +The following commands override the global ``dns-servers`` option for a particular subnet, setting a single DNS server with address 2001:db8:1::3. @@ -1362,16 +1395,16 @@ particular subnet, setting a single DNS In some cases it is useful to associate some options with an address or prefix pool from which a client is assigned a lease. Pool-specific option values override subnet-specific and global option values. If the -client is assigned multiple leases from different pools, the server will -assign options from all pools from which the leases have been obtained. +client is assigned multiple leases from different pools, the server +assigns options from all pools from which the leases have been obtained. However, if the particular option is specified in multiple pools from which the client obtains the leases, only one instance of this option -will be handed out to the client. The server's administrator must not +is handed out to the client. The server's administrator must not try to prioritize assignment of pool-specific options by trying to order -pools declarations in the server configuration. +pool declarations in the server configuration. -The following configuration snippet demonstrates how to specify the DNS -servers option, which will be assigned to a client only if the client +The following configuration snippet demonstrates how to specify the +``dns-servers`` option, which will be assigned to a client only if the client obtains an address from the given pool: :: @@ -1396,21 +1429,15 @@ obtains an address from the given pool: ... } -Options can also be specified in class or host reservation scope. The +Options can also be specified in class or host-reservation scope. The current Kea options precedence order is (from most important): host reservation, pool, subnet, shared network, class, global. -The currently supported standard DHCPv6 options are listed in -:ref:`dhcp6-std-options-list`. "Name" and "Code" are the -values that should be used as a name/code in the option-data structures. -"Type" designates the format of the data; the meanings of the various -types are given in :ref:`dhcp-types`. - -When a data field is a string and that string contains the comma (,; -U+002C) character, the comma must be escaped with two backslashes (\; +When a data field is a string and that string contains the comma (``,``; +U+002C) character, the comma must be escaped with two backslashes (``\\,``; U+005C). This double escape is required because both the routine splitting CSV data into fields and JSON use the same escape character; a -single escape (\,) would make the JSON invalid. For example, the string +single escape (``\,``) would make the JSON invalid. For example, the string "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00" must be represented as: :: @@ -1437,7 +1464,7 @@ single escape (\,) would make the JSON i } Some options are designated as arrays, which means that more than one -value is allowed in such an option. For example, the option dns-servers +value is allowed. For example, the option ``dns-servers`` allows the specification of more than one IPv6 address, enabling clients to obtain the addresses of multiple DNS servers. @@ -1445,17 +1472,23 @@ to obtain the addresses of multiple DNS configuration syntax to create custom option definitions (formats). Creation of custom definitions for standard options is generally not permitted, even if the definition being created matches the actual -option format defined in the RFCs. There is an exception to this rule +option format defined in the RFCs. However, there is an exception to this rule for standard options for which Kea currently does not provide a -definition. In order to use such options, a server administrator must -create a definition as described in :ref:`dhcp6-custom-options` in the 'dhcp6' option space. This +definition. To use such options, a server administrator must +create a definition as described in :ref:`dhcp6-custom-options` in the ``dhcp6`` option space. This definition should match the option format described in the relevant RFC, -but the configuration mechanism will allow any option format as it -currently has no means to validate it. +but the configuration mechanism allows any option format as there is +currently no way to validate it. + +The currently supported standard DHCPv6 options are listed in +the table below. "Name" and "Code" are the +values that should be used as a name/code in the option-data structures. +"Type" designates the format of the data; the meanings of the various +types are given in :ref:`dhcp-types`. .. _dhcp6-std-options-list: -.. table:: List of Standard DHCPv6 Options configurable by an administrator +.. table:: List of standard DHCPv6 options configurable by an administrator +--------------------------+-----------------+-----------------+-----------------+ | Name | Code | Type | Array? | @@ -1596,7 +1629,7 @@ processing, the support for those option may be useful in some limited lab testing; hence the definition formats are listed here. -Kea supports more options than the listed above. The following list is mostly useful for readers who +Kea supports more options than those listed above. The following list is mostly useful for readers who want to understand whether Kea is able to support certain options. The following options are returned by the Kea engine itself and in general should not be configured manually. @@ -1605,61 +1638,61 @@ returned by the Kea engine itself and in +--------------+------+------------------------------------------------------------------------+ | Name | Code | Description | +==============+======+========================================================================+ - | client-id | 1 | sent by the client and Kea uses it to distinguish between clients. | + | client-id | 1 | Sent by the client; Kea uses it to distinguish between clients. | +--------------+------+------------------------------------------------------------------------+ - | server-id | 2 | sent by clients to request action from a specific server and by the | + | server-id | 2 | Sent by clients to request action from a specific server and by the | | | | server to identify itself. See :ref:`dhcp6-serverid` for details. | +--------------+------+------------------------------------------------------------------------+ - | ia-na | 3 | a container option that conveys IPv6 addresses (``iaddr`` options). Kea| + | ia-na | 3 | A container option that conveys IPv6 addresses (``iaddr`` options). Kea| | | | receives and sends those options using its allocation engine. | +--------------+------+------------------------------------------------------------------------+ - | ia-ta | 4 | conveys temporary addresses. Deprecated feature, not supported. | + | ia-ta | 4 | Conveys temporary addresses. Deprecated feature, not supported. | +--------------+------+------------------------------------------------------------------------+ - | iaaddr | 5 | conveys addresses with lifetimes in ``ia-na`` and ``ia-ta`` options. | + | iaaddr | 5 | Conveys addresses with lifetimes in ``ia-na`` and ``ia-ta`` options. | +--------------+------+------------------------------------------------------------------------+ - | oro | 6 | ORO (or Option Request Option) is used by the clients to request a list| - | | | of options they are interested in. Kea supports it and will send the | + | oro | 6 | ORO (or Option Request Option) is used by clients to request a list | + | | | of options they are interested in. Kea supports it and sends the | | | | requested options back if configured with required options. | +--------------+------+------------------------------------------------------------------------+ - | elapsed-time | 8 | sent by the clients to identify how long they're trying to obtain a | + | elapsed-time | 8 | Sent by clients to identify how long they have been trying to obtain a | | | | configuration. Kea uses high values sent by clients as an indicator | - | | | that something is wrong and this is one of the aspects used in HA to | + | | | that something is wrong; this is one of the aspects used in HA to | | | | determine if the partner is healthy or not. | +--------------+------+------------------------------------------------------------------------+ - | relay-msg | 9 | used by relays to encapsulate the original client message. Kea uses it | + | relay-msg | 9 | Used by relays to encapsulate the original client message. Kea uses it | | | | when sending back relayed responses to the relay agent. | +--------------+------+------------------------------------------------------------------------+ - | auth | 10 | used to pass authentication information between clients and server. The| + | auth | 11 | Used to pass authentication information between clients and server. The| | | | support for this option is very limited. | +--------------+------+------------------------------------------------------------------------+ - | status-code | 13 | an option that the server can attach in case of various failures, such | + | status-code | 13 | An option that the server can attach in case of various failures, such | | | | as running out of addresses or not being configured to assign prefixes.| +--------------+------+------------------------------------------------------------------------+ - | rapid-commit | 14 | used to signal client's willingness to support ``rapid-commit`` and | - | | | server's acceptance for this configuration. See | + | rapid-commit | 14 | Used to signal the client's willingness to support ``rapid-commit`` and| + | | | the server's acceptance for this configuration. See | | | | :ref:`dhcp6-rapid-commit` for details. | +--------------+------+------------------------------------------------------------------------+ - | user-class | 15 | sent by the client to self-identify what kind of device type it is. Kea| + | user-class | 15 | Sent by the client to self-identify the device type. Kea | | | | can use this for client classification. | +--------------+------+------------------------------------------------------------------------+ - | vendor-class | 16 | similar to ``user-class``, but it is vendor specific. | + | vendor-class | 16 | Similar to ``user-class``, but vendor-specific. | +--------------+------+------------------------------------------------------------------------+ - | vendor-opts | 17 | a vendor specific container that is used by both the client and the | - | | | server to exchange vendor specific options. The logic behind those | - | | | options vary between vendors. The vendor options are explained in | + | vendor-opts | 17 | A vendor-specific container that is used by both the client and the | + | | | server to exchange vendor-specific options. The logic behind those | + | | | options varies between vendors. Vendor options are explained in | | | | :ref:`dhcp6-vendor-opts`. | +--------------+------+------------------------------------------------------------------------+ - | interface-id | 18 | may be inserted by the relay agent to identify the interface that the | + | interface-id | 18 | May be inserted by the relay agent to identify the interface that the | | | | original client message was received on. Kea may be told to use this | - | | | information to select specific subnets. Also, if specified, Kea will | - | | | echo this option back, so the relay will know which interface to use to| - | | | reach the client. | + | | | information to select specific subnets. Also, if specified, Kea | + | | | echoes this option back, so the relay will know which interface to use | + | | | to reach the client. | +--------------+------+------------------------------------------------------------------------+ - | ia-pd | 25 | a container for conveying PDs (Prefix Delegation) that are being | + | ia-pd | 25 | A container for conveying Prefix Delegations (PDs)) that are being | | | | delegated to clients. See :ref:`dhcp6-prefix-config` for details. | +--------------+------+------------------------------------------------------------------------+ - | iaprefix | 26 | conveys IPv6 prefix in ``ia-pd`` option. See :ref:`dhcp6-prefix-config`| - | | | for details. | + | iaprefix | 26 | Conveys the IPv6 prefix in the ``ia-pd`` option. See | + | | | :ref:`dhcp6-prefix-config` for details. | +--------------+------+------------------------------------------------------------------------+ .. _s46-options: @@ -1667,8 +1700,8 @@ returned by the Kea engine itself and in Common Softwire46 Options ------------------------- -Softwire46 options are involved in IPv4 over IPv6 provisioning by means -of tunneling or translation as specified in `RFC +Softwire46 options are involved in IPv4-over-IPv6 provisioning by means +of tunneling or translation, as specified in `RFC 7598 `__. The following sections provide configuration examples of these options. @@ -1700,18 +1733,18 @@ server configuration as shown below: } This configuration will cause the server to include the MAP-E Container -option to the client. Use "s46-cont-mapt" or "s46-cont-lw" for the MAP-T +option to the client. Use ``s46-cont-mapt`` or ``s46-cont-lw`` for the MAP-T Container and S46 Lightweight 4over6 Container options, respectively. -All remaining Softwire options described below are included in one of +All remaining Softwire46 options described below are included in one of the container options. Thus, they must be included in appropriate -option spaces by selecting a "space" name, which specifies in which -option they are supposed to be included. +option spaces by selecting a ``space`` name, which specifies the +option where they are supposed to be included. S46 Rule Option ~~~~~~~~~~~~~~~ -The S46 Rule option is used for conveying the Basic Mapping Rule (BMR) +The S46 Rule option is used to convey the Basic Mapping Rule (BMR) and Forwarding Mapping Rule (FMR). :: @@ -1722,7 +1755,7 @@ and Forwarding Mapping Rule (FMR). "data": "128, 0, 24, 192.0.2.0, 2001:db8:1::/64" } -Another possible "space" value is "s46-cont-mapt-options". +Another possible ``space`` value is ``s46-cont-mapt-options``. The S46 Rule option conveys a number of parameters: @@ -1733,18 +1766,18 @@ The S46 Rule option conveys a number of - ``ea-len`` - an 8-bit-long Embedded Address length. Allowed values range from 0 to 48. -- ``IPv4 prefix length`` - 8 bits long; expresses the prefix length of - the Rule IPv4 prefix specified in the ipv4-prefix field. Allowed +- ``IPv4 prefix length`` - an 8-bit-long expression of the prefix length of + the Rule IPv4 prefix specified in the ``ipv4-prefix`` field. Allowed values range from 0 to 32. - ``IPv4 prefix`` - a fixed-length 32-bit field that specifies the IPv4 prefix for the S46 rule. The bits in the prefix after - a specific number of bits (defined in prefix4-len) are reserved, and MUST + a specific number of bits (defined in ``prefix4-len``) are reserved, and MUST be initialized to zero by the sender and ignored by the receiver. -- ``IPv6 prefix`` - in prefix/length notation that specifies the IPv6 +- ``IPv6 prefix`` - a field in prefix/length notation that specifies the IPv6 domain prefix for the S46 rule. The field is padded on the right with - zero bits up to the nearest octet boundary, when prefix6-len is not + zero bits up to the nearest octet boundary, when ``prefix6-len`` is not evenly divisible by 8. S46 BR Option @@ -1762,7 +1795,7 @@ permitted in the MAP-T and S46 Lightweig "data": "2001:db8:cafe::1", } -Another possible "space" value is "s46-cont-lw-options". +Another possible ``space`` value is ``s46-cont-lw-options``. S46 DMR Option ~~~~~~~~~~~~~~ @@ -1803,7 +1836,7 @@ S46 Port Parameters ~~~~~~~~~~~~~~~~~~~ The S46 Port Parameters option specifies optional port-set information -that MAY be provided to CEs. +that may be provided to CEs. :: @@ -1813,12 +1846,12 @@ that MAY be provided to CEs. "data": "2, 3/4", } -Another possible "space" value is "s46-v4v6bind", to include this option +Another possible ``space`` value is ``s46-v4v6bind``, to include this option in the S46 IPv4/IPv6 Address Binding option. Note that the second value in the example above specifies the PSID and PSID-length fields in the format of PSID/PSID length. This is equivalent -to the values of PSID-len=4 and PSID=12288 conveyed in the S46 Port +to the values of ``PSID-len=4`` and ``PSID=12288`` conveyed in the S46 Port Parameters option. .. _dhcp6-custom-options: @@ -1827,9 +1860,9 @@ Custom DHCPv6 Options --------------------- Kea supports custom (non-standard) DHCPv6 options. -Assume that we want to define a new DHCPv6 option called "foo" which -will have code 100 and which will convey a single, unsigned, 32-bit -integer value. We can define such an option by putting the following entry +Let's say that we want to define a new DHCPv6 option called ``foo``, which +will have code 100 and will convey a single, unsigned, 32-bit +integer value. Such an option can be defined by putting the following entry in the configuration file: :: @@ -1850,22 +1883,22 @@ in the configuration file: } The ``false`` value of the ``array`` parameter determines that the option -does NOT comprise an array of "uint32" values but is, instead, a single +does NOT comprise an array of ``uint32`` values but is, instead, a single value. Two other parameters have been left blank: ``record-types`` and ``encapsulate``. The former specifies the comma-separated list of option data fields, if the option comprises a record of data fields. The ``record-types`` value should be non-empty if ``type`` is set to -"record"; otherwise it must be left blank. The latter parameter +``record``; otherwise it must be left blank. The latter parameter specifies the name of the option space being encapsulated by the particular option. If the particular option does not encapsulate any option space, the parameter should be left blank. Note that the ``option-def`` -configuration statement only defines the format of the new option and does +configuration statement only defines the format of an option and does not set its value(s). The ``name``, ``code``, and ``type`` parameters are required; all others are optional. The ``array`` default value is ``false``. The -``record-types`` and ``encapsulate`` default values are blank (i.e. ""). -The default ``space`` is "dhcp6". +``record-types`` and ``encapsulate`` default values are blank (``""``). +The default ``space`` is ``dhcp6``. Once the new option format is defined, its value is set in the same way as for a standard option. For example, the following commands set a @@ -1886,11 +1919,11 @@ global value that applies to all subnets ... } -New options can take more complex forms than simple use of primitives +New options can take more complex forms than the simple use of primitives (uint8, string, ipv6-address, etc.); it is possible to define an option comprising a number of existing primitives. -For example, assume we want to define a new option that will consist of +For example, say we want to define a new option that will consist of an IPv6 address, followed by an unsigned 16-bit integer, followed by a boolean value, followed by a text string. Such an option could be defined in the following way: @@ -1912,7 +1945,7 @@ defined in the following way: ... } -The ``type`` is set to "record" to indicate that the option contains +The ``type`` is set to ``record`` to indicate that the option contains multiple values of different types. These types are given as a comma-separated list in the ``record-types`` field and should be ones from those listed in :ref:`dhcp-types`. @@ -1940,7 +1973,7 @@ comprises a comma-separated list of valu must correspond to the types set in the ``record-types`` field of the option definition. -When ``array`` is set to ``true`` and ``type`` is set to "record", the +When ``array`` is set to ``"true"`` and ``type`` is set to ``"record"``, the last field is an array, i.e. it can contain more than one value, as in: :: @@ -1966,7 +1999,7 @@ unsigned integers. .. note:: In general, boolean values are specified as ``true`` or ``false``, - without quotes. Some specific boolean parameters may accept also + without quotes. Some specific boolean parameters may also accept ``"true"``, ``"false"``, ``0``, ``1``, ``"0"``, and ``"1"``. .. _dhcp6-vendor-opts: @@ -1975,11 +2008,41 @@ DHCPv6 Vendor-Specific Options ------------------------------ Vendor options in DHCPv6 are carried in the Vendor-Specific -Information option (code 17). The following examples show how to -define an option "foo" with code 1 that consists of an IPv6 address, -an unsigned 16-bit integer, and a string. The "foo" option is +Information option (code 17). The idea behind option 17 +is that each vendor has its own unique set of options with their own custom +formats. The vendor is identified by a 32-bit unsigned integer called +``enterprise-number`` or ``vendor-id``. + +The standard spaces defined in Kea and their options are: + +- ``vendor-2495``: Internet Systems Consortium, Inc. for 4o6 options: + ++-------------+--------------------+------------------------------------------------------------------------+ +| option code | option name | option description | ++=============+====================+========================================================================+ +| 60000 | 4o6-interface | the name of the 4o6 server's client-facing interface | ++-------------+--------------------+------------------------------------------------------------------------+ +| 60001 | 4o6-source-address | the address that the 4o6 server uses to send packets to the client | ++-------------+--------------------+------------------------------------------------------------------------+ +| 60002 | 4o6-source-port | the port that the 4o6 server opens to send packets to the client | ++-------------+--------------------+------------------------------------------------------------------------+ + +- ``vendor-4491``: Cable Television Laboratories, Inc. for DOCSIS3 options: + ++-------------+--------------------+------------------------------------------------------------------------+ +| option code | option name | option description | ++=============+====================+========================================================================+ +| 1 | oro | ORO (or Option Request Option) is used by clients to request a list of | +| | | options they are interested in. | ++-------------+--------------------+------------------------------------------------------------------------+ +| 2 | tftp-servers | a list of IPv4 addresses of TFTP servers to be used by the cable modem | ++-------------+--------------------+------------------------------------------------------------------------+ + +The following examples show how to +define an option ``"foo"`` with code 1 that consists of an IPv6 address, +an unsigned 16-bit integer, and a string. The ``"foo"`` option is conveyed in a Vendor-Specific Information option, which comprises a -single uint32 value that is set to "12345". The sub-option "foo" +single uint32 value that is set to ``12345``. The sub-option ``"foo"`` follows the data field holding this value. The first step is to define the format of the option: @@ -2001,7 +2064,7 @@ The first step is to define the format o ... } -(Note that the option space is set to ``vendor-12345``.) Once the +(Note that the option space is set to ``"vendor-12345"``.) Once the option format is defined, the next step is to define actual values for that option: @@ -2019,8 +2082,8 @@ that option: ... } -We should also define a value (enterprise-number) for the -Vendor-Specific Information option, that conveys our option "foo". +We should also define a value (``"enterprise-number"``) for the +Vendor-Specific Information option, to convey the option ``foo``. :: @@ -2050,14 +2113,14 @@ Alternatively, the option can be specifi ... } -A common configuration is to set the always-send flag to true so the +A common configuration is to set the ``always-send`` flag to ``true``, so the vendor option is sent even when the client did not specify it in the query. .. note:: - Currently only a single instance of the vendor-class (code 16) and - a single instance of the vendor-opts (code 17) options can be - specified. Specifying multiple options with different enterprise + Only a single instance of the ``vendor-class`` (code 16) and + a single instance of the ``vendor-opts`` (code 17) options can be + specified. Specifying multiple options with different enterprise numbers is currently not supported by Kea. .. _dhcp6-option-spaces: @@ -2065,9 +2128,9 @@ vendor option is sent even when the clie Nested DHCPv6 Options (Custom Option Spaces) -------------------------------------------- -It is sometimes useful to define completely new option spaces, such as +It is sometimes useful to define a completely new option space, such as when a user creates a new option to convey sub-options that -use a separate numbering scheme, for example sub-options with codes 1 +use a separate numbering scheme, such as sub-options with codes 1 and 2. Those option codes conflict with standard DHCPv6 options, so a separate option space must be defined. @@ -2076,8 +2139,8 @@ defining sub-options for a standard opti default if the standard option is meant to convey any sub-options (see :ref:`dhcp6-vendor-opts`). -Assume that we want to have a DHCPv6 option called "container" with code -102 that conveys two sub-options with codes 1 and 2. First we need to +If we want a DHCPv6 option called ``container`` with code +102, that conveys two sub-options with codes 1 and 2, we first need to define the new sub-options: :: @@ -2107,7 +2170,7 @@ define the new sub-options: } Note that we have defined the options to belong to a new option space -(in this case, "isc"). +(in this case, ``"isc"``). The next step is to define a regular DHCPv6 option with the desired code and specify that it should include options from the new option space: @@ -2131,8 +2194,9 @@ and specify that it should include optio } The name of the option space in which the sub-options are defined is set -in the ``encapsulate`` field. The ``type`` field is set to ``empty``, -which limits this option to only carrying data in sub-options. +in the ``encapsulate`` field. The ``type`` field is set to ``"empty"``, +to indicate that this option does not carry any data other than +sub-options. Finally, we can set values for the new options: @@ -2161,16 +2225,16 @@ Finally, we can set values for the new o ... } -Note that it is possible to create an option which carries some data in +It is possible to create an option which carries some data in addition to the sub-options defined in the encapsulated option space. -For example, if the "container" option from the previous example were +For example, if the ``container`` option from the previous example were required to carry a uint16 value as well as the sub-options, the -``type`` value would have to be set to "uint16" in the option +``type`` value would have to be set to ``"uint16"`` in the option definition. (Such an option would then have the following data structure: DHCP header, uint16 value, sub-options.) The value specified with the ``data`` parameter — which should be a valid integer enclosed -in quotes, e.g. "123" — would then be assigned to the uint16 field in -the "container" option. +in quotes, e.g. ``"123"`` — would then be assigned to the ``uint16`` field in +the ``container`` option. .. _dhcp6-option-data-defaults: @@ -2189,17 +2253,17 @@ specified: must be specified. - ``code`` - the server requires either an option name or an option code to - identify an option. This parameter may be left unspecified if the + identify an option; this parameter may be left unspecified if the ``name`` parameter is specified. However, this also requires that the - particular option has a definition (either as a standard option or + particular option have a definition (either as a standard option or an administrator-created definition for the option using an - 'option-def' structure), as the option definition associates an + ``option-def`` structure), as the option definition associates an option with a particular name. It is possible to configure an option for which there is no definition (unspecified option format). Configuration of such options requires the use of the option code. -- ``space`` - if the option space is unspecified it will default to - 'dhcp6', which is an option space holding standard DHCPv6 options. +- ``space`` - if the option space is unspecified it defaults to + ``dhcp6``, which is an option space holding standard DHCPv6 options. - ``data`` - if the option data is unspecified it defaults to an empty value. The empty value is mostly used for the options which have no @@ -2208,8 +2272,8 @@ specified: specification allows a length of 0. For such options, the data parameter may be omitted in the configuration. -- ``csv-format`` - if this value is not specified, the server will - assume that the option data is specified as a list of comma-separated +- ``csv-format`` - if this value is not specified, the server + assumes that the option data is specified as a list of comma-separated values to be assigned to individual fields of the DHCP option. .. _dhcp6-t1-t2-times: @@ -2221,12 +2285,11 @@ According to RFC 8415, section 21.4, the are 50% and 80% of the preferred lease time, respectively. Kea can be configured to send values that are specified explicitly or that are calculated as percentages of the -preferred lease time. The server's behavior is governed by a combination -of configuration parameters, two of which have already been mentioned. - -Beginning with Kea 1.6.0 lease preferred and valid lifetime are extended from -single values to triplets with minimum, default and maximum values using: +preferred lease time. The server's behavior is determined by a combination +of configuration parameters, of which T1 and T2 are only two. +The lease's preferred and valid lifetimes are expressed as triplets with +minimum, default, and maximum values using configuration entries: - ``min-preferred-lifetime`` - specifies the minimum preferred lifetime (optional). @@ -2240,28 +2303,28 @@ single values to triplets with minimum, - ``max-valid-lifetime`` - specifies the maximum valid lifetime (optional). -As of Kea 1.9.11, these values may be specified within client classes. +Since Kea 1.9.11, these values may be specified within client classes. -When the client does not specify lifetimes the default is used. When -it specifies a lifetime using IAADDR or IAPREFIX sub option with -non-zero values, these values are used when they are between configured -minimum (lower values are round up) and maximum (larger values are -rounded down) bounds. +When the client does not specify lifetimes, the default is used. +A specified lifetime - using the IAADDR or IAPREFIX sub-option with +non-zero values - uses these values when they are between the configured +minimum and maximum bounds. Values outside the bounds are rounded up or down as +needed. -To send specific, fixed values use the following two parameters: +To send specific fixed values, use the following two parameters: - ``renew-timer`` - specifies the value of T1 in seconds. - ``rebind-timer`` - specifies the value of T2 in seconds. -Any value greater than or equal to zero may be specified for T2. When -specifying T1 it must be less than T2. This flexibility is allowed to -support a use case where administrators want to suppress client renewals and +Any value greater than or equal to zero may be specified for T2. +T1, if specified, must be less than T2. This flexibility allows +a use case where administrators want to suppress client renewals and rebinds by deferring them beyond the lifespan of the lease. This should cause the lease to expire, rather than get renewed by clients. If T1 is -specified as larger than T2, T1 will be set to zero in the outbound IA. +specified as larger than T2, T1 is silently set to zero in the outbound IA. -In the great majority of cases the values should follow this rule: T1 < T2 < +In the great majority of cases, the values should follow this rule: T1 < T2 < preferred lifetime < valid lifetime. Alternatively, both T1 and T2 values can be configured to 0, which is a signal to DHCPv6 clients that they may renew at their own discretion. However, there are known broken @@ -2280,29 +2343,27 @@ However, there may be some rare business Calculation of the values is controlled by the following three parameters: -- ``calculate-tee-times`` - when true, T1 and T2 will be calculated as - percentages of the valid lease time. It defaults to true. +- ``calculate-tee-times`` - when ``true``, T1 and T2 are calculated as + percentages of the valid lease time. It defaults to ``true``. - ``t1-percent`` - the percentage of the valid lease time to use for T1. It is expressed as a real number between 0.0 and 1.0 and must be - less than t2-percent. The default value is 0.5 per RFC 8415. + less than ``t2-percent``. The default value is 0.5, per RFC 8415. - ``t2-percent`` - the percentage of the valid lease time to use for T2. It is expressed as a real number between 0.0 and 1.0 and must be - greater than t1-percent. The default value is 0.8 per RFC 8415. - -.. + greater than ``t1-percent``. The default value is 0.8 per RFC 8415. .. note:: - In the event that both explicit values are specified and - calculate-tee-times is true, the server will use the explicit values. - Administrators with a setup where some subnets or share-networks - will use explicit values and some will use calculated values must + If both explicit values are specified and + ``calculate-tee-times`` is ``true``, the server will use the explicit values. + Administrators with a setup where some subnets or shared-networks + use explicit values and some use calculated values must not define the explicit values at any level higher than where they will be used. Inheriting them from too high a scope, such as global, will cause them to have values at every level underneath - (shared-networks and subnets), effectively disabling calculated + (both shared-networks and subnets), effectively disabling calculated values. .. _dhcp6-config-subnets: @@ -2371,9 +2432,9 @@ shown below: } This setting only affects the subnet for which ``rapid-commit`` is -set to ``true``. For clients connected to other subnets, the server will -ignore the Rapid Commit option sent by the client and will follow the -4-way exchange procedure, i.e. respond with an Advertise for a Solicit +set to ``true``. For clients connected to other subnets, the server +ignores the Rapid Commit option sent by the client and follows the +4-way exchange procedure, i.e. responds with an Advertise for a Solicit containing a Rapid Commit option. .. _dhcp6-relays: @@ -2385,33 +2446,33 @@ A DHCPv6 server with multiple subnets de appropriate subnet when it receives a request from a client. For clients connected via relays, two mechanisms are used: -The first uses the linkaddr field in the RELAY_FORW message. The name of +The first uses the ``linkaddr`` field in the ``RELAY_FORW`` message. The name of this field is somewhat misleading in that it does not contain a link-layer address; instead, it holds an address (typically a global address) that is used to identify a link. The DHCPv6 server checks to see whether the address belongs to a defined subnet and, if it does, that subnet is selected for the client's request. -The second mechanism is based on interface-id options. While forwarding -a client's message, relays may insert an interface-id option into the +The second mechanism is based on ``interface-id`` options. While forwarding +a client's message, relays may insert an ``interface-id`` option into the message that identifies the interface on the relay that received the message. (Some relays allow configuration of that parameter, but it is -sometimes hard-coded and may range from the very simple (e.g. "vlan100") +sometimes hard-coded and may range from the very simple [e.g. "vlan100"] to the very cryptic; one example seen on real hardware was -"ISAM144|299|ipv6|nt:vp:1:110"). The server can use this information to +"ISAM144|299|ipv6|nt:vp:1:110".) The server can use this information to select the appropriate subnet. The information is also returned to the relay, which then knows the interface to use to transmit the response to the client. For this to work successfully, the relay interface IDs must be unique within the network and the server configuration must match those values. -When configuring the DHCPv6 server, it should be noted that two +When configuring the DHCPv6 server, two similarly named parameters can be configured for a subnet: -- ``interface`` defines which local network interface can be used to +- ``interface`` - defines which local network interface can be used to access a given subnet. -- ``interface-id`` specifies the content of the interface-id option +- ``interface-id`` - specifies the content of the ``interface-id`` option used by relays to identify the interface on the relay to which the response packet is sent. @@ -2420,7 +2481,7 @@ locally (direct traffic) and via relays both is a configuration error and the DHCPv6 server will refuse such a configuration. -The following example configuration shows how to specify an interface-id +The following example configuration shows how to specify an ``interface-id`` with a value of "vlan123": :: @@ -2449,7 +2510,7 @@ Relay-Supplied Options called Relay-Supplied DHCP Options. In certain cases relay agents are the only entities that may have specific information, and they can insert options when relaying messages from the client to the server. The -server will then do certain checks and copy those options to the +server then does certain checks and copies those options to the response sent to the client. There are certain conditions that must be met for the option to be @@ -2461,7 +2522,7 @@ options `here `__. However, there may be cases when system administrators want to echo other options. Kea can be instructed to treat other options as -RSOO-enabled. For example, to mark options 110, 120, and 130 as +RSOO-enabled; for example, to mark options 110, 120, and 130 as RSOO-enabled, the following syntax should be used: :: @@ -2471,9 +2532,9 @@ RSOO-enabled, the following syntax shoul ... } -As of February 2019, only option 65 is RSOO-enabled by IANA. This option -will always be treated as such, so there is no need to explicitly mark -it. Also, when enabling standard options, it is possible to use their +At this time, only option 65 is RSOO-enabled by IANA. This option +will always be treated as RSOO-enabled, so there is no need to explicitly mark +it. When enabling standard options, it is also possible to use their names rather than their option code, e.g. use ``dns-servers`` instead of ``23``. See ref:`dhcp6-std-options-list` for the names. In certain cases this may also work for custom options, but due to the @@ -2485,12 +2546,12 @@ Client Classification in DHCPv6 ------------------------------- The DHCPv6 server includes support for client classification. For a -deeper discussion of the classification process see :ref:`classify`. +deeper discussion of the classification process, see :ref:`classify`. In certain cases it is useful to configure the server to differentiate between DHCP client types and treat them accordingly. Client classification can be used to modify the behavior of almost any part of -the DHCP message processing. Kea currently offers +DHCP message processing. Kea currently offers three mechanisms that take advantage of client classification in DHCPv6: subnet selection, address pool selection, and DHCP options assignment. @@ -2500,39 +2561,39 @@ devices share the same link and are expe different subnets. The primary use case for such a scenario is cable networks, where there are two classes of devices: the cable modem itself, which should be handed a lease from subnet A; and all other -devices behind the modem, which should get a lease from subnet B. That -segregation is essential to prevent overly curious users from playing +devices behind the modem, which should get leases from subnet B. That +segregation is essential to prevent overly curious end-users from playing with their cable modems. For details on how to set up class restrictions on subnets, see :ref:`classification-subnets`. When subnets belong to a shared network, the classification applies to subnet selection but not to pools; that is, a pool in a subnet limited to a particular class can still be used by clients which do not belong to the -class, if the pool they are expected to use is exhausted. So the limit +class, if the pool they are expected to use is exhausted. The limit on access based on class information is also available at the -address/prefix pool level; see :ref:`classification-pools`, within a -subnet. This is useful when segregating clients belonging to the same +address/prefix pool level within a subnet: see :ref:`classification-pools`. +This is useful when segregating clients belonging to the same subnet into different address ranges. In a similar way, a pool can be constrained to serve only known clients, -i.e. clients which have a reservation, using the built-in "KNOWN" or -"UNKNOWN" classes. Addresses can be assigned to registered clients -without giving a different address per reservation, for instance when +i.e. clients which have a reservation, using the built-in ``KNOWN`` or +``UNKNOWN`` classes. Addresses can be assigned to registered clients +without giving a different address per reservation: for instance, when there are not enough available addresses. The determination whether there is a reservation for a given client is made after a subnet is -selected, so it is not possible to use "KNOWN"/"UNKNOWN" classes to select a +selected, so it is not possible to use ``KNOWN``/``UNKNOWN`` classes to select a shared network or a subnet. The process of classification is conducted in five steps. The first step is to assess an incoming packet and assign it to zero or more classes. The second step is to choose a subnet, possibly based on the class -information. When the incoming packet is in the special class, "DROP, +information. When the incoming packet is in the special class ``DROP``, it is dropped and a debug message logged. The next step is to evaluate class expressions depending on the built-in -"KNOWN"/"UNKNOWN" classes after host reservation lookup, using them for +``KNOWN``/``UNKNOWN`` classes after host reservation lookup, using them for pool/pd-pool selection and assigning classes from host reservations. The list of required classes is then built and each class of the list has -its expression evaluated; when it returns "true" the packet is added as +its expression evaluated; when it returns ``true``, the packet is added as a member of the class. The last step is to assign options, again possibly based on the class information. More complete and detailed information is available in :ref:`classify`. @@ -2541,12 +2602,23 @@ There are two main methods of classifica relies on examining the values in the vendor class options or the existence of a host reservation. Information from these options is extracted, and a class name is constructed from it and added to the -class list for the packet. The second specifies an expression that is -evaluated for each packet. If the result is "true", the packet is a +class list for the packet. The second method specifies an expression that is +evaluated for each packet. If the result is ``true``, the packet is a member of the class. .. note:: + The new ``early-global-reservations-lookup`` global parameter flag + enables a lookup for global reservations before the subnet selection + phase. This lookup is similar to the general lookup described above + with two differences: + + - the lookup is limited to global host reservations + + - the ``UNKNOWN`` class is never set + +.. note:: + Care should be taken with client classification, as it is easy for clients that do not meet class criteria to be denied all service. @@ -2555,7 +2627,7 @@ Defining and Using Custom Classes The following example shows how to configure a class using an expression and a subnet using that class. This configuration defines the class -named "Client_enterprise". It is comprised of all clients whose client +named ``Client_enterprise``. It is comprised of all clients whose client identifiers start with the given hex string (which would indicate a DUID based on an enterprise id of 0xAABBCCDD). Members of this class will be given an address from 2001:db8:1::0 to 2001:db8:1::FFFF and the addresses of their DNS @@ -2591,7 +2663,7 @@ servers set to 2001:db8:0::1 and 2001:db } This example shows a configuration using an automatically generated -"VENDOR_CLASS\_" class. The administrator of the network has decided that +``VENDOR_CLASS_`` class. The administrator of the network has decided that addresses in the range 2001:db8:1::1 to 2001:db8:1::ffff are to be managed by the DHCP6 server and that only clients belonging to the eRouter1.0 client class are allowed to use that pool. @@ -2623,7 +2695,7 @@ shared network, subnet, or pool. There a to limit the scope of the class by instructing the server to evaluate test expressions when required. -The first one is the per-class ``only-if-required`` flag, which is false +The first one is the per-class ``only-if-required`` flag, which is ``false`` by default. When it is set to ``true``, the test expression of the class is not evaluated at the reception of the incoming packet but later, and only if the class evaluation is required. @@ -2631,7 +2703,7 @@ only if the class evaluation is required The second is ``require-client-classes``, which takes a list of class names and is valid in shared-network, subnet, and pool scope. Classes in these lists are marked as required and evaluated after selection of this -specific shared-network/subnet/pool and before output option processing. +specific shared network/subnet/pool and before output-option processing. In this example, a class is assigned to the incoming packet when the specified subnet is used: @@ -2665,15 +2737,15 @@ specified subnet is used: Required evaluation can be used to express complex dependencies like subnet membership. It can also be used to reverse the -precedence; if an option-data is set in a subnet, it takes precedence -over an option-data in a class. If the option-data is moved to a +precedence; if ``option-data`` is set in a subnet, it takes precedence +over ``option-data`` in a class. If ``option-data`` is moved to a required class and required in the subnet, a class evaluated earlier may take precedence. Required evaluation is also available at shared-network and pool/pd-pool levels. The order in which required classes are considered is: -shared-network, subnet, and (pd-)pool, i.e. in the opposite order in which -option-data is processed. +shared-network, subnet, and (pd-)pool, i.e. in the reverse order from the +way in which ``option-data`` is processed. .. _dhcp6-ddns-config: @@ -2682,27 +2754,25 @@ DDNS for DHCPv6 As mentioned earlier, kea-dhcp6 can be configured to generate requests to the DHCP-DDNS server (referred to here as "D2") to update DNS -entries. These requests are known as Name Change Requests or NCRs. Each +entries. These requests are known as NameChangeRequests or NCRs. Each NCR contains the following information: -1. Whether it is a request to add (update) or remove DNS entries +1. Whether it is a request to add (update) or remove DNS entries. 2. Whether the change requests forward DNS updates (AAAA records), - reverse DNS updates (PTR records), or both + reverse DNS updates (PTR records), or both. 3. The Fully Qualified Domain Name (FQDN), lease address, and DHCID - (information identifying the client associated with the FQDN) + (information identifying the client associated with the FQDN). -Prior to Kea 1.7.1, all parameters for controlling DDNS were within the -global ``dhcp-ddns`` section of the kea-dhcp6. Beginning with Kea 1.7.1 -DDNS related parameters were split into two groups: +DDNS-related parameters are split into two groups: 1. Connectivity Parameters - These are parameters which specify where and how kea-dhcp6 connects to - and communicates with D2. These parameters can only be specified - within the top-level ``dhcp-ddns`` section in the kea-dhcp6 - configuration. The connectivity parameters are listed below: + These are parameters which specify where and how ``kea-dhcp6`` connects to + and communicates with D2. These parameters can only be specified + within the top-level ``dhcp-ddns`` section in the ``kea-dhcp6`` + configuration. The connectivity parameters are listed below: - ``enable-updates`` - ``server-ip`` @@ -2716,12 +2786,12 @@ DDNS related parameters were split into 2. Behavioral Parameters These parameters influence behavior such as how client host names and - FQDN options are handled. They have been moved out of the ``dhcp-ddns`` + FQDN options are handled. They have been moved out of the ``dhcp-ddns`` section so that they may be specified at the global, shared-network, - and/or subnet levels. Furthermore, they are inherited downward from global to - shared-network to subnet. In other words, if a parameter is not specified at + and/or subnet levels. Furthermore, they are inherited downward from global to + shared-network to subnet. In other words, if a parameter is not specified at a given level, the value for that level comes from the level above it. - The behavioral parameter as follows: + The behavioral parameters are as follows: - ``ddns-send-updates`` - ``ddns-override-no-update`` @@ -2736,13 +2806,13 @@ DDNS related parameters were split into .. note:: - For backward compatibility, configuration parsing will still recognize - the original behavioral parameters specified in ``dhcp-ddns``. It will - do so by translating the parameter into its global equivalent. If a + For backward compatibility, configuration parsing still recognizes + the original behavioral parameters specified in ``dhcp-ddns``, + by translating the parameter into its global equivalent. If a parameter is specified both globally and in ``dhcp-ddns``, the latter - value will be ignored. In either case, a log will be emitted explaining - what has occurred. Specifying these values within ``dhcp-ddns`` is - deprecated and support for it will be removed at some future date. + value is ignored. In either case, a log is emitted explaining + what has occurred. Specifying these values within ``dhcp-ddns`` is + deprecated and support for it will be removed. The default configuration and values would appear as follows: @@ -2775,141 +2845,139 @@ The default configuration and values wou ... } -As of Kea 1.7.1, there are two parameters which determine if kea-dhcp6 +There are two parameters which determine if ``kea-dhcp6`` can generate DDNS requests to D2: the existing ``dhcp-ddns:enable-updates`` -parameter, which now only controls whether kea-dhcp6 connects to D2; +parameter, which now only controls whether ``kea-dhcp6`` connects to D2; and the new behavioral parameter, ``ddns-send-updates``, which determines whether DDNS updates are enabled at a given level (i.e. global, shared-network, or subnet). The following table shows how the two parameters function together: -.. table:: Enabling and Disabling DDNS Updates +.. table:: Enabling and disabling DDNS updates - +-----------------+--------------------+-------------------------------+ - | dhcp-ddns: | Global | Outcome | - | enable-updates | ddns-send-updates | | - +=================+====================+===============================+ - | false (default) | false | no updates at any scope | - +-----------------+--------------------+-------------------------------+ - | false | true (default) | no updates at any scope | - +-----------------+--------------------+-------------------------------+ - | true | false | updates only at scopes with | - | | | a local value of true for | - | | | ddns-enable-updates | - +-----------------+--------------------+-------------------------------+ - | true | true | updates at all scopes except | - | | | those with a local value of | - | | | false for ddns-enable-updates | - +-----------------+--------------------+-------------------------------+ + +-----------------+--------------------+-------------------------------------+ + | dhcp-ddns: | Global | Outcome | + | enable-updates | ddns-send-updates | | + +=================+====================+=====================================+ + | false (default) | false | no updates at any scope | + +-----------------+--------------------+-------------------------------------+ + | false | true (default) | no updates at any scope | + +-----------------+--------------------+-------------------------------------+ + | true | false | updates only at scopes with | + | | | a local value of ``true`` for | + | | | ``ddns-enable-updates`` | + +-----------------+--------------------+-------------------------------------+ + | true | true | updates at all scopes except those | + | | | with a local value of ``false`` | + | | | for ``ddns-enable-updates`` | + +-----------------+--------------------+-------------------------------------+ -Kea 1.9.1 adds two new parameters. The first new parameter is ``ddns-update-on-renew``. -Normally, when leases are renewed the server only updates DNS if the DNS +Kea 1.9.1 added two new parameters; the first is ``ddns-update-on-renew``. +Normally, when leases are renewed, the server only updates DNS if the DNS information for the lease (e.g. FQDN, DNS update direction flags) has changed. -Setting ``ddns-update-on-renew`` to true instructs the server to always update -the DNS information when a lease is renewed even if its DNS information has not +Setting ``ddns-update-on-renew`` to ``true`` instructs the server to always update +the DNS information when a lease is renewed, even if its DNS information has not changed. This allows Kea to "self-heal" if it was previously unable to add DNS entries or they were somehow lost by the DNS server. .. note:: - Setting ``ddns-update-on-renew`` to true may impact performance, especially - for servers with numerous clients who renew often. + Setting ``ddns-update-on-renew`` to ``true`` may impact performance, especially + for servers with numerous clients that renew often. The second parameter added in Kea 1.9.1 is ``ddns-use-conflict-resolution``. -The value of this parameter is passed by kea-dhcp6 to D2 with each DNS update -request. When true, (the default value), D2 will employ conflict resolution, +The value of this parameter is passed by ``kea-dhcp6`` to D2 with each DNS update +request. When ``true`` (the default value), D2 employs conflict resolution, as described in `RFC 4703 `__, when -attempting to fulfill the update request. When false, D2 will simply attempt -to update the DNS entries per the request, regardless of whether or not they -conflict with existing entries owned by other DHCP6 clients. +attempting to fulfill the update request. When ``false``, D2 simply attempts +to update the DNS entries per the request, regardless of whether they +conflict with existing entries owned by other DHCPv6 clients. .. note:: - Setting ``ddns-use-conflict-resolution`` to false disables the overwrite - safeguards that the rules of conflict resolution ( + Setting ``ddns-use-conflict-resolution`` to ``false`` disables the overwrite + safeguards that the rules of conflict resolution (from `RFC 4703 `__) are intended to - prevent. This means that existing entries for a FQDN or an + prevent. This means that existing entries for an FQDN or an IP address made for Client-A can be deleted or replaced by entries - for Client-B. Furthermore, there are two scenarios by which entries + for Client-B. Furthermore, there are two scenarios by which entries for multiple clients for the same key (e.g. FQDN or IP) can be created. 1. Client-B uses the same FQDN as Client-A but a different IP address. - In this case the forward DNS entries (AAAA, and DHCID RRs) for + In this case, the forward DNS entries (AAAA and DHCID RRs) for Client-A will be deleted as they match the FQDN and new entries for - Client-B will be added. The reverse DNS entries (PTR and DHCID RRs) + Client-B will be added. The reverse DNS entries (PTR and DHCID RRs) for Client-A, however, will not be deleted as they belong to a different - IP address while new entries for Client-B will still be added. + IP address, while new entries for Client-B will still be added. 2. Client-B uses the same IP address as Client-A but a different FQDN. In this case the reverse DNS entries (PTR and DHCID RRs) for Client-A - will be deleted as they match the IP address and new entries for - Client-B will be added. The forward DNS entries (AAAA and DHCID RRs) - for Client-A, however, will not be deleted as they belong to a different - FQDN while new entries for Client-B will still be added. + will be deleted as they match the IP address, and new entries for + Client-B will be added. The forward DNS entries (AAAA and DHCID RRs) + for Client-A, however, will not be deleted, as they belong to a different + FQDN, while new entries for Client-B will still be added. Disabling conflict resolution should be done only after careful review of specific use cases. The best way to avoid unwanted DNS entries is to always ensure lease changes are processed through Kea, whether they are - released, expire, or are deleted via the lease-del6 command, prior to - reassigning either FQDNs or IP addresses. Doing so causes kea-dhcp6 + released, expire, or are deleted via the ``lease-del6`` command, prior to + reassigning either FQDNs or IP addresses. Doing so causes ``kea-dhcp6`` to generate DNS removal requests to D2. .. note:: - The DNS entries Kea creates contain a value for TTL (time to live). As of - Kea 1.9.3, kea-dhcp6 calculates that value based on - `RFC 4702, Section 5 `__ - which suggests that the TTL value be 1/3 of the lease's lifetime with - a minimum value of 10 minutes. Prior to this the server set the TTL value - equal to the lease's valid lifetime. Future releases may add one or - more parameters to customize this value. + The DNS entries Kea creates contain a value for TTL (time to live). Since + Kea 1.9.3, ``kea-dhcp6`` calculates that value based on + `RFC 4702, Section 5 `__, + which suggests that the TTL value be 1/3 of the lease's lifetime, with + a minimum value of 10 minutes. In earlier versions, the server set the TTL value + equal to the lease's valid lifetime. .. _dhcpv6-d2-io-config: DHCP-DDNS Server Connectivity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For NCRs to reach the D2 server, kea-dhcp6 must be able to communicate -with it. kea-dhcp6 uses the following configuration parameters to +For NCRs to reach the D2 server, ``kea-dhcp6`` must be able to communicate +with it. ``kea-dhcp6`` uses the following configuration parameters to control this communication: -- ``enable-updates`` - As of Kea 1.7.1, this parameter only enables - connectivity to kea-dhcp-ddns such that DDNS updates can be constructed - and sent. It must be true for NCRs to be generated and sent to D2. - It defaults to false. +- ``enable-updates`` - Enables connectivity to ``kea-dhcp-ddns`` such that DDNS + updates can be constructed and sent. It must be ``true`` for NCRs to be generated and sent to D2. + It defaults to ``false``. -- ``server-ip`` - IP address on which D2 listens for requests. The +- ``server-ip`` - This is the IP address on which D2 listens for requests. The default is the local loopback interface at address 127.0.0.1. Either an IPv4 or IPv6 address may be specified. -- ``server-port`` - port on which D2 listens for requests. The default +- ``server-port`` - This is the port on which D2 listens for requests. The default value is 53001. -- ``sender-ip`` - the IP address which kea-dhcp6 uses to send requests to - D2. The default value is blank, which instructs kea-dhcp6 to select a +- ``sender-ip`` - This is the IP address which ``kea-dhcp6`` uses to send requests to + D2. The default value is blank, which instructs ``kea-dhcp6`` to select a suitable address. -- ``sender-port`` - the port which kea-dhcp6 uses to send requests to D2. +- ``sender-port`` - This is the port which ``kea-dhcp6`` uses to send requests to D2. The default value of 0 instructs kea-dhcp6 to select a suitable port. -- ``max-queue-size`` - the maximum number of requests allowed to queue - waiting to be sent to D2. This value guards against requests +- ``max-queue-size`` - This is the maximum number of requests allowed to queue + while waiting to be sent to D2. This value guards against requests accumulating uncontrollably if they are being generated faster than they can be delivered. If the number of requests queued for - transmission reaches this value, DDNS updating will be turned off + transmission reaches this value, DDNS updating is turned off until the queue backlog has been sufficiently reduced. The intent is - to allow the kea-dhcp6 server to continue lease operations without running the + to allow the ``kea-dhcp6`` server to continue lease operations without running the risk that its memory usage grows without limit. The default value is 1024. -- ``ncr-protocol`` - the socket protocol to use when sending requests to +- ``ncr-protocol`` - This specifies the socket protocol to use when sending requests to D2. Currently only UDP is supported. -- ``ncr-format`` - the packet format to use when sending requests to D2. +- ``ncr-format`` - This specifies the packet format to use when sending requests to D2. Currently only JSON format is supported. -By default, kea-dhcp-ddns is assumed to be running on the same machine -as kea-dhcp6, and all of the default values mentioned above should be +By default, ``kea-dhcp-ddns`` is assumed to be running on the same machine +as ``kea-dhcp6``, and all of the default values mentioned above should be sufficient. If, however, D2 has been configured to listen on a different address or port, these values must be altered accordingly. For example, if D2 has been configured to listen on 2001:db8::5 port 900, the following @@ -2928,28 +2996,28 @@ configuration is required: .. _dhcpv6-d2-rules-config: -When Does the kea-dhcp6 Server Generate a DDNS Request? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +When Does the ``kea-dhcp6`` Server Generate a DDNS Request? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -kea-dhcp6 follows the behavior prescribed for DHCP servers in `RFC +``kea-dhcp6`` follows the behavior prescribed for DHCP servers in `RFC 4704 `__. It is important to keep in -mind that kea-dhcp6 makes the initial decision of when and what to +mind that ``kea-dhcp6`` makes the initial decision of when and what to update and forwards that information to D2 in the form of NCRs. Carrying out the actual DNS updates and dealing with such things as conflict resolution are within the purview of D2 itself -(see :ref:`dhcp-ddns-server`). This section describes when kea-dhcp6 -will generate NCRs and the configuration parameters that can be used to +(see :ref:`dhcp-ddns-server`). This section describes when ``kea-dhcp6`` +generates NCRs and the configuration parameters that can be used to influence this decision. It assumes that the ``enable-updates`` -parameter is true. +parameter is ``true``. .. note:: - Currently the interface between kea-dhcp6 and D2 only supports + Currently the interface between ``kea-dhcp6`` and D2 only supports requests which update DNS entries for a single IP address. If a lease - grants more than one address, kea-dhcp6 will create the DDNS update + grants more than one address, ``kea-dhcp6`` creates the DDNS update request for only the first of these addresses. -In general, kea-dhcp6 will generate DDNS update requests when: +In general, ``kea-dhcp6`` generates DDNS update requests when: 1. A new lease is granted in response to a DHCPREQUEST; @@ -2958,18 +3026,18 @@ In general, kea-dhcp6 will generate DDNS 3. An existing lease is released in response to a DHCPRELEASE. -In the second case, lease renewal, two DDNS requests will be issued: one +In the second case, lease renewal, two DDNS requests are issued: one request to remove entries for the previous FQDN, and a second request to -add entries for the new FQDN. In the last case, a lease release, a -single DDNS request to remove its entries will be made. +add entries for the new FQDN. In the third case, a lease release - a +single DDNS request - to remove its entries will be made. As for the first case, the decisions involved when granting a new lease are -more complex. When a new lease is granted, kea-dhcp6 will generate a +more complex. When a new lease is granted, ``kea-dhcp6`` generates a DDNS update request only if the DHCPREQUEST contains the FQDN option -(code 39). By default, kea-dhcp6 will respect the FQDN N and S flags +(code 39). By default, ``kea-dhcp6`` respects the FQDN N and S flags specified by the client as shown in the following table: -.. table:: Default FQDN Flag Behavior +.. table:: Default FQDN flag behavior +-----------------+-----------------+-----------------+-----------------+ | Client | Client Intent | Server Response | Server | @@ -2994,18 +3062,18 @@ specified by the client as shown in the The first row in the table above represents "client delegation." Here the DHCP client states that it intends to do the forward DNS updates and -the server should do the reverse updates. By default, kea-dhcp6 will -honor the client's wishes and generate a DDNS request to D2 to update +the server should do the reverse updates. By default, ``kea-dhcp6`` +honors the client's wishes and generates a DDNS request to D2 to update only reverse DNS data. The parameter ``ddns-override-client-update`` can be used to instruct the server to override client delegation requests. When -this parameter is "true", kea-dhcp6 will disregard requests for client -delegation and generate a DDNS request to update both forward and +this parameter is ``true``, ``kea-dhcp6`` disregards requests for client +delegation and generates a DDNS request to update both forward and reverse DNS data. In this case, the N-S-O flags in the server's response to the client will be 0-1-1 respectively. (Note that the flag combination N=1, S=1 is prohibited according to `RFC 4702 `__. If such a combination is -received from the client, the packet will be dropped by kea-dhcp6.) +received from the client, the packet will be dropped by ``kea-dhcp6``.) To override client delegation, set the following values in the configuration file: @@ -3019,10 +3087,10 @@ configuration file: } The third row in the table above describes the case in which the client -requests that no DNS updates be done. The parameter, -``ddns-override-no-update``, can be used to instruct the server to disregard -the client's wishes. When this parameter is true, kea-dhcp6 will -generate DDNS update requests to kea-dhcp-ddns even if the client +requests that no DNS updates be done. The parameter +``ddns-override-no-update`` can be used to instruct the server to disregard +the client's wishes. When this parameter is ``true``, ``kea-dhcp6`` +generates DDNS update requests to ``kea-dhcp-ddns`` even if the client requests that no updates be done. The N-S-O flags in the server's response to the client will be 0-1-1. @@ -3038,10 +3106,10 @@ To override client delegation, issue the .. _dhcpv6-fqdn-name-generation: -kea-dhcp6 Name Generation for DDNS Update Requests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``kea-dhcp6`` Name Generation for DDNS Update Requests +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Each Name Change Request must of course include the fully qualified +Each NameChangeRequest must of course include the fully qualified domain name whose DNS entries are to be affected. kea-dhcp6 can be configured to supply a portion or all of that name, based upon what it receives from the client in the DHCPREQUEST. @@ -3075,18 +3143,16 @@ parameter, which provides the following - ``when-not-present`` - use the name the client sent. If the client sent no name, generate one for the client. -.. - .. note:: - Note that in early versions of Kea, this parameter was a boolean and + In early versions of Kea, this parameter was a boolean and permitted only values of ``true`` and ``false``. Boolean values have been deprecated and are no longer accepted. Administrators currently using booleans must replace them with the - desired mode name. A value of ``true`` maps to ``"when-present"``, while - ``false`` maps to ``"never"``. + desired mode name. A value of ``true`` maps to ``when-present``, while + ``false`` maps to ``never``. -For example, to instruct kea-dhcp6 to always generate the FQDN for a +For example, to instruct ``kea-dhcp6`` to always generate the FQDN for a client, set the parameter ``ddns-replace-client-name`` to ``always`` as follows: @@ -3123,28 +3189,28 @@ are enabled. To set its value simply set ... } -When qualifying a partial name, kea-dhcp6 constructs the name in the +When qualifying a partial name, ``kea-dhcp6`` constructs the name in the format: -[**candidate-name**].[**ddns-qualifying-suffix**]. +``[candidate-name].[ddns-qualifying-suffix].`` -where **candidate-name** is the partial name supplied in the DHCPREQUEST. +where ``candidate-name`` is the partial name supplied in the DHCPREQUEST. For example, if the FQDN domain name value is "some-computer" and the -``ddns-qualifying-suffix`` "example.com", the generated FQDN is: +``ddns-qualifying-suffix`` is "example.com", the generated FQDN is: -**some-computer.example.com.** +``some-computer.example.com.`` -When generating the entire name, kea-dhcp6 will construct the name in +When generating the entire name, ``kea-dhcp6`` constructs the name in the format: -[**ddns-generated-prefix**]-[**address-text**].[**ddns-qualifying-suffix**]. +``[ddns-generated-prefix]-[address-text].[ddns-qualifying-suffix].`` -where **address-text** is simply the lease IP address converted to a +where ``address-text`` is simply the lease IP address converted to a hyphenated string. For example, if the lease address is 3001:1::70E, the -qualifying suffix "example.com", and the default value is used for +qualifying suffix is "example.com", and the default value is used for ``ddns-generated-prefix``, the generated FQDN is: -**myhost-3001-1--70E.example.com.** +``myhost-3001-1--70E.example.com.`` .. _dhcp6-host-name-sanitization: @@ -3153,32 +3219,25 @@ Sanitizing Client FQDN Names Some DHCP clients may provide values in the name component of the FQDN option (option code 39) that contain undesirable -characters. It is possible to configure kea-dhcp6 to sanitize these +characters. It is possible to configure ``kea-dhcp6`` to sanitize these values. The most typical use case is ensuring that only characters that -are permitted by RFC 1035 be included: A-Z, a-z, 0-9, and '-'. This may be +are permitted by RFC 1035 be included: A-Z, a-z, 0-9, and "-". This may be accomplished with the following two parameters: - ``hostname-char-set`` - a regular expression describing the invalid character set. This can be any valid, regular expression using POSIX - extended expression syntax. Embedded nulls (0x00) are always + extended expression syntax. Embedded nulls (0x00) are always considered an invalid character to be replaced (or omitted). + The default is ``"[^A-Za-z0-9.-]"``. This matches any character that is not + a letter, digit, dot, hyphen, or null. - ``hostname-char-replacement`` - a string of zero or more characters with which to replace each invalid character in the host name. An empty string causes invalid characters to be OMITTED rather than replaced. - -.. note:: - - Starting with Kea 1.7.5, the default values are as follows: - - - "hostname-char-set": "[^A-Za-z0-9.-]", - - "hostname-char-replacement": "" - - This enables sanitizing and omits any character that is not - a letter, digit, hyphen, dot, or null. + The default is ``""``. The following configuration replaces anything other than a letter, -digit, hyphen, or dot with the letter 'x': +digit, dot, or hyphen with the letter "x": :: "Dhcp6": { @@ -3195,7 +3254,6 @@ qualifying suffix (if one is defined and .. note:: - The following are some considerations to keep in mind: Name sanitizing is meant to catch the more common cases of invalid characters through a relatively simple character-replacement scheme. It is difficult to devise a scheme that works well in all cases. @@ -3204,7 +3262,7 @@ qualifying suffix (if one is defined and mechanism should consider writing a hook that can carry out sufficiently complex logic to address their needs. - Do not include dots in the hostname-char-set expression. When + Do not include dots in the ``hostname-char-set`` expression. When scrubbing FQDNs, dots are treated as delimiters and used to separate the option value into individual domain labels that are scrubbed and then re-assembled. @@ -3217,17 +3275,17 @@ qualifying suffix (if one is defined and Finally, given the latitude clients have in the values they send, it is virtually impossible to guarantee that a combination of these two parameters will always yield a name that is valid for use in DNS. For - example, using an empty value for hostname-char-replacement could + example, using an empty value for ``hostname-char-replacement`` could yield an empty domain label within a name, if that label consists only of invalid characters. .. note:: - Since the 1.6.0 Kea release, it is possible to specify hostname-char-set - and/or hostname-char-replacement at the global scope. This allows - sanitizing of host names without requiring a dhcp-ddns entry. When - a hostname-char parameter is defined at the global scope and - in a dhcp-ddns entry, the second (local) value is used. + It is possible to specify ``hostname-char-set`` + and/or ``hostname-char-replacement`` at the global scope. This allows + host names to be sanitized without requiring a ``dhcp-ddns`` entry. When + a ``hostname-char`` parameter is defined at both the global scope and + in a ``dhcp-ddns`` entry, the second (local) value is used. .. _dhcp6-dhcp4o6-config: @@ -3243,9 +3301,9 @@ configuration of the DHCPv6 side (the DH .. note:: DHCPv4-over-DHCPv6 support is experimental and the details of the - inter-process communication may change; both the DHCPv4 and DHCPv6 - sides should be running the same version of Kea. For instance, the + inter-process communication may change; for instance, the support of port relay (RFC 8357) introduced an incompatible change. + Both the DHCPv4 and DHCPv6 sides should be running the same version of Kea. There is only one specific parameter for the DHCPv6 side: ``dhcp4o6-port``, which specifies the first of the two consecutive ports @@ -3254,10 +3312,10 @@ DHCPv4 servers. The DHCPv6 server is bou connected to ::1 on ``port`` + 1. Two other configuration entries are generally required: unicast traffic -support (see :ref:`dhcp6-unicast`) and DHCP 4o6 +support (see :ref:`dhcp6-unicast`) and the DHCP 4o6 server address option (name "dhcp4o6-server-addr", code 88). -The following configuration was used during some tests: +ISC tested the following configuration: :: @@ -3309,8 +3367,6 @@ The following configuration was used dur } -.. - .. note:: Relayed DHCPv4-QUERY DHCPv6 messages are not supported. @@ -3321,29 +3377,30 @@ Sanity Checks in DHCPv6 ----------------------- An important aspect of a well-running DHCP system is an assurance that -the data remain consistent. However, in some cases it may be convenient +the data remains consistent; however, in some cases it may be convenient to tolerate certain inconsistent data. For example, a network -administrator that temporarily removed a subnet from a configuration -would not want all the leases associated with it to disappear from the lease -database. Kea has a mechanism to control sanity checks for situations -such as this. +administrator who temporarily removes a subnet from a configuration +would not want all the leases associated with it to disappear from the +lease database. Kea has a mechanism to implement sanity checks for situations +like this. Kea supports a configuration scope called ``sanity-checks``. It currently allows only a single parameter, called ``lease-checks``, which governs the verification carried out when a new lease is loaded from a -lease file. This mechanism permits Kea to attempt to correct -inconsistent data. +lease file. This mechanism permits Kea to attempt to correct inconsistent data. + +Every subnet has a ``subnet-id`` value; this is how Kea internally +identifies subnets. Each lease has a ``subnet-id`` parameter as well, which +identifies the subnet it belongs to. However, if the configuration has +changed, it is possible that a lease could exist with a ``subnet-id`` but +without any subnet that matches it. Also, it is possible that the +subnet's configuration has changed and the ``subnet-id`` now belongs to a +subnet that does not match the lease. -Every subnet has a subnet-id value; this is how Kea internally -identifies subnets. Each lease has a subnet-id parameter as well, which -identifies which subnet it belongs to. However, if the configuration has -changed, it is possible that a lease could exist with a subnet-id, but -without any subnet that matches it. Also, it may be possible that the -subnet's configuration has changed and the subnet-id now belongs to a -subnet that does not match the lease. Kea's corrective algorithm first -checks to see if there is a subnet with the subnet-id specified by the +Kea's corrective algorithm first +checks to see if there is a subnet with the ``subnet-id`` specified by the lease. If there is, it verifies whether the lease belongs to that -subnet. If not, depending on the lease-checks setting, the lease is +subnet. If not, depending on the ``lease-checks`` setting, the lease is discarded, a warning is displayed, or a new subnet is selected for the lease that matches it topologically. @@ -3359,18 +3416,18 @@ There are five levels which are supporte accept the lease data anyway. This is the default value. - ``fix`` - if a data inconsistency is discovered, try to - correct it. If the correction is not successful, the incorrect data - will be inserted anyway. + correct it. If the correction is not successful, insert the incorrect data + anyway. - ``fix-del`` - if a data inconsistency is discovered, try to correct it. If the correction is not successful, reject the lease. This setting ensures the data's correctness, but some incorrect data may be lost. Use with care. -- ``del`` - this is the strictest mode. If any inconsistency is - detected, reject the lease. Use with care. +- ``del`` - if any inconsistency is + detected, reject the lease. This is the strictest mode; use with care. -This feature is currently implemented for the memfile backend. Note the +This feature is currently implemented for the memfile backend. The sanity check applies to the lease database in memory, not to the lease file, i.e. inconsistent leases will stay in the lease file. @@ -3389,14 +3446,14 @@ An example configuration that sets this Storing Extended Lease Information ---------------------------------- -In order to support such features as DHCPv6 Reconfigure -(`RFC 3315 `__) and LeaseQuery -(`RFC 5007 `__) it is necessary to -store additional information with each lease. Because the amount +To support such features as DHCPv6 Reconfigure +(`RFC 3315 `__) and Leasequery +(`RFC 5007 `__), +additional information must be stored with each lease. Because the amount of information stored for each lease has ramifications in terms of -performance and system resource consumption, storing this additional -information is configurable through the "store-extended-info" parameter. -It defaults to false and may be set at the global, shared-network, and +performance and system resource consumption, storage of this additional +information is configurable through the ``store-extended-info`` parameter. +It defaults to ``false`` and may be set at the global, shared-network, and subnet levels. :: @@ -3406,12 +3463,12 @@ subnet levels. ... } -When enabled, information relevant to the DHCPv6 query (e.g. REQUEST, RENEW, -or REBIND) asking for the lease is added into the lease's user-context as a -map element labeled "ISC". Currently the information contained in the map -will be a list of relays, one for each relay message layer that encloses the -client query. Other values may be added at a future date. The lease's -user-context for a two-hop query might look something like this (shown +When set to ``true``, information relevant to the DHCPv6 query (e.g. REQUEST, RENEW, +or REBIND) asking for the lease is added into the lease's ``user-context`` as a +map element labeled "ISC". Currently, the information contained in the map +is a list of relays, one for each relay message layer that encloses the +client query. The lease's +``user-context`` for a two-hop query might look something like this (shown pretty-printed for clarity): :: @@ -3433,19 +3490,14 @@ pretty-printed for clarity): } } - .. note:: - This feature is intended to be used in conjunction with an upcoming - LeaseQuery hook library and at this time there is other use for this - information within Kea. -.. note:: It is possible that other hook libraries are already using - user-context. Enabling store-extended-info should not interfere with - any other user-context content, as long as it does not also use an element - labeled "ISC". In other words, user-context is intended to be a flexible + ``user-context``. Enabling ``store-extended-info`` should not interfere with + any other ``user-context`` content, as long as it does not also use an element + labeled "ISC". In other words, ``user-context`` is intended to be a flexible container serving multiple purposes. As long as no other purpose also - writes an "ISC" element to user-context there should not be a conflict. + writes an "ISC" element to ``user-context`` there should not be a conflict. .. _dhcp6-multi-threading-settings: @@ -3453,21 +3505,21 @@ Multi-Threading Settings ------------------------ The Kea server can be configured to process packets in parallel using multiple -threads. These settings can be found under ``multi-threading`` structure and are +threads. These settings can be found under the ``multi-threading`` structure and are represented by: - ``enable-multi-threading`` - use multiple threads to process packets in - parallel (default false). + parallel. The default is ``false``. - ``thread-pool-size`` - specify the number of threads to process packets in - parallel. Supported values are: 0 (auto detect), any positive number sets - thread count explicitly (default 0). + parallel. It may be set to 0 (auto-detect), or any positive number explicitly sets + the thread count. The default is 0. - ``packet-queue-size`` - specify the size of the queue used by the thread - pool to process packets. Supported values are: 0 (unlimited), any positive - number sets queue size explicitly (default 64). + pool to process packets. It may be set to 0 (unlimited), or any positive + number explicitly sets the queue size. The default is 64. -An example configuration that sets these parameter looks as follows: +An example configuration that sets these parameters looks as follows: :: @@ -3480,22 +3532,22 @@ An example configuration that sets these ... } -Multi-Threading Settings in Different Backends ----------------------------------------------- +Multi-Threading Settings With Different Database Backends +--------------------------------------------------------- -Both kea-dhcp4 and kea-dhcp6 are tested internally to determine which settings +Both ``kea-dhcp4`` and ``kea-dhcp6`` are tested by ISC to determine which settings give the best performance. Although this section describes our results, they are merely -recommendations and are very dependent on the particular hardware that was used +recommendations and are very dependent on the particular hardware used for testing. We strongly advise that administrators run their own performance tests. -A full report of performance results for the latest stable Kea can be found +A full report of performance results for the latest stable Kea version can be found `here `_. This includes hardware and test scenario descriptions, as well as current results. -After enabling multi-threading, the number of threads is set by ``thread-pool-size`` -parameter, and results from our tests show that best configurations for -kea-dhcp6 are: +After enabling multi-threading, the number of threads is set by the ``thread-pool-size`` +parameter. Results from our tests show that best configurations for +``kea-dhcp6`` are: - ``thread-pool-size``: 4 when using ``memfile`` for storing leases. @@ -3503,41 +3555,40 @@ kea-dhcp6 are: - ``thread-pool-size``: 6 when using ``postgresql``. -Another very important parameter is ``packet-queue-size`` and in our tests we -used it as multiplier of ``thread-pool-size``. So actual setting strongly depends +Another very important parameter is ``packet-queue-size``; in our tests we +used it as a multiplier of ``thread-pool-size``. The actual setting strongly depends on ``thread-pool-size``. -Our tests reported best results when: +We saw the best results in our tests with the following settings: - ``packet-queue-size``: 150 * ``thread-pool-size`` when using ``memfile`` for - storing leases. In our case it's 150 * 4 = 600. This means that at any given + storing leases; in our case it was 150 * 4 = 600. This means that at any given time, up to 600 packets could be queued. - ``packet-queue-size``: 200 * ``thread-pool-size`` when using ``mysql`` for - storing leases. In our case it's 200 * 12 = 2400. This means that up to + storing leases; in our case it was 200 * 12 = 2400. This means that up to 2400 packets could be queued. - ``packet-queue-size``: 11 * ``thread-pool-size`` when using ``postgresql`` for - storing leases. In our case it's 11 * 6 = 66. - + storing leases; in our case it was 11 * 6 = 66. Lease Caching ------------- -Clients that attempt renewal frequently can cause the server to update -and write to the database frequently resulting in a performance impact +Clients that attempt multiple renewals in a short period can cause the server to update +and write to the database frequently, resulting in a performance impact on the server. The cache parameters instruct the DHCP server to avoid -updating leases too frequently thus avoiding this behavior. Instead +updating leases too frequently, thus avoiding this behavior. Instead, the server assigns the same lease (i.e. reuses it) with no -modifications except for CLTT (Client Last Transmission Time) which +modifications except for CLTT (Client Last Transmission Time), which does not require disk operations. The two parameters are the ``cache-threshold`` double and the -``cache-max-age`` integer and have no default, i.e. the lease caching +``cache-max-age`` integer; they have no default setting, i.e. the lease caching feature must be explicitly enabled. These parameters can be configured -at the global, shared network and subnet levels. The subnet level has -the precedence on the shared network level, the global level is used -as last resort. For example: +at the global, shared-network and subnet levels. The subnet level has +the precedence over the shared-network level, while the global level is used +as a last resort. For example: :: @@ -3552,50 +3603,50 @@ as last resort. For example: } ], -When an already assigned lease can fulfill a client query: +When an already-assigned lease can fulfill a client query: - - any important change e.g. for DDNS parameter, hostname, or - preferred or valid lifetime reduction makes the lease not reusable + - any important change, e.g. for DDNS parameter, hostname, or + preferred or valid lifetime reduction, makes the lease not reusable. - - lease age i.e. the difference between the creation or last modification - time and the current time is computed (elapsed duration) + - lease age, i.e. the difference between the creation or last modification + time and the current time, is computed (elapsed duration). - - if ``cache-max-age`` is explicitly configured, it is compared with the age - and leases that are too old are not reusable (this means that the value 0 - for ``cache-max-age`` disables the lease cache feature) + - if ``cache-max-age`` is explicitly configured, it is compared with the lease age; + leases that are too old are not reusable. This means that the value 0 + for ``cache-max-age`` disables the lease cache feature. - if ``cache-threshold`` is explicitly configured and is between 0.0 and 1.0, it expresses the percentage of the lease valid lifetime which is allowed for the lease age. Values below and including 0.0 and values greater than 1.0 disable the lease cache feature. -In the example a lease with a valid lifetime of 2000 seconds can be +In our example, a lease with a valid lifetime of 2000 seconds can be reused if it was committed less than 500 seconds ago. With a lifetime -of 3000 seconds the maximum age of 600 seconds applies. +of 3000 seconds, a maximum age of 600 seconds applies. -In outbound client responses (e.g. DHCPV6_REPLY messages) used -preferred and valid lifetimes are the reusable values i.e. the +In outbound client responses (e.g. DHCPV6_REPLY messages), the used +preferred and valid lifetimes are the reusable values, i.e. the expiration dates do not change. .. _host-reservation-v6: -Host Reservation in DHCPv6 -========================== +Host Reservations in DHCPv6 +=========================== There are many cases where it is useful to provide a configuration on a per-host basis. The most obvious one is to reserve a specific, static IPv6 address or/and prefix for exclusive use by a given client (host); -the returning client will receive the same address or/and prefix every time, -and other clients will never get that address. Another situation when host -reservations are applicable is when a host has specific requirements, +the returning client receives the same address and/or prefix every time, +and other clients will never get that address. Host +reservations are also convenient when a host has specific requirements, e.g. a printer that needs additional DHCP options or a cable modem that needs specific parameters. Yet another possible use case is to define unique names for hosts. -Note that there may be cases when a new reservation has been made for a +There may be cases when a new reservation has been made for a client for an address or prefix currently in use by another client. We call this situation a "conflict." These conflicts get resolved -automatically over time as described in subsequent sections. Once the +automatically over time, as described in subsequent sections. Once a conflict is resolved, the correct client will receive the reserved configuration when it renews. @@ -3603,7 +3654,7 @@ Host reservations are defined as paramet must be identified by either DUID or its hardware/MAC address; see :ref:`mac-in-dhcpv6` for details. There is an optional ``reservations`` array in the ``subnet6`` structure; each -element in that array is a structure that holds information about a +element in that array is a structure that holds information about reservations for a single host. In particular, the structure has an identifier that uniquely identifies a host. In the DHCPv6 context, the identifier is usually a DUID, but it can also be a hardware or MAC address. One or more @@ -3612,8 +3663,7 @@ specify a hostname and DHCPv6 options fo .. note:: - Kea requires that reserved addresses must be within the subnet. - Kea 1.7.10 is the last release that does not enforce this. + The reserved address must be within the subnet. This does not apply to reserved prefixes. The following example shows how to reserve addresses and prefixes for @@ -3652,7 +3702,7 @@ specific hosts: ] This example includes reservations for three different clients. The -first reservation is for the address 2001:db8:1::100 for a client using +first reservation is for the address 2001:db8:1::100, for a client using DUID 01:02:03:04:05:0A:0B:0C:0D:0E. The second reservation is for two addresses, 2001:db8:1::101 and 2001:db8:1::102, for a client using MAC address 00:01:02:03:04:05. Lastly, address 2001:db8:1::103 and prefix @@ -3660,7 +3710,7 @@ address 00:01:02:03:04:05. Lastly, addre 01:02:03:04:05:06:07:08:09:0A. The last reservation also assigns a hostname to this client. -Note that DHCPv6 allows a single client to lease multiple addresses and +DHCPv6 allows a single client to lease multiple addresses and multiple prefixes at the same time. Therefore ``ip-addresses`` and ``prefixes`` are plural and are actually arrays. When the client sends multiple IA options (IA_NA or IA_PD), each reserved address or prefix is @@ -3705,7 +3755,7 @@ overhead. Address/Prefix Reservation Types -------------------------------- -In a typical scenario there is an IPv6 subnet defined, with a certain +In a typical Kea scenario there is an IPv6 subnet defined, with a certain part of it dedicated for dynamic address allocation by the DHCPv6 server. There may be an additional address space defined for prefix delegation. Those dynamic parts are referred to as dynamic pools, @@ -3719,9 +3769,9 @@ and both reservation types are handled u Kea supports global host reservations. These are reservations that are specified at the global level within the configuration and that do not -belong to any specific subnet. Kea will still match inbound client +belong to any specific subnet. Kea still matches inbound client packets to a subnet as before, but when the subnet's reservation mode is -set to ``"global"``, Kea will look for host reservations only among the +set to "global", Kea looks for host reservations only among the global reservations defined. Typically, such reservations would be used to reserve hostnames for clients which may move from one subnet to another. @@ -3734,9 +3784,9 @@ another. .. note:: - Beginning with Kea 1.9.1 reservation mode was replaced by three - boolean flags ``"reservations-global"``, ``"reservations-in-subnet"`` - and ``"reservations-out-of-pool"`` which allows the configuration of + Since Kea 1.9.1, reservation mode has been replaced by three + boolean flags, ``reservations-global``, ``reservations-in-subnet`` + and ``reservations-out-of-pool``, which allow the configuration of host reservations both globally and in a subnet. In such cases a subnet host reservation has preference over a global reservation when both exist for the same client. @@ -3756,7 +3806,7 @@ someone else is not recommended, but the such an operation is warranted. The server now has a conflict to resolve. If Host B boots up and -requests an address, the server is not able to assign the reserved +requests an address, the server cannot immediately assign the reserved address 2001:db8::10. A naive approach would to be immediately remove the lease for Host A and create a new one for Host B. That would not solve the problem, though, because as soon as Host B gets the address, @@ -3769,14 +3819,14 @@ When Host A renews its address, the serv address being renewed is now reserved for someone else - Host B. The server will remove the lease for 2001:db8::10, select a new address, and create a new lease for it. It will send two addresses -in its response: the old address, with lifetime set to 0 to explicitly +in its response: the old address, with the lifetime set to 0 to explicitly indicate that it is no longer valid; and the new address, with a non-zero lifetime. When Host B tries to renew its temporarily assigned address, the server will detect that the existing lease does not match the reservation, so it will release the current address Host B has and will create a new lease matching the reservation. As before, the server will -send two addresses: the temporarily assigned one with zeroed lifetimes, -and the new one that matches the reservation with proper lifetimes set. +send two addresses: the temporarily assigned one with a zero lifetime, +and the new one that matches the reservation with the proper lifetime set. This recovery will succeed, even if other hosts attempt to get the reserved address. If Host C requests the address 2001:db8::10 after the @@ -3784,10 +3834,10 @@ reservation is made, the server will pro This recovery mechanism allows the server to fully recover from a case where reservations conflict with existing leases; however, this procedure -will take roughly as long as the value set for renew-timer. The -best way to avoid such recovery is not to define new reservations that +takes roughly as long as the value set for ``renew-timer``. The +best way to avoid such a recovery is not to define new reservations that conflict with existing leases. Another recommendation is to use -out-of-pool reservations. If the reserved address does not belong to a +out-of-pool reservations; if the reserved address does not belong to a pool, there is no way that other clients can get it. .. note:: @@ -3805,11 +3855,11 @@ Reserving a Hostname -------------------- When the reservation for a client includes the ``hostname``, the server -will assign this hostname to the client and send it back in the Client -FQDN, if the client sent the FQDN option to the server. The reserved -hostname always takes precedence over the hostname supplied by the -client (via the FQDN option) or the autogenerated (from the IPv6 -address) hostname. +assigns this hostname to the client and sends it back in the Client +FQDN option, if the client included the Client FQDN option in its message +to the server. The reserved hostname always takes precedence over the +hostname supplied by the client (via the FQDN option) or the autogenerated +(from the IPv6 address) hostname. The server qualifies the reserved hostname with the value of the ``ddns-qualifying-suffix`` parameter. For example, the following subnet @@ -3835,7 +3885,7 @@ configuration: "enable-updates": true } -will result in assigning the "alice-laptop.example.isc.org." hostname to +will result the "alice-laptop.example.isc.org." hostname being assigned to the client using the DUID "01:02:03:04:05:0A:0B:0C:0D:0E". If the ``ddns-qualifying-suffix`` is not specified, the default (empty) value will be used, and in this case the value specified as a ``hostname`` will be @@ -3917,9 +3967,9 @@ Vendor-specific options can be reserved } ] } ] -Options defined at host level have the highest priority. In other words, +Options defined at the host level have the highest priority. In other words, if there are options defined with the same type on global, subnet, -class, and host levels, the host-specific values will be used. +class, and host levels, the host-specific values are used. .. _reservation6-client-classes: @@ -3928,11 +3978,11 @@ Reserving Client Classes in DHCPv6 :ref:`classification-using-expressions` explains how to configure the server to assign classes to a client, based on the content of the -options that this client sends to the server. Host reservations +options that this client sends to the server. Host reservation mechanisms also allow for the static assignment of classes to clients. -The definitions of these classes are placed in the Kea configuration or +The definitions of these classes are placed in the Kea configuration file or a database. The following configuration snippet shows how to specify that -a client belongs to classes ``reserved-class1`` and ``reserved-class2``. Those +a client belongs to the classes ``reserved-class1`` and ``reserved-class2``. Those classes are associated with specific options sent to the clients which belong to them. @@ -3994,17 +4044,18 @@ For example: ] } -Note that the ``only-if-required`` parameter is needed here to force +The ``only-if-required`` parameter is needed here to force evaluation of the class after the lease has been allocated and thus the reserved class has been also assigned. .. note:: - Be aware that the classes specified in non-global host reservations + + The classes specified in non-global host reservations are assigned to the processed packet after all classes with the ``only-if-required`` parameter set to ``false`` have been evaluated. - This has an implication that these classes must not depend on the - statically assigned classes from the host reservations. If there - is a need to create such dependency, the ``only-if-required`` must + This means that these classes must not depend on the + statically assigned classes from the host reservations. If + such a dependency is needed, the ``only-if-required`` must be set to ``true`` for the dependent classes. Such classes are evaluated after the static classes have been assigned to the packet. This, however, imposes additional configuration overhead, because @@ -4012,26 +4063,27 @@ reserved class has been also assigned. ``require-client-classes`` list for every subnet where they are used. .. note:: + Client classes specified within the Kea configuration file may depend on the classes specified within the global host reservations. In such a case the ``only-if-required`` parameter is not needed. Refer to the :ref:`pool-selection-with-class-reservations6` and :ref:`subnet-selection-with-class-reservations6` - for the specific use cases. + for specific use cases. -.. _reservations6-mysql-pgsql-cql: +.. _reservations6-mysql-pgsql: -Storing Host Reservations in MySQL, PostgreSQL, or Cassandra ------------------------------------------------------------- +Storing Host Reservations in MySQL or PostgreSQL +------------------------------------------------ -It is possible to store host reservations in MySQL, PostgreSQL, or -Cassandra. See :ref:`hosts6-storage` for information on -how to configure Kea to use reservations stored in MySQL, PostgreSQL, or -Cassandra. Kea provides a dedicated hook for managing reservations in a -database; section :ref:`host-cmds` provides detailed information. +Kea can store host reservations in MySQL or PostgreSQL. +See :ref:`hosts6-storage` for information on how to +configure Kea to use reservations stored in MySQL or PostgreSQL. +Kea provides a dedicated hook for managing reservations in a +database; section :ref:`hooks-host-cmds` provides detailed information. The `Kea wiki `__ -provides some examples of how to conduct common host reservations +provides some examples of how to conduct common host reservation operations. .. note:: @@ -4049,15 +4101,15 @@ the allocation engine (the component of a client) during lease selection and renewal. In particular, three major checks are necessary. First, when selecting a new lease, it is not sufficient for a candidate lease to simply not be in use by another DHCP -client; it also must not be reserved for another client. Second, when +client; it also must not be reserved for another client. Similarly, when renewing a lease, an additional check must be performed to see whether the address being renewed is reserved for another client. Finally, when a host renews an address or a prefix, the server must check whether -there is a reservation for this host, so the existing (dynamically +there is a reservation for this host, which would mean the existing (dynamically allocated) address should be revoked and the reserved one be used instead. -Some of those checks may be unnecessary in certain deployments and not +Some of those checks may be unnecessary in certain deployments, and not performing them may improve performance. The Kea server provides the ``reservation-mode`` configuration parameter to select the types of reservations allowed for a particular subnet. Each reservation type has @@ -4070,7 +4122,7 @@ allocating or renewing a lease for the c It does not check against global reservations. - ``out-of-pool`` - allows only out-of-pool host reservations. With - this setting in place, the server may assume that all host + this setting in place, the server assumes that all host reservations are for addresses that do not belong to the dynamic pool. Therefore, it can skip the reservation checks when dealing with in-pool addresses, thus improving performance. Do not use this mode @@ -4081,17 +4133,17 @@ allocating or renewing a lease for the c - ``global`` - allows only global host reservations. With this setting in place, the server searches for reservations for a client only among the defined global reservations. If an address is specified, - the server skips the reservation checks carried out when dealing in + the server skips the reservation checks carried out in other modes, thus improving performance. Caution is advised when using this setting; Kea does not sanity-check the reservations when - ``global`` and misconfiguration may cause problems. + ``global`` is set, and misconfiguration may cause problems. - ``disabled`` - host reservation support is disabled. As there are no - reservations, the server will skip all checks. Any reservations - defined will be completely ignored. As the checks are skipped, the + reservations, the server skips all checks. Any reservations + defined are completely ignored. As checks are skipped, the server may operate faster in this mode. -Since Kea 1.9.1, the ``reservation-mode`` is replaced by the +Since Kea 1.9.1, the ``reservation-mode`` parameter is replaced by the ``reservations-global``, ``reservations-in-subnet`` and ``reservations-out-of-pool`` flags. The flags can be activated independently and can produce various combinations, @@ -4225,20 +4277,16 @@ The meaning of the reservation flags are this includes all subnet members of the shared network. - ``reservations-out-of-pool``: this makes sense only when the - ``reservations-in-subnet`` flag is true. When ``reservations-out-of-pool`` - is true the server may assume that all host reservations are for addresses + ``reservations-in-subnet`` flag is ``true``. When ``reservations-out-of-pool`` + is ``true``, the server assumes that all host reservations are for addresses that do not belong to the dynamic pool. Therefore, it can skip the reservation checks when dealing with in-pool addresses, thus improving performance. - Also the server will not assign reserved addresses that are inside the dynamic + The server will not assign reserved addresses that are inside the dynamic pools to the respective clients. This also means that the addresses matching the respective reservations from inside the dynamic pools (if any) can be dynamically assigned to any client. -The ``reservation-mode`` will be deprecated in a future Kea version. - -The correspondence of old values are: - -``disabled``: +The ``disabled`` value from the deprecated ``reservation-mode`` corresponds to: .. code-block:: json @@ -4249,7 +4297,7 @@ The correspondence of old values are: } } -``global``: +The ``global`` value from the deprecated ``reservation-mode`` corresponds to: .. code-block:: json @@ -4260,7 +4308,7 @@ The correspondence of old values are: } } -``out-of-pool``: +The ``out-of-pool`` value from the deprecated ``reservation-mode`` corresponds to: .. code-block:: json @@ -4272,7 +4320,7 @@ The correspondence of old values are: } } -``all``: +And the ``all`` value from the deprecated ``reservation-mode`` corresponds to: .. code-block:: json @@ -4309,11 +4357,11 @@ be used: } } -Note that enabling ``out-of-pool`` and disabling ``in-subnet`` at the same time -is not recommended because ``out-of-pool`` is about host reservations in a -subnet which are fetched only when the ``in-subnet`` flag is true. +Enabling ``out-of-pool`` and disabling ``in-subnet`` at the same time +is not recommended because ``out-of-pool`` applies to host reservations in a +subnet, which are fetched only when the ``in-subnet`` flag is ``true``. -The parameter can be specified at global, subnet, and shared-network +The parameter can be specified at the global, subnet, and shared-network levels. An example configuration that disables reservations looks as follows: @@ -4379,13 +4427,13 @@ slower. To address this problem, a parameter called ``host-reservation-identifiers`` is available. It takes a list of -identifier types as a parameter. Kea will check only those identifier -types enumerated in host-reservation-identifiers. From a performance +identifier types as a parameter. Kea checks only those identifier +types enumerated in ``host-reservation-identifiers``. From a performance perspective, the number of identifier types should be kept to a minimum, ideally one. If the deployment uses several reservation types, please enumerate them from most- to least-frequently used, as this increases the chances of Kea finding the reservation using the fewest queries. An -example of host reservation identifiers looks as follows: +example of a ``host-reservation-identifiers`` configuration looks as follows: :: @@ -4410,24 +4458,24 @@ Global Reservations in DHCPv6 In some deployments, such as mobile, clients can roam within the network and certain parameters must be specified regardless of the client's -current location. To facilitate such a need, a global reservation -mechanism has been implemented. The idea behind it is that regular host +current location. To meet such a need, Kea offers a global reservation +mechanism. The idea behind it is that regular host reservations are tied to specific subnets, by using a specific -subnet-id. Kea can specify a global reservation that can be used in +subnet ID. Kea can specify a global reservation that can be used in every subnet that has global reservations enabled. This feature can be used to assign certain parameters, such as hostname or other dedicated, host-specific options. It can also be used to assign addresses or prefixes. However, global reservations that assign either -of these bypass the whole topology determination provided by DHCP logic +of these bypass the whole topology determination provided by the DHCP logic implemented in Kea. It is very easy to misuse this feature and get a configuration that is inconsistent. To give a specific example, imagine -a global reservation for an address 2001:db8:1111::1 and two subnets +a global reservation for the address 2001:db8:1111::1 and two subnets 2001:db8:1111::/48 and 2001:db8:ffff::/48. If global reservations are used in both subnets and a device matching global host reservations visits part of the network that is covered by 2001:db8:ffff::/48, it -will get an IP address 2001:db8:ffff::1, which will be outside of the -prefix announced by its local router using Router Advertisements. Such a +will get the IP address 2001:db8:ffff::1, which is outside of the +prefix announced by its local router using router advertisements. Such a configuration is unusable or, at the very least, riddled with issues, such as downlink traffic not reaching the device. @@ -4481,8 +4529,8 @@ following can be used: } When using database backends, the global host reservations are -distinguished from regular reservations by using subnet-id value of -zero. +distinguished from regular reservations by using a ``subnet-id`` value of +0. .. _pool-selection-with-class-reservations6: @@ -4490,7 +4538,7 @@ Pool Selection with Client Class Reserva --------------------------------------------- Client classes can be specified both in the Kea configuration file and/or -host reservations. The classes specified in the Kea configuration file are +via host reservations. The classes specified in the Kea configuration file are evaluated immediately after receiving the DHCP packet and therefore can be used to influence subnet selection using the ``client-class`` parameter specified in the subnet scope. The classes specified within the host @@ -4501,10 +4549,10 @@ subnet assignment for this client, unles shared network. If the subnet belongs to a shared network, the server may dynamically change the subnet assignment while trying to allocate a lease. If the subnet does not belong to a shared network, once selected, the subnet -is not changed. +is not changed once selected. If the subnet does not belong to a shared network, it is possible to -use host reservation based client classification to select an address pool +use host reservation-based client classification to select an address pool within the subnet as follows: :: @@ -4542,12 +4590,12 @@ within the subnet as follows: The ``reserved_class`` is declared without the ``test`` parameter because it may be only assigned to the client via host reservation mechanism. The -second class, ``unreserved_class``, is assigned to the clients which do not -belong to the ``reserved_class``. The first pool within the subnet is only -used for the clients having a reservation for the ``reserved_class``. The -second pool is used for the clients not having such reservation. The +second class, ``unreserved_class``, is assigned to clients which do not +belong to the ``reserved_class``. The first pool within the subnet is only +used for clients having a reservation for the ``reserved_class``. The +second pool is used for clients not having such a reservation. The configuration snippet includes one host reservation which causes the client -having the MAC address of aa:bb:cc:dd:ee:fe to be assigned to the +with the MAC address aa:bb:cc:dd:ee:fe to be assigned to the ``reserved_class``. Thus, this client will be given an IP address from the first address pool. @@ -4557,7 +4605,7 @@ Subnet Selection with Client Class Reser ----------------------------------------------- There is one specific use case when subnet selection may be influenced by -client classes specified within host reservations. This is the case when the +client classes specified within host reservations: when the client belongs to a shared network. In such a case it is possible to use classification to select a subnet within this shared network. Consider the following example: @@ -4615,62 +4663,62 @@ following example: This is similar to the example described in the :ref:`pool-selection-with-class-reservations6`. This time, however, there -are two subnets, each of them having a pool associated with a different -class. The clients which don't have a reservation for the ``reserved_class`` -will be assigned an address from the subnet 2001:db8:2::/64. Clients having -a reservation for the ``reserved_class`` will be assigned an address from +are two subnets, each of which has a pool associated with a different +class. The clients that do not have a reservation for the ``reserved_class`` +are assigned an address from the subnet 2001:db8:2::/64. Clients with +a reservation for the ``reserved_class`` are assigned an address from the subnet 2001:db8:1::/64. The subnets must belong to the same shared network. In addition, the reservation for the client class must be specified at the -global scope (global reservation) and the ``reservations-global`` must be -set to true. +global scope (global reservation) and ``reservations-global`` must be +set to ``true``. -In the example above the ``client-class`` could also be specified at the -subnet level rather than pool level yielding the same effect. +In the example above, the ``client-class`` could also be specified at the +subnet level rather than the pool level, and would yield the same effect. .. _multiple-reservations-same-ip6: Multiple Reservations for the Same IP ------------------------------------- -Host Reservations were designed to preclude creation of multiple +Host reservations were designed to preclude the creation of multiple reservations for the same IP address or delegated prefix within a -particular subnet to avoid the situation when two different clients +particular subnet, to avoid having two different clients compete for the same lease. When using the default settings, the server returns a configuration error when it finds two or more reservations for the same lease within a subnet in the Kea configuration file. The -:ref:`host-cmds` hooks library returns an error in response to the +:ref:`hooks-host-cmds` hook library returns an error in response to the ``reservation-add`` command when it detects that the reservation exists in the database for the lease for which the new reservation is being added. Similar to DHCPv4 (see :ref:`multiple-reservations-same-ip4`), the DHCPv6 -server can also be configured to allow creating multiple reservations +server can also be configured to allow the creation of multiple reservations for the same IPv6 address and/or delegated prefix in a given subnet. This -is supported beginning with Kea release 1.9.1 as an optional mode of operation +is supported since Kea release 1.9.1 as an optional mode of operation enabled with the ``ip-reservations-unique`` global parameter. -The ``ip-reservations-unique`` is a boolean parameter, which defaults to +The ``ip-reservations-unique`` is a boolean parameter that defaults to ``true``, which forbids the specification of more than one reservation for the same lease in a given subnet. Setting this parameter to ``false`` -allows for creating such reservations both in the Kea configuration -file and in the host database backends via ``host-cmds`` hooks library. +allows such reservations to be created both in the Kea configuration +file and in the host database backend, via the ``host-cmds`` hook library. This setting is currently supported by the most popular host database -backends, i.e. MySQL and PostgreSQL. It is not supported for Cassandra, -Host Cache (see :ref:`hooks-host-cache`) or Radius backend +backends, i.e. MySQL and PostgreSQL. +Host Cache (see :ref:`hooks-host-cache`), or the RADIUS backend (see :ref:`hooks-radius`). An attempt to set ``ip-reservations-unique`` to ``false`` when any of these three backends is in use yields a configuration error. .. note:: - When ``ip-reservations-unique`` is set to ``true`` (the default value) + When ``ip-reservations-unique`` is set to ``true`` (the default value), the server ensures that IP reservations are unique for a subnet within a single host backend and/or Kea configuration file. It does not guarantee that the reservations are unique across multiple backends. -The following is the example configuration with two reservations for -the same IPv6 address and for different MAC addresses: +The following is an example configuration with two reservations for +the same IPv6 address but different MAC addresses: :: @@ -4693,11 +4741,11 @@ the same IPv6 address and for different ] } -It is possible to control the ``ip-reservations-unique`` via the +It is possible to control the ``ip-reservations-unique`` parameter via the :ref:`dhcp6-cb`. If the new setting of this parameter conflicts with -the currently used backends (backends do not support the new setting), -the new setting is ignored and the warning log message is output. -The backends continue to use the default setting, i.e. expecting that +the currently used backends (i.e. backends do not support the new setting), +the new setting is ignored and a warning log message is generated. +The backends continue to use the default setting, expecting that IP reservations are unique within each subnet. To allow the creation of non-unique IP reservations, the administrator must remove the backends which lack support for them from the configuration file. @@ -4705,54 +4753,61 @@ the backends which lack support for them Administrators must be careful when they have been using multiple reservations for the same IP address and/or delegated prefix and later decide to return to the default mode in which this is no longer allowed. -The administrators must make sure that at most one reservation for -the given IP address or delegated prefix exists within a subnet prior +They must make sure that at most one reservation for +a given IP address or delegated prefix exists within a subnet, prior to switching back to the default mode. If such duplicates are left in the configuration file, the server reports a configuration error. Leaving such reservations in the host databases does not cause configuration errors but may lead to lease allocation errors during -the server operation, when it unexpectedly finds multiple reservations +the server's operation, when it unexpectedly finds multiple reservations for the same IP address or delegated prefix. .. note:: - Currently the server does not verify whether multiple reservations for - the same IP address and/or delegated prefix exist in the host - databases (MySQL and/or PostgreSQL) when ``ip-reservations-unique`` + Currently the Kea server does not verify whether multiple reservations for + the same IP address and/or delegated prefix exist in + MySQL and/or PostgreSQL) host databases when ``ip-reservations-unique`` is updated from ``true`` to ``false``. This may cause issues with lease allocations. The administrator must ensure that there is at most one reservation for each IP address and/or delegated prefix - within each subnet prior to this configuration update. + within each subnet, prior to the configuration update. +The ``reservations-lookup-first`` is a boolean parameter which controls whether +host reservations lookup should be performed before lease lookup. This parameter +has effect only when multi-threading is disabled. When multi-threading is +enabled, host reservations lookup is always performed first to avoid lease +lookup resource locking. The ``reservations-lookup-first`` defaults to ``false`` +when multi-threading is disabled. .. _shared-network6: Shared Networks in DHCPv6 ========================= -DHCP servers use subnet information in two ways. First, it is used to -determine the point of attachment, or where the client is -connected to the network. Second, the subnet information is used to -group information pertaining to a specific location in the network. This -approach works well in general, but there are scenarios where the -boundaries are blurred. Sometimes it is useful to have more than one +DHCP servers use subnet information in two ways. It is used to +both determine the point of attachment, i.e. where the client is +connected to the network, and to +group information pertaining to a specific location in the network. +Sometimes it is useful to have more than one logical IP subnet being deployed on the same physical link. Understanding that two or more subnets are used on the same link requires additional logic in the DHCP server. This capability is called "shared -networks" in the Kea and ISC DHCP projects. (It is sometimes also -called "shared subnets"; in Microsoft's nomenclature it is called -"multinet.") - -There are many use cases where the feature is useful; the most common -example in IPv4 is when the server is running out of available -addresses in a subnet. This is less common in IPv6, but shared networks -are still useful in IPv6. One of the use cases is an exhaustion of IPv6- -delegated prefixes within a subnet; another is an +networks" in Kea, and sometimes also +"shared subnets"; in Microsoft's nomenclature it is called +"multinet." + +There are many cases where the shared networks feature is useful; here we explain +just a handful of the most common ones. The first and by far most common +use case is an existing IPv4 network that has grown and +is running out of available +address space. This is less common in IPv6, but shared networks +are still useful: for example, with the exhaustion of IPv6- +delegated prefixes within a subnet, or the desire to experiment with an addressing scheme. With the advent of IPv6 deployment and a vast address space, many organizations split the address space into subnets, deploy it, and then after a while discover that they want -to split it differently. In the transition period, they want both old -and new addressing to be available; thus the need for more than one +to split it differently. In the transition period, they want both the old +and new addressing to be available: thus the need for more than one subnet on the same physical link. Finally, the case of cable networks is directly applicable in IPv6. @@ -4767,12 +4822,12 @@ or prefix) from any of the pools defined the shared network. Internally, the server selects one of the subnets belonging to a shared network and tries to allocate a lease from this subnet. If the server is unable to allocate a lease from the selected -subnet (e.g., due to pool exhaustion), it will use another subnet from -the same shared network and will try to allocate a lease from this subnet, -etc. Therefore, the server will typically allocate all leases +subnet (e.g., due to pool exhaustion), it uses another subnet from +the same shared network and tries to allocate a lease from this subnet. +The server typically allocates all leases available in a given subnet before it starts allocating leases from other subnets belonging to the same shared network. However, in certain -situations the client can be allocated a lease from the other subnets +situations the client can be allocated a lease from another subnet before the pools in the first subnet get exhausted; this sometimes occurs when the client provides a hint that belongs to another subnet, or the client has reservations in a subnet other than the default. @@ -4783,7 +4838,7 @@ reservations in a subnet other than the all the addresses from the first subnet in a shared network before allocating addresses from other subnets. -In order to define a shared network an additional configuration scope is +To define a shared network, an additional configuration scope is introduced: :: @@ -4838,12 +4893,12 @@ of two or more subnets. However, for tes or a network with just a single subnet is allowed. This is not a recommended practice in production networks, as the shared network logic requires additional processing and thus lowers the -server's performance. To avoid unnecessary performance degradation, the +server's performance. To avoid unnecessary performance degradation, shared subnets should only be defined when required by the deployment. Shared networks provide an ability to specify many parameters in the shared network scope that apply to all subnets within it. If -necessary, it is possible to specify a parameter in the shared network scope and +necessary, it is possible to specify a parameter in the shared-network scope and then override its value in the subnet scope. For example: :: @@ -4898,56 +4953,56 @@ then override its value in the subnet sc ], } ] -In this example, there is a dns-servers option defined that is available +In this example, there is a ``dns-servers`` option defined that is available to clients in both subnets in this shared network. Also, the valid lifetime is set to 10 minutes (600s). However, the first subnet -overrides some of the values (valid lifetime is 20 minutes, different IP -address for dns-servers), but also adds its own option (unicast -address). Assuming a client asking for a server unicast and dns-servers +overrides some of the values (the valid lifetime is 20 minutes, there is a different IP +address for ``dns-servers``), but also adds its own option (the unicast +address). Assuming a client asking for server unicast and ``dns-servers`` options is assigned a lease from this subnet, it will get a lease for 20 -minutes and dns-servers, and be allowed to use server unicast at address +minutes and ``dns-servers``, and be allowed to use server unicast at address 2001:abcd::1. If the same client is assigned to the second subnet, it -will get a 10-minute lease, a dns-servers value of 2001:db8:cafe::1, and +will get a 10-minute lease, a ``dns-servers`` value of 2001:db8:cafe::1, and no server unicast. Some parameters must be the same in all subnets in the same shared network. This restriction applies to the ``interface`` and ``rapid-commit`` settings. The most convenient way is to define them on -the shared network scope, but they can be specified for each subnet. -However, care should be taken for each subnet to have the same value. +the shared-network scope, but they can be specified for each subnet. +However, each subnet must have the same value. .. note:: There is an inherent ambiguity when using clients that send multiple IA - options in a single request and shared-networks whose subnets have - different values for options and configuration parameters. The server + options in a single request, and shared-networks whose subnets have + different values for options and configuration parameters. The server sequentially processes IA options in the order that they occur in the - client's query. If the leases requested in the IA options end up being - fulfilled from different subnets then which parameters and options should - apply? Currently, the code will use the values from the last subnet of + client's query; if the leases requested in the IA options end up being + fulfilled from different subnets, which parameters and options should + apply? Currently, the code uses the values from the last subnet of the last IA option fulfilled. - We view this largely as a site configuration issue. A shared-network + We view this largely as a site configuration issue. A shared network generally means the same physical link, so services configured by options from subnet A should be as easily reachable from subnet B and vice versa. There are a number of ways to avoid this situation: - - Use the same values for options and parameters for subnets within the shared-network. - - Use subnet selectors or client class guards that ensure that for a single client's query, the same subnet will be used for all IA options in that query. - - Avoid using shared-networks with clients that send multiple IA options per query - + - Use the same values for options and parameters for subnets within the shared network. + - Use subnet selectors or client class guards that ensure that for a single client's query, the same subnet is used for all IA options in that query. + - Avoid using shared networks with clients that send multiple IA options per query. Local and Relayed Traffic in Shared Networks -------------------------------------------- -It is possible to specify an interface name at the shared network level +It is possible to specify an interface name at the shared network level, to tell the server that this specific shared network is reachable directly (not via relays) using the local network interface. As all subnets in a shared network are expected to be used on the same physical link, it is a configuration error to attempt to define a shared network using subnets that are reachable over different interfaces. In other words, all subnets within the shared network must have the same value -of the "interface" parameter. The following configuration is wrong. +for the ``interface`` parameter. The following configuration is an example +of what **NOT** to do: :: @@ -4972,8 +5027,8 @@ of the "interface" parameter. The follow ], } ] -To minimize the chance of the configuration errors, it is often more convenient -to simply specify the interface name once, at the shared network level, like +To minimize the chance of configuration errors, it is often more convenient +to simply specify the interface name once, at the shared-network level, as shown in the example below. :: @@ -4999,14 +5054,15 @@ shown in the example below. } ] -In case of the relayed traffic, the subnets are typically selected using +With relayed traffic, subnets are typically selected using the relay agents' addresses. If the subnets are used independently (not -grouped within a shared network) it is allowed to specify different relay -addresses for each of these subnets. When multiple subnets belong to a +grouped within a shared network), a different relay +address can be specified for each of these subnets. When multiple subnets belong to a shared network they must be selected via the same relay address and, similarly to the case of the local traffic described above, it is a configuration error to specify different relay addresses for the respective -subnets in the shared network. The following configuration is wrong. +subnets in the shared network. The following configuration is another example +of what **NOT** to do: :: @@ -5036,8 +5092,8 @@ subnets in the shared network. The follo } ] -Again, it is better to specify the relay address at the shared network -level and this value will be inherited by all subnets belonging to the +Again, it is better to specify the relay address at the shared-network +level; this value will be inherited by all subnets belonging to the shared network. :: @@ -5068,12 +5124,12 @@ always lead to a different behavior than case, the Kea server will initially select one of the subnets by matching the relay address in the client's packet with the subnet's configuration. However, it MAY end up using the other subnet (even though it does not match -the relay address) if the client already has a lease in this subnet, has a -host reservation in this subnet or simply the initially selected subnet has no +the relay address) if the client already has a lease in this subnet or has a +host reservation in this subnet, or simply if the initially selected subnet has no more addresses available. Therefore, it is strongly recommended to always -specify subnet selectors (interface or a relay address) at shared network +specify subnet selectors (interface or relay address) at the shared-network level if the subnets belong to a shared network, as it is rarely useful to -specify them at the subnet level and it may lead to the configuration errors +specify them at the subnet level and may lead to the configuration errors described above. Client Classification in Shared Networks @@ -5086,12 +5142,12 @@ classification can be applied to subnets the same way as it is used for subnets specified outside of shared networks. It is important to understand how the server selects subnets for clients when client classification is in use, to ensure that the -desired subnet is selected for a given client type. +appropriate subnet is selected for a given client type. If a subnet is associated with a class, only the clients belonging to this class can use this subnet. If there are no classes specified for a subnet, any client connected to a given shared network can use this -subnet. A common mistake is to assume that the subnet including a client +subnet. A common mistake is to assume that the subnet that includes a client class is preferred over subnets without client classes. Consider the following example: @@ -5131,9 +5187,9 @@ subnet 2001:db8:3::/64 will be used (or server can use either of the two subnets, because the subnet 2001:db8:1::/64 is also allowed for this client. The client classification used in this case should be perceived as a way to -restrict access to certain subnets, rather than a way to express subnet +restrict access to certain subnets, rather than as a way to express subnet preference. For example, if the client does not belong to the "b-devices" -class it may only use the subnet 2001:db8:1::/64 and will never use the +class, it may only use the subnet 2001:db8:1::/64 and will never use the subnet 2001:db8:3::/64. A typical use case for client classification is in a cable network, @@ -5180,22 +5236,22 @@ on option 1234 values. } In this example each class has its own restriction. Only clients that -belong to class "a-devices" will be able to use subnet 2001:db8:1::/64 -and only clients belonging to "b-devices" will be able to use subnet +belong to class "a-devices" are able to use subnet 2001:db8:1::/64 +and only clients belonging to "b-devices" are able to use subnet 2001:db8:3::/64. Care should be taken not to define too-restrictive classification rules, as clients that are unable to use any subnets will be refused service. However, this may be a desired outcome if one wishes to provide service only to clients with known properties (e.g. only VoIP phones allowed on a given link). -Note that it is possible to achieve an effect similar to the one +It is possible to achieve an effect similar to the one presented in this section without the use of shared networks. If the subnets are placed in the global subnets scope, rather than in the shared network, the server will still use classification rules to pick the right subnet for a given class of devices. The major benefit of placing subnets within the shared network is that common parameters for the logically grouped subnets can be specified once, in the shared -network scope, e.g. the "interface" or "relay" parameter. All subnets +network scope, e.g. the ``interface`` or ``relay`` parameter. All subnets belonging to this shared network will inherit those parameters. Host Reservations in Shared Networks @@ -5244,20 +5300,20 @@ similar to regular subnets: It is worth noting that Kea conducts additional checks when processing a packet if shared networks are defined. First, instead of simply checking -whether there's a reservation for a given client in its initially +whether there is a reservation for a given client in its initially selected subnet, Kea looks through all subnets in a shared network for a reservation. This is one of the reasons why defining a shared network may impact performance. If there is a reservation for a client in any -subnet, that particular subnet will be picked for the client. Although -it is technically not an error, it is considered a bad practice to define +subnet, that particular subnet is picked for the client. Although +it is technically not an error, it is considered bad practice to define reservations for the same host in multiple subnets belonging to the same shared network. While not strictly mandatory, it is strongly recommended to use explicit "id" values for subnets if database storage will be used for host reservations. If an ID is not specified, the values for it are -auto generated, i.e. it assigns increasing integer values starting from -1. Thus, the auto generated IDs are not stable across configuration +auto generated, i.e. Kea assigns increasing integer values starting from +1. Thus, the auto-generated IDs are not stable across configuration changes. .. _dhcp6-serverid: @@ -5277,7 +5333,7 @@ restarts of the server and so is a stabl Kea follows the recommendation from `RFC 8415 `__ to use DUID-LLT as the default server identifier. However, ISC has received reports that some -deployments require different DUID types, and there is a need to +deployments require different DUID types, and that there is a need to administratively select both the DUID type and/or its contents. The server identifier can be configured using parameters within the @@ -5299,23 +5355,23 @@ Currently supported values for the ``typ When a new DUID type is selected, the server generates its value and replaces any existing DUID in the file. The server then uses the new -server identifier in all future interactions with the clients. +server identifier in all future interactions with clients. .. note:: If the new server identifier is created after some clients have obtained their leases, the clients using the old identifier are not - able to renew the leases; the server will ignore messages containing - the old server identifier. Clients will continue sending Renew until + able to renew their leases; the server will ignore messages containing + the old server identifier. Clients will continue sending RENEW until they transition to the rebinding state. In this state, they will - start sending Rebind messages to the multicast address without a - server identifier. The server will respond to the Rebind messages + start sending REBIND messages to the multicast address without a + server identifier. The server will respond to the REBIND messages with a new server identifier, and the clients will associate the new server identifier with their leases. Although the clients will be able to keep their leases and will eventually learn the new server identifier, this will be at the cost of an increased number of renewals and multicast traffic due to a need to rebind. Therefore, it - is recommended that modification of the server identifier type and + is recommended that modification of the server-identifier type and value be avoided if the server has already assigned leases and these leases are still valid. @@ -5352,12 +5408,12 @@ configuration specified above is: 00:01:00:08:96:23:AB:E6:A6:5D:C7:41:0F:05 |type |htype| time | identifier | -A special value of 0 for "htype" and "time" is allowed, which indicates +A special value of "0" for ``htype`` and ``time`` is allowed, which indicates that the server should use ANY value for these components. If the server already uses a DUID-LLT, it will use the values from this DUID; if the -server uses a DUID of a different type or doesn't yet use any DUID, it -will generate these values. Similarly, if the "identifier" is assigned -an empty string, the value of the identifier will be generated. Omitting +server uses a DUID of a different type or does not yet use any DUID, it +will generate these values. Similarly, if the ``identifier`` is assigned +an empty string, the value of the ``identifier`` will be generated. Omitting any of these parameters is equivalent to setting them to those special values. @@ -5414,12 +5470,12 @@ configuration above is: |type | ent-id | identifier | As in the case of the DUID-LLT, special values can be used for the -configuration of the DUID-EN. If the ``enterprise-id`` is 0, the server +configuration of the DUID-EN. If the ``enterprise-id`` is "0", the server will use a value from the existing DUID-EN. If the server is not using any DUID or the existing DUID has a different type, the ISC enterprise -id will be used. When an empty string is entered for ``identifier``, the +ID will be used. When an empty string is entered for ``identifier``, the identifier from the existing DUID-EN will be used. If the server is not -using any DUID-EN, a new 6-byte-long identifier will be generated. +using any DUID-EN, a new 6-byte-long ``identifier`` will be generated. DUID-LL is configured in the same way as DUID-LLT except that the ``time`` parameter has no effect for DUID-LL, because this DUID type @@ -5445,7 +5501,7 @@ which will result in the following serve |type |htype| identifier | The server stores the generated server identifier in the following -location: [kea-install-dir]/var/lib/kea/kea-dhcp6-serverid. +location: ``[kea-install-dir]/var/lib/kea/kea-dhcp6-serverid``. In some uncommon deployments where no stable storage is available, the server should be configured not to try to store the server identifier. @@ -5464,12 +5520,12 @@ parameter: ... } -The default value of the "persist" parameter is ``true``, which +The default value of the ``persist`` parameter is ``true``, which configures the server to store the server identifier on a disk. In the example above, the server is configured not to store the generated server identifier on a disk. But if the server identifier is -not modified in the configuration, the same value will be used after +not modified in the configuration, the same value is used after server restart, because the entire server identifier is explicitly specified in the configuration. @@ -5481,7 +5537,7 @@ DHCPv6 Data Directory The Kea DHCPv6 server puts the server identifier file and the default memory lease file into its data directory. By default this directory is ``prefix/var/lib/kea`` but this location can be changed using the -``data-directory`` global parameter as in: +``data-directory`` global parameter, as in: :: @@ -5492,21 +5548,20 @@ memory lease file into its data director .. _stateless-dhcp6: -Stateless DHCPv6 (Information-Request Message) +Stateless DHCPv6 (INFORMATION-REQUEST Message) ============================================== Typically DHCPv6 is used to assign both addresses and options. These assignments (leases) have a state that changes over time, hence their -description as stateful. DHCPv6 also supports a stateless mode, where clients -request configuration options only. This mode is considered lightweight -from the server perspective, as it does not require any state tracking, -and carries the stateless name. - -The Kea server supports stateless mode. Clients can send -Information-Request messages and the server sends back answers with the -requested options, providing the options are available in the server +description as "stateful." DHCPv6 also supports a "stateless" mode, where clients +request only configuration options. This mode is considered lightweight +from the server perspective, as it does not require any state tracking. + +The Kea server supports stateless mode. When clients send +INFORMATION-REQUEST messages, the server sends back answers with the +requested options, if they are available in the server configuration. The server attempts to use per-subnet options first; if -that fails for any reason, it then tries to provide options +that fails, it then tries to provide options defined in the global scope. Stateless and stateful mode can be used together. No special @@ -5514,10 +5569,9 @@ configuration directives are required to configuration for stateful clients and the stateless clients will get only the options they requested. -This usage of global options allows for an interesting case. It is -possible to run a server that provides only options and no addresses or +It is possible to run a server that provides only options and no addresses or prefixes. If the options have the same value in each subnet, the -configuration can define required options in the global scope and skip +configuration can define the required options in the global scope and skip subnet definitions altogether. Here's a simple example of such a configuration: @@ -5537,8 +5591,8 @@ configuration: } This very simple configuration provides DNS server information to -all clients in the network, regardless of their location. Note the -specification of the memfile lease database; this is needed as Kea +all clients in the network, regardless of their location. The +memfile lease database must be specified, as Kea requires a lease database to be specified even if it is not used. .. _dhcp6-rfc7550: @@ -5549,7 +5603,7 @@ Support for RFC 7550 (now part of RFC 84 `RFC 7550 `__ introduced some changes to the previous DHCPv6 specifications, `RFC 3315 `__ and `RFC -3633 `__, to resolve a few issues +3633 `__, to resolve issues with the coexistence of multiple stateful options in the messages sent between clients and servers. Those changes were later included in the most recent DHCPv6 protocol specification, `RFC @@ -5560,22 +5614,22 @@ changes, which are briefly described bel When a client, such as a requesting router, requests an allocation of both addresses and prefixes during the 4-way (SARR) exchange with the -server, and the server is not configured to allocate any prefixes but it +server, and the server is not configured to allocate any prefixes but can allocate some addresses, it will respond with the IA_NA(s) containing allocated addresses and the IA_PD(s) containing the NoPrefixAvail status code. According to the updated specifications, if the client can operate without prefixes it should accept allocated addresses and transition to the "bound" state. When the client -subsequently sends Renew/Rebind messages to the server, according to the -T1 and T2 times, to extend the lifetimes of the allocated addresses, and +subsequently sends RENEW/REBIND messages to the server to extend the +lifetimes of the allocated addresses, according to the T1 and T2 times, and if the client is still interested in obtaining prefixes from the server, -it may also include an IA_PD in the Renew/Rebind to request allocation +it may also include an IA_PD in the RENEW/REBIND to request allocation of the prefixes. If the server still cannot allocate the prefixes, it will respond with the IA_PD(s) containing the NoPrefixAvail status code. -However, if the server can allocate the prefixes it will allocate and -send them in the IA_PD(s) to the client. A similar situation occurs when +However, if the server can allocate the prefixes, it allocates and +sends them in the IA_PD(s) to the client. A similar situation occurs when the server is unable to allocate addresses for the client but can -delegate prefixes. The client may request allocation of the addresses +delegate prefixes: the client may request allocation of the addresses while renewing the delegated prefixes. Allocating leases for other IA types while renewing existing leases is by default supported by the Kea DHCPv6 server, and the server provides no configuration mechanisms to @@ -5591,7 +5645,7 @@ DHCPv6 server: time (in a single message exchange). - Place NoAddrsAvail and NoPrefixAvail status codes in the IA_NA and - IA_PD options in the Advertise message, rather than as the top-level + IA_PD options in the ADVERTISE message, rather than as the top-level options. .. _dhcp6-relay-override: @@ -5605,28 +5659,26 @@ relays. .. note:: - Starting with Kea 1.7.9, the order used to find a subnet which matches - required conditions to be selected is the ascending subnet identifier - order. When the selected subnet is a member of a shared network the + When the selected subnet is a member of a shared network, the whole shared network is selected. -The relay must have an interface connected to the link on which the +A relay must have an interface connected to the link on which the clients are being configured. Typically the relay has a global IPv6 address configured on that interface, which belongs to the subnet from -which the server will assign addresses. Normally, the server is able to -use the IPv6 address inserted by the relay (in the link-addr field in -RELAY-FORW message) to select the appropriate subnet. +which the server assigns addresses. Normally, the server is able to +use the IPv6 address inserted by the relay (in the ``link-addr`` field in +the RELAY-FORW message) to select the appropriate subnet. -However, that is not always the case. The relay address may not match +However, that is not always the case; the relay address may not match the subnet in certain deployments. This usually means that there is more than one subnet allocated for a given link. The two most common examples -where this is the case are long-lasting network renumbering (where both the +of this are long-lasting network renumbering (where both the old and new address spaces are still being used) and a cable network. In a cable network, both cable modems and the devices behind them are physically connected to the same link, yet they use distinct addressing. -In such a case, the DHCPv6 server needs additional information (like the -value of the interface-id option or the IPv6 address inserted in the -link-addr field in the RELAY-FORW message) to properly select an +In such a case, the DHCPv6 server needs additional information (the +value of the ``interface-id`` option or the IPv6 address inserted in the +``link-addr`` field in the RELAY-FORW message) to properly select an appropriate subnet. The following example assumes that there is a subnet 2001:db8:1::/64 @@ -5653,13 +5705,8 @@ selects that subnet for a relay with add ] } -If "relay" is specified, the "ip-addresses" parameter within it is -mandatory. - -.. note:: - - The current version of Kea uses the "ip-addresses" parameter, which - supports specifying a list of addresses. +If ``relay`` is specified, the ``ip-addresses`` parameter within it is +mandatory. The ``ip-addresses`` parameter supports specifying a list of addresses. .. _dhcp6-client-class-relay: @@ -5667,17 +5714,17 @@ Segregating IPv6 Clients in a Cable Netw =========================================== In certain cases, it is useful to mix relay address information -(introduced in :ref:`dhcp6-relay-override`), with client classification, explained -in :ref:`classify`. One specific example is in a cable network, +(introduced in :ref:`dhcp6-relay-override`) with client classification (explained +in :ref:`classify`). One specific example is in a cable network, where modems typically get addresses from a different subnet than all the devices connected behind them. -Let us assume that there is one CMTS (Cable Modem Termination System) +Let us assume that there is one Cable Modem Termination System (CMTS) with one CM MAC (a physical link that modems are connected to). We want the modems to get addresses from the 3000::/64 subnet, while everything -connected behind the modems should get addresses from another subnet -(2001:db8:1::/64). The CMTS that acts as a relay uses address 3000::1. -The following configuration can serve that configuration: +connected behind the modems should get addresses from the 2001:db8:1::/64 +subnet. The CMTS that acts as a relay uses address 3000::1. +The following configuration can serve that situation: :: @@ -5712,28 +5759,22 @@ The following configuration can serve th MAC/Hardware Addresses in DHCPv6 ================================ -MAC/hardware addresses are available in DHCPv4 messages from the +MAC/hardware addresses are available in DHCPv4 messages from clients, and administrators frequently use that information to perform certain tasks like per-host configuration and address reservation for specific MAC addresses. Unfortunately, the DHCPv6 protocol does not provide any completely reliable way to retrieve that information. To mitigate that issue, a number of mechanisms have been implemented in -Kea. Each of these mechanisms works in certain cases, but may fail in +Kea. Each of these mechanisms works in certain cases, but may not in others. Whether the mechanism works in a particular deployment is somewhat dependent on the network topology and the technologies used. Kea allows specification of which of the supported methods should be -used and in what order. This configuration may be considered a fine -tuning of the DHCP deployment. In a typical deployment the default value -of ``"any"`` is sufficient and there is no need to select specific -methods. Changing the value of this parameter is most useful in -cases when an administrator wants to disable certain methods; for -example, if the administrator trusts the network infrastructure more -than the information provided by the clients themselves, they may prefer -information provided by the relays over that provided by clients. +used and in what order, via the ``mac-sources`` parameter. This configuration +may be considered a fine +tuning of the DHCP deployment. -The configuration is controlled by the ``mac-sources`` parameter as -follows: +Here is an example: :: @@ -5745,14 +5786,21 @@ follows: ... } -When not specified, a special value of "any" is used, which instructs +When not specified, a value of "any" is used, which instructs the server to attempt to try all the methods in sequence and use the -value returned by the first one that succeeds. If specified, it must -have at least one value. +value returned by the first one that succeeds. In a typical deployment the default value +of "any" is sufficient and there is no need to select specific +methods. Changing the value of this parameter is most useful in +cases when an administrator wants to disable certain methods; for +example, if the administrator trusts the network infrastructure more +than the information provided by the clients themselves, they may prefer +information provided by the relays over that provided by clients. + +If specified, ``mac-sources`` must have at least one value. Supported methods are: -- ``any`` - not an actual method, just a keyword that instructs Kea to +- ``any`` - this is not an actual method, just a keyword that instructs Kea to try all other methods and use the first one that succeeds. This is the default operation if no ``mac-sources`` are defined. @@ -5778,7 +5826,7 @@ Supported methods are: link-local address types. In particular, privacy extensions, defined in `RFC 4941 `__, do not use MAC addresses. Also note that successful extraction requires that the - address's u-bit must be set to 1 and its g-bit set to 0, indicating + address's u-bit must be set to "1" and its g-bit set to "0", indicating that it is an interface identifier as per `RFC 2373, section 2.5.1 `__. @@ -5788,66 +5836,63 @@ Supported methods are: option that is inserted by a relay and contains information about a client's MAC address. This method requires a relay agent that supports the option and is configured to insert it. This method is - useless for directly connected clients. This parameter can also be - specified as ``rfc6939``, which is an alias for + useless for directly connected clients. The value ``rfc6939`` is an alias for ``client-link-addr-option``. - ``remote-id`` - `RFC 4649 `__ - defines a remote-id option that is inserted by a relay agent. + defines a ``remote-id`` option that is inserted by a relay agent. Depending on the relay agent configuration, the inserted option may - convey the client's MAC address information. This parameter can also - be specified as ``rfc4649``, which is an alias for ``remote-id``. + convey the client's MAC address information. The value ``rfc4649`` + is an alias for ``remote-id``. -- ``subscriber-id`` - Another option that is somewhat similar to the - previous one is subscriber-id, defined in `RFC - 4580 `__. It, too, is inserted by - a relay agent that is configured to insert it. This parameter can - also be specified as ``rfc4580``, which is an alias for +- ``subscriber-id`` - Defined in `RFC 4580 `__, + ``subscriber-id`` is somewhat similar to ``remote-id``; it is also inserted + by a relay agent. The value ``rfc4580`` is an alias for ``subscriber-id``. This method is currently not implemented. - ``docsis-cmts`` - Yet another possible source of MAC address information are the DOCSIS options inserted by a CMTS that acts as a DHCPv6 relay agent in cable networks. This method attempts to extract MAC address information from sub-option 1026 (cm mac) of the - vendor-specific option with vendor-id=4491. This vendor option is - extracted from the relay-forward message, not the original client's + vendor-specific option with ``vendor-id=4491``. This vendor option is + extracted from the Relay-forward message, not the original client's message. - ``docsis-modem`` - The final possible source of MAC address information are the DOCSIS options inserted by the cable modem itself. This method attempts to extract MAC address information from - sub-option 36 (device id) of the vendor-specific option with - vendor-id=4491. This vendor option is extracted from the original + sub-option 36 (``device-id``) of the vendor-specific option with + ``vendor-id=4491``. This vendor option is extracted from the original client's message, not from any relay options. -Empty mac-sources are not allowed. Administrators who do not want to specify it -should either simply omit the mac-sources definition or specify it with the +An empty ``mac-sources`` parameter is not allowed. Administrators who do not want to specify it +should either simply omit the ``mac-sources`` definition or specify it with the "any" value, which is the default. .. _dhcp6-decline: -Duplicate Addresses (DECLINE Support) -===================================== +Duplicate Addresses (DHCPDECLINE Support) +========================================= The DHCPv6 server is configured with a certain pool of addresses that it is expected to hand out to DHCPv6 clients. It is assumed that the server is authoritative and has complete jurisdiction over those addresses. -However, for various reasons, such as misconfiguration or a faulty +However, for various reasons such as misconfiguration or a faulty client implementation that retains its address beyond the valid lifetime, there may be devices connected that use those addresses without the server's approval or knowledge. Such an unwelcome event can be detected by legitimate clients (using Duplicate Address Detection) and reported to the DHCPv6 server using a -DHCPDECLINE message. The server will do a sanity check (to see whether -the client declining an address really was supposed to use it), and then -will conduct a clean-up operation and confirm it by sending back a REPLY -message. Any DNS entries related to that address will be removed, the -fact will be logged, and hooks will be triggered. After that is -complete, the address will be marked as declined (which indicates that +DHCPDECLINE message. The server does a sanity check (to see whether +the client declining an address really was supposed to use it), then +conducts a clean-up operation, and confirms the DHCPDECLINE by sending back a REPLY +message. Any DNS entries related to that address are removed, the +event is logged, and hooks are triggered. After that is +complete, the address is marked as declined (which indicates that it is used by an unknown entity and thus not available for assignment) -and a probation time will be set on it. Unless otherwise configured, the -probation period lasts 24 hours; after that period, the server will +and a probation time is set on it. Unless otherwise configured, the +probation period lasts 24 hours; after that time, the server will recover the lease (i.e. put it back into the available state) and the address will be available for assignment again. It should be noted that if the underlying issue of a misconfigured device is not resolved, the @@ -5866,33 +5911,33 @@ default, the following syntax can be use ... } -The parameter is expressed in seconds, so the example above will -instruct the server to recycle declined leases after one hour. +The parameter is expressed in seconds, so the example above +instructs the server to recycle declined leases after one hour. There are several statistics and hook points associated with the decline -handling procedure. The lease6_decline hook is triggered after the +handling procedure. The ``lease6_decline`` hook is triggered after the incoming DHCPDECLINE message has been sanitized and the server is about -to decline the lease. The declined-addresses statistic is increased -after the hook returns (both global and subnet-specific variants). (See +to decline the lease. The ``declined-addresses`` statistic is increased +after the hook returns (both the global and subnet-specific variants). (See :ref:`dhcp6-stats` and :ref:`hooks-libraries` for more details on DHCPv6 statistics and Kea hook points.) Once the probation time elapses, the declined lease is recovered using the standard expired-lease reclamation procedure, with several -additional steps. In particular, both declined-addresses statistics +additional steps. In particular, both ``declined-addresses`` statistics (global and subnet-specific) are decreased. At the same time, -reclaimed-declined-addresses statistics (again in two variants, global +``reclaimed-declined-addresses`` statistics (again in two variants, global and subnet-specific) are increased. -A note about statistics: The server does not decrease the -assigned-nas statistics when a DHCPDECLINE message is received and +A note about statistics: The Kea server does not decrease the +``assigned-nas`` statistics when a DHCPDECLINE message is received and processed successfully. While technically a declined address is no -longer assigned, the primary usage of the assigned-nas statistic +longer assigned, the primary usage of the ``assigned-nas`` statistic is to monitor pool utilization. Most people would forget to include -declined-addresses in the calculation, and simply use -assigned-nas/total-nas. This would cause a bias towards -under-representing pool utilization. As this has a potential for major -issues, ISC decided not to decrease assigned-nas immediately after +``declined-addresses`` in the calculation, and would simply use +``assigned-nas``/``total-nas``. This would cause a bias towards +under-representing pool utilization. As this has a potential to cause serious +confusion, ISC decided not to decrease ``assigned-nas`` immediately after receiving DHCPDECLINE, but to do it later when Kea recovers the address back to the available pool. @@ -5905,624 +5950,510 @@ The DHCPv6 server supports the following .. tabularcolumns:: |p{0.2\linewidth}|p{0.1\linewidth}|p{0.7\linewidth}| -.. table:: DHCPv6 Statistics +.. table:: DHCPv6 statistics :class: longtable :widths: 20 10 70 - +-----------------------------------------+-----------------------+------------------------+ - | Statistic | Data Type | Description | - +=========================================+=======================+========================+ - | pkt6-received | integer | Number of DHCPv6 | - | | | packets received. | - | | | This includes all | - | | | packets: valid, | - | | | bogus, corrupted, | - | | | rejected, etc. This | - | | | statistic is expected | - | | | to grow rapidly. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-receive-drop | integer | Number of incoming | - | | | packets that were | - | | | dropped. The exact | - | | | reason for dropping | - | | | packets is logged, | - | | | but the most common | - | | | reasons may be: an | - | | | unacceptable or not | - | | | supported packet type | - | | | is received, direct | - | | | responses are | - | | | forbidden, the | - | | | server-id sent by the | - | | | client does not match | - | | | the server's | - | | | server-id, or the | - | | | packet is malformed. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-parse-failed | integer | Number of incoming | - | | | packets that could | - | | | not be parsed. A | - | | | non-zero value of | - | | | this statistic | - | | | indicates that the | - | | | server received a | - | | | malformed or | - | | | truncated packet. | - | | | This may indicate | - | | | problems in the | - | | | network, faulty | - | | | clients, faulty relay | - | | | agents, or a bug in | - | | | the server. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-solicit-received | integer | Number of SOLICIT | - | | | packets received. | - | | | This statistic is | - | | | expected to grow; its | - | | | increase means that | - | | | clients that just | - | | | booted started their | - | | | configuration process | - | | | and their initial | - | | | packets reached the | - | | | Kea server. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-advertise-received | integer | Number of ADVERTISE | - | | | packets received. | - | | | Advertise packets are | - | | | sent by the server | - | | | and the server is | - | | | never expected to | - | | | receive them. A | - | | | non-zero value of | - | | | this statistic | - | | | indicates an error | - | | | occurring in the | - | | | network. One likely | - | | | cause would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | ADVERTISE messages | - | | | towards the server, | - | | | rather than back to | - | | | the clients. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-request-received | integer | Number of DHCPREQUEST | - | | | packets received. | - | | | This statistic is | - | | | expected to grow. Its | - | | | increase means that | - | | | clients that just | - | | | booted received the | - | | | server's response | - | | | (DHCPADVERTISE) and | - | | | accepted it, and are | - | | | now requesting an | - | | | address | - | | | (DHCPREQUEST). | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-reply-received | integer | Number of REPLY | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | zero at all times, as | - | | | REPLY packets are | - | | | sent by the server | - | | | and the server is | - | | | never expected to | - | | | receive them. A | - | | | non-zero value | - | | | indicates an error. | - | | | One likely cause | - | | | would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | REPLY messages | - | | | towards the server, | - | | | rather than back to | - | | | the clients. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-renew-received | integer | Number of RENEW | - | | | packets received. | - | | | This statistic is | - | | | expected to grow; its | - | | | increase means that | - | | | clients received | - | | | their addresses and | - | | | prefixes and are | - | | | trying to renew them. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-rebind-received | integer | Number of REBIND | - | | | packets received. A | - | | | non-zero value | - | | | indicates that | - | | | clients did not | - | | | receive responses to | - | | | their RENEW messages | - | | | (through the regular | - | | | lease-renewal | - | | | mechanism) and are | - | | | attempting to find | - | | | any server that is | - | | | able to take over | - | | | their leases. It may | - | | | mean that some | - | | | servers' REPLY | - | | | messages never | - | | | reached the clients. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-release-received | integer | Number of RELEASE | - | | | packets received. | - | | | This statistic is | - | | | expected to grow when | - | | | a device is being | - | | | shut down in the | - | | | network; it indicates | - | | | that the address or | - | | | prefix assigned is | - | | | reported as no longer | - | | | needed. Note that | - | | | many devices, | - | | | especially wireless, | - | | | do not send RELEASE | - | | | packets either | - | | | because of design | - | | | choice or due to the | - | | | client moving out of | - | | | range. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-decline-received | integer | Number of DECLINE | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | close to zero. Its | - | | | increase means that a | - | | | client leased an | - | | | address, but | - | | | discovered that the | - | | | address is currently | - | | | used by an unknown | - | | | device in the | - | | | network. If this | - | | | statistic is growing, | - | | | it may indicate a | - | | | misconfigured server | - | | | or devices that have | - | | | statically assigned | - | | | conflicting | - | | | addresses. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-infrequest-received | integer | Number of | - | | | INFORMATION-REQUEST | - | | | packets received. | - | | | This statistic is | - | | | expected to grow if | - | | | there are devices | - | | | that are using | - | | | stateless DHCPv6. | - | | | INFORMATION-REQUEST | - | | | messages are used by | - | | | clients that request | - | | | stateless | - | | | configuration, i.e. | - | | | options and | - | | | parameters other than | - | | | addresses or | - | | | prefixes. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-dhcpv4-query-received | integer | Number of | - | | | DHCPv4-QUERY packets | - | | | received. This | - | | | statistic is expected | - | | | to grow if there are | - | | | devices that are | - | | | using | - | | | DHCPv4-over-DHCPv6. | - | | | DHCPv4-QUERY messages | - | | | are used by DHCPv4 | - | | | clients on an | - | | | IPv6-only line which | - | | | encapsulates the | - | | | requests over DHCPv6. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-dhcpv4-response-received | integer | Number of | - | | | DHCPv4-RESPONSE | - | | | packets received. | - | | | This statistic is | - | | | expected to remain | - | | | zero at all times, as | - | | | DHCPv4-RESPONSE | - | | | packets are sent by | - | | | the server and the | - | | | server is never | - | | | expected to receive | - | | | them. A non-zero | - | | | value indicates an | - | | | error. One likely | - | | | cause would be a | - | | | misbehaving relay | - | | | agent that | - | | | incorrectly forwards | - | | | DHCPv4-RESPONSE | - | | | message towards the | - | | | server rather than | - | | | back to the clients. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-unknown-received | integer | Number of packets | - | | | received of an | - | | | unknown type. A | - | | | non-zero value of | - | | | this statistic | - | | | indicates that the | - | | | server received a | - | | | packet that it wasn't | - | | | able to recognize; | - | | | either it had an | - | | | unsupported type or | - | | | was possibly | - | | | malformed. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-sent | integer | Number of DHCPv6 | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow every time | - | | | the server transmits | - | | | a packet. In general, | - | | | it should roughly | - | | | match pkt6-received, | - | | | as most incoming | - | | | packets cause the | - | | | server to respond. | - | | | There are exceptions | - | | | (e.g. server | - | | | receiving a REQUEST | - | | | with server-id | - | | | matching another | - | | | server), so do not | - | | | worry if it is less | - | | | than pkt6-received. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-advertise-sent | integer | Number of ADVERTISE | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow in most cases | - | | | after a SOLICIT is | - | | | processed. There are | - | | | certain uncommon, but | - | | | valid, cases where | - | | | incoming SOLICIT | - | | | packets are dropped, | - | | | but in general this | - | | | statistic is expected | - | | | to be close to | - | | | pkt6-solicit-received. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-reply-sent | integer | Number of REPLY | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow in most cases | - | | | after a SOLICIT (with | - | | | rapid-commit), | - | | | REQUEST, RENEW, | - | | | REBIND, RELEASE, | - | | | DECLINE, or | - | | | INFORMATION-REQUEST | - | | | is processed. There | - | | | are certain cases | - | | | where there is no | - | | | response. | - +-----------------------------------------+-----------------------+------------------------+ - | pkt6-dhcpv4-response-sent | integer | Number of | - | | | DHCPv4-RESPONSE | - | | | packets sent. This | - | | | statistic is expected | - | | | to grow in most cases | - | | | after a DHCPv4-QUERY | - | | | is processed. There | - | | | are certain cases | - | | | where there is no | - | | | response. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].total-nas | integer | Total number of NA | - | | | addresses available | - | | | for DHCPv6 management | - | | | for a given subnet; | - | | | in other words, this | - | | | is the sum of all | - | | | addresses in all | - | | | configured pools. | - | | | This statistic | - | | | changes only during | - | | | configuration | - | | | changes. Note that it | - | | | does not take into | - | | | account any addresses | - | | | that may be reserved | - | | | due to host | - | | | reservation. The *id* | - | | | is the subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | cumulative-assigned-nas | integer | Cumulative number of | - | | | NA addresses that | - | | | have been assigned | - | | | since server startup. | - | | | It is incremented | - | | | each time a NA address | - | | | is assigned and is not | - | | | reset when the server | - | | | is reconfigured. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].cumulative-assigned-nas | integer | Cumulative number of | - | | | NA addresses in a | - | | | given subnet that | - | | | were assigned. It | - | | | increases every time | - | | | a new lease is | - | | | allocated (as a | - | | | result of receiving a | - | | | REQUEST message) and | - | | | is never decreased. | - | | | The *id* is the | - | | | subnet-id of a given | - | | | subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].assigned-nas | integer | Number of NA | - | | | addresses in a given | - | | | subnet that are | - | | | assigned. It | - | | | increases every time | - | | | a new lease is | - | | | allocated (as a | - | | | result of receiving a | - | | | REQUEST message) and | - | | | is decreased every | - | | | time a lease is | - | | | released (a RELEASE | - | | | message is received) | - | | | or expires. The *id* | - | | | is the subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].total-pds | integer | Total number of PD | - | | | prefixes available | - | | | for DHCPv6 management | - | | | for a given subnet; | - | | | in other words, this | - | | | is the sum of all | - | | | prefixes in all | - | | | configured pools. | - | | | This statistic | - | | | changes only during | - | | | configuration | - | | | changes. Note it does | - | | | not take into account | - | | | any prefixes that may | - | | | be reserved due to | - | | | host reservation. The | - | | | *id* is the subnet-id | - | | | of a given subnet. | - | | | This statistic is | - | | | exposed for each | - | | | subnet separately, | - | | | and is reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | cumulative-assigned-pds | integer | Cumulative number of | - | | | PD prefixes that | - | | | have been assigned | - | | | since server startup. | - | | | It is incremented | - | | | each time a PD prefix | - | | | is assigned and is not | - | | | reset when the server | - | | | is reconfigured. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].cumulative-assigned-pds | integer | Cumulative number of | - | | | PD prefixes in a | - | | | given subnet that | - | | | were assigned. It | - | | | increases every time | - | | | a new lease is | - | | | allocated (as a | - | | | result of receiving a | - | | | REQUEST message) and | - | | | is never decreased. | - | | | The *id* is the | - | | | subnet-id of a given | - | | | subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].assigned-pds | integer | Number of PD prefixes | - | | | in a given subnet | - | | | that are assigned. It | - | | | increases every time | - | | | a new lease is | - | | | allocated (as a | - | | | result of receiving a | - | | | REQUEST message) and | - | | | is decreased every | - | | | time a lease is | - | | | released (a RELEASE | - | | | message is received) | - | | | or expires. The *id* | - | | | is the subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately, and is | - | | | reset during a | - | | | reconfiguration | - | | | event. | - +-----------------------------------------+-----------------------+------------------------+ - | reclaimed-leases | integer | Number of expired | - | | | leases that have been | - | | | reclaimed since | - | | | server startup. It is | - | | | incremented each time | - | | | an expired lease is | - | | | reclaimed (counting | - | | | both NA and PD | - | | | reclamations). | - | | | This statistic never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual leases have been| - | | | reclaimed. | - | | | This is a global | - | | | statistic that covers | - | | | all subnets. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].reclaimed-leases | integer | Number of expired | - | | | leases associated | - | | | with a given subnet | - | | | (*"id"* is the | - | | | subnet-id) that have | - | | | been reclaimed since | - | | | server startup. It is | - | | | incremented each time | - | | | an expired lease is | - | | | reclaimed (counting | - | | | both NA and PD | - | | | reclamations). | - | | | The *id* is the | - | | | subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately. | - +-----------------------------------------+-----------------------+------------------------+ - | declined-addresses | integer | Number of IPv6 | - | | | addresses that are | - | | | currently declined; a | - | | | count of the number | - | | | of leases currently | - | | | unavailable. Once a | - | | | lease is recovered, | - | | | this statistic will | - | | | be decreased; | - | | | ideally, this | - | | | statistic should be | - | | | zero. If this | - | | | statistic is non-zero | - | | | or increasing, a | - | | | network administrator | - | | | should investigate | - | | | whether there is a | - | | | misbehaving device in | - | | | the network. This is | - | | | a global statistic | - | | | that covers all | - | | | subnets. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].declined-addresses | integer | Number of IPv6 | - | | | addresses that are | - | | | currently declined in | - | | | a given subnet; a | - | | | count of the number | - | | | of leases currently | - | | | unavailable. Once a | - | | | lease is recovered, | - | | | this statistic will | - | | | be decreased; | - | | | ideally, this | - | | | statistic should be | - | | | zero. If this | - | | | statistic is non-zero | - | | | or increasing, a | - | | | network administrator | - | | | should investigate | - | | | whether there is a | - | | | misbehaving device in | - | | | the network. The *id* | - | | | is the subnet-id of a | - | | | given subnet. This | - | | | statistic is exposed | - | | | for each subnet | - | | | separately. | - +-----------------------------------------+-----------------------+------------------------+ - | reclaimed-declined-addresses | integer | Number of IPv6 | - | | | addresses that were | - | | | declined, but have | - | | | now been recovered. | - | | | Unlike | - | | | declined-addresses, | - | | | this statistic never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual valid Declines | - | | | were processed and | - | | | recovered from. This | - | | | is a global statistic | - | | | that covers all | - | | | subnets. | - +-----------------------------------------+-----------------------+------------------------+ - | subnet[id].reclaimed-declined-addresses | integer | Number of IPv6 | - | | | addresses that were | - | | | declined, but have | - | | | now been recovered. | - | | | Unlike | - | | | declined-addresses, | - | | | this statistic never | - | | | decreases. It can be | - | | | used as a long-term | - | | | indicator of how many | - | | | actual valid Declines | - | | | were processed and | - | | | recovered from. The | - | | | *id* is the subnet-id | - | | | of a given subnet. | - | | | This statistic is | - | | | exposed for each | - | | | subnet separately. | - +-----------------------------------------+-----------------------+------------------------+ + +----------------------------------------------+----------------+------------------------------------+ + | Statistic | Data Type | Description | + +==============================================+================+====================================+ + | pkt6-received | integer | Number of DHCPv6 packets received. | + | | | This includes all packets: valid, | + | | | bogus, corrupted, rejected, etc. | + | | | This statistic is expected to grow | + | | | rapidly. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-receive-drop | integer | Number of incoming packets that | + | | | were dropped. The exact reason for | + | | | dropping packets is logged, but | + | | | the most common reasons may be: an | + | | | unacceptable or not supported | + | | | packet type is received, direct | + | | | responses are forbidden, the | + | | | server-id sent by the client does | + | | | not match the server's server-id, | + | | | or the packet is malformed. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-parse-failed | integer | Number of incoming packets that | + | | | could not be parsed. A non-zero | + | | | value of this statistic indicates | + | | | that the server received a | + | | | malformed or truncated packet. | + | | | This may indicate problems in the | + | | | network, faulty clients, faulty | + | | | relay agents, or a bug in the | + | | | server. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-solicit-received | integer | Number of SOLICIT packets | + | | | received. This statistic is | + | | | expected to grow; its increase | + | | | means that clients that just | + | | | booted started their configuration | + | | | process and their initial packets | + | | | reached the Kea server. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-advertise-received | integer | Number of ADVERTISE packets | + | | | received. ADVERTISE packets are | + | | | sent by the server and the server | + | | | is never expected to receive them. | + | | | A non-zero value of this statistic | + | | | indicates an error occurring in | + | | | the network. One likely cause | + | | | would be a misbehaving relay | + | | | agent that incorrectly forwards | + | | | ADVERTISE messages towards the | + | | | server, rather than back to the | + | | | clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-request-received | integer | Number of DHCPREQUEST packets | + | | | received. This statistic is | + | | | expected to grow. Its increase | + | | | means that clients that just | + | | | booted received the server's | + | | | response (DHCPADVERTISE) and | + | | | accepted it, and are now | + | | | requesting an address | + | | | (DHCPREQUEST). | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-reply-received | integer | Number of REPLY packets received. | + | | | This statistic is expected to | + | | | remain zero at all times, as REPLY | + | | | packets are sent by the server and | + | | | the server is never expected to | + | | | receive them. A non-zero value | + | | | indicates an error. One likely | + | | | cause would be a misbehaving relay | + | | | agent that incorrectly forwards | + | | | REPLY messages towards the server, | + | | | rather than back to the clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-renew-received | integer | Number of RENEW packets received. | + | | | This statistic is expected to | + | | | grow; its increase means that | + | | | clients received their addresses | + | | | and prefixes and are trying to | + | | | renew them. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-rebind-received | integer | Number of REBIND packets received. | + | | | A non-zero value indicates that | + | | | clients did not receive responses | + | | | to their RENEW messages (through | + | | | the regular lease-renewal | + | | | mechanism) and are attempting to | + | | | find any server that is able to | + | | | take over their leases. It may | + | | | mean that some servers' REPLY | + | | | messages never reached the | + | | | clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-release-received | integer | Number of RELEASE packets | + | | | received. This statistic is | + | | | expected to grow when a device is | + | | | being shut down in the network; it | + | | | indicates that the address or | + | | | prefix assigned is reported as no | + | | | longer needed. Note that many | + | | | devices, especially wireless, do | + | | | not send RELEASE packets either | + | | | because of design choice or due to | + | | | the client moving out of range. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-decline-received | integer | Number of DECLINE packets | + | | | received. This statistic is | + | | | expected to remain close to zero. | + | | | Its increase means that a client | + | | | leased an address, but discovered | + | | | that the address is currently used | + | | | by an unknown device in the | + | | | network. If this statistic is | + | | | growing, it may indicate a | + | | | misconfigured server or devices | + | | | that have statically assigned | + | | | conflicting addresses. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-infrequest-received | integer | Number of INFORMATION-REQUEST | + | | | packets received. This statistic | + | | | is expected to grow if there are | + | | | devices that are using stateless | + | | | DHCPv6. INFORMATION-REQUEST | + | | | messages are used by clients that | + | | | request stateless configuration, | + | | | i.e. options and parameters other | + | | | than addresses or prefixes. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-dhcpv4-query-received | integer | Number of DHCPv4-QUERY packets | + | | | received. This statistic is | + | | | expected to grow if there are | + | | | devices that are using | + | | | DHCPv4-over-DHCPv6. DHCPv4-QUERY | + | | | messages are used by DHCPv4 | + | | | clients on an IPv6-only line which | + | | | encapsulates the requests over | + | | | DHCPv6. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-dhcpv4-response-received | integer | Number of DHCPv4-RESPONSE packets | + | | | received. This statistic is | + | | | expected to remain zero at all | + | | | times, as DHCPv4-RESPONSE packets | + | | | are sent by the server and the | + | | | server is never expected to | + | | | receive them. A non-zero value | + | | | indicates an error. One likely | + | | | cause would be a misbehaving relay | + | | | agent that incorrectly forwards | + | | | DHCPv4-RESPONSE message towards | + | | | the server rather than back to the | + | | | clients. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-unknown-received | integer | Number of packets received of an | + | | | unknown type. A non-zero value of | + | | | this statistic indicates that the | + | | | server received a packet that it | + | | | was unable to recognize; either it | + | | | had an unsupported type or was | + | | | possibly malformed. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-sent | integer | Number of DHCPv6 packets sent. | + | | | This statistic is expected to grow | + | | | every time the server transmits a | + | | | packet. In general, it should | + | | | roughly match pkt6-received, as | + | | | most incoming packets cause the | + | | | server to respond. There are | + | | | exceptions (e.g. server receiving | + | | | a REQUEST with server-id matching | + | | | another server), so do not worry | + | | | if it is less than pkt6-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-advertise-sent | integer | Number of ADVERTISE packets sent. | + | | | This statistic is expected to grow | + | | | in most cases after a SOLICIT is | + | | | processed. There are certain | + | | | uncommon, but valid, cases where | + | | | incoming SOLICIT packets are | + | | | dropped, but in general this | + | | | statistic is expected to be close | + | | | to pkt6-solicit-received. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-reply-sent | integer | Number of REPLY packets sent. This | + | | | statistic is expected to grow in | + | | | most cases after a SOLICIT (with | + | | | rapid-commit), REQUEST, RENEW, | + | | | REBIND, RELEASE, DECLINE, or | + | | | INFORMATION-REQUEST is processed. | + | | | There are certain cases where | + | | | there is no response. | + +----------------------------------------------+----------------+------------------------------------+ + | pkt6-dhcpv4-response-sent | integer | Number of DHCPv4-RESPONSE packets | + | | | sent. This statistic is expected | + | | | to grow in most cases after a | + | | | DHCPv4-QUERY is processed. There | + | | | are certain cases where there is | + | | | no response. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].total-nas | integer | Total number of NA addresses | + | | | available for DHCPv6 management | + | | | for a given subnet; in other | + | | | words, this is the sum of all | + | | | addresses in all configured pools. | + | | | This statistic changes only during | + | | | configuration changes. Note that | + | | | it does not take into account any | + | | | addresses that may be reserved due | + | | | to host reservation. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | cumulative-assigned-nas | integer | Cumulative number of NA addresses | + | | | that have been assigned since | + | | | server startup. It is incremented | + | | | each time a NA address is assigned | + | | | and is not reset when the server | + | | | is reconfigured. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].cumulative-assigned-nas | integer | Cumulative number of NA addresses | + | | | in a given subnet that were | + | | | assigned. It increases every time | + | | | a new lease is allocated (as a | + | | | result of receiving a REQUEST | + | | | message) and is never decreased. | + | | | The *id* is the subnet-id of a | + | | | given subnet. This statistic is | + | | | exposed for each subnet | + | | | separately, and is reset during a | + | | | reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].assigned-nas | integer | Number of NA addresses in a given | + | | | subnet that are assigned. It | + | | | increases every time a new lease | + | | | is allocated (as a result of | + | | | receiving a REQUEST message) and | + | | | is decreased every time a lease is | + | | | released (a RELEASE message is | + | | | received) or expires. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].total-pds | integer | Total number of PD prefixes | + | | | available for DHCPv6 management | + | | | for a given subnet; in other | + | | | words, this is the sum of all | + | | | prefixes in all configured pools. | + | | | This statistic changes only during | + | | | configuration changes. Note it | + | | | does not take into account any | + | | | prefixes that may be reserved due | + | | | to host reservation. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | cumulative-assigned-pds | integer | Cumulative number of PD prefixes | + | | | that have been assigned since | + | | | server startup. It is incremented | + | | | each time a PD prefix is assigned | + | | | and is not reset when the server | + | | | is reconfigured. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].cumulative-assigned-pds | integer | Cumulative number of PD prefixes | + | | | in a given subnet that were | + | | | assigned. It increases every time | + | | | a new lease is allocated (as a | + | | | result of receiving a REQUEST | + | | | message) and is never decreased. | + | | | The *id* is the subnet-id of a | + | | | given subnet. This statistic is | + | | | exposed for each subnet | + | | | separately, and is reset during a | + | | | reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].assigned-pds | integer | Number of PD prefixes in a given | + | | | subnet that are assigned. It | + | | | increases every time a new lease | + | | | is allocated (as a result of | + | | | receiving a REQUEST message) and | + | | | is decreased every time a lease is | + | | | released (a RELEASE message is | + | | | received) or expires. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately, and is reset | + | | | during a reconfiguration event. | + +----------------------------------------------+----------------+------------------------------------+ + | reclaimed-leases | integer | Number of expired leases that have | + | | | been reclaimed since server | + | | | startup. It is incremented each | + | | | time an expired lease is reclaimed | + | | | (counting both NA and PD | + | | | reclamations). This statistic | + | | | never decreases. It can be used as | + | | | a long-term indicator of how many | + | | | actual leases have been reclaimed. | + | | | This is a global statistic that | + | | | covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].reclaimed-leases | integer | Number of expired leases | + | | | associated with a given subnet | + | | | that have been reclaimed since | + | | | server startup. It is incremented | + | | | each time an expired lease is | + | | | reclaimed (counting both NA and PD | + | | | reclamations). The *id* is the | + | | | subnet-id of a given subnet. This | + | | | statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+------------------------------------+ + | declined-addresses | integer | Number of IPv6 addresses that are | + | | | currently declined; a count of the | + | | | number of leases currently | + | | | unavailable. Once a lease is | + | | | recovered, this statistic will be | + | | | decreased; ideally, this statistic | + | | | should be zero. If this statistic | + | | | is non-zero or increasing, a | + | | | network administrator should | + | | | investigate whether there is a | + | | | misbehaving device in the network. | + | | | This is a global statistic that | + | | | covers all subnets. | + +----------------------------------------------+----------------+------------------------------------+ + | subnet[id].declined-addresses | integer | Number of IPv6 addresses that are | + | | | currently declined in a given | + | | | subnet; a count of the number of | + | | | leases currently unavailable. Once | + | | | a lease is recovered, this | + | | | statistic will be decreased; | + | | | ideally, this statistic should be | + | | | zero. If this statistic is | + | | | non-zero or increasing, a network | + | | | administrator should investigate | + | | | whether there is a misbehaving | + | | | device in the network. The *id* is | + | | | the subnet-id of a given subnet. | + | | | This statistic is exposed for each | + | | | subnet separately. | + +----------------------------------------------+----------------+----