From: Marcin Siodelski Date: Mon, 21 Nov 2022 20:17:16 +0000 (+0100) Subject: [#969] Documented allocators X-Git-Tag: Kea-2.3.4~71 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bbfda363633591dc77ed069f1074aff8ce4647f2;p=thirdparty%2Fkea.git [#969] Documented allocators --- diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst index 63f52a80e8..c2369b056b 100644 --- a/doc/sphinx/arm/dhcp4-srv.rst +++ b/doc/sphinx/arm/dhcp4-srv.rst @@ -7252,3 +7252,85 @@ and include incorrect Link Selection information. } } } + +.. _dhcp4_allocation_strategies: + +Address Allocation Strategies in DHCPv4 +======================================= + +A DHCP server follows a complicated algorithm to select an IPv4 address for a client. +It prefers assigning specific addresses requested by the client and the addresses for +which the client has reservations. If the client requests no particular address, +has no reservations, or other clients already use these addresses, the server must +find another available address within the configured pools. A server function called +"allocator" is responsible in Kea for finding an available address in such a case. + +Kea DHCPv4 server provides configuration parameters to select different allocators +(allocation strategies) at the global, shared network, and subnet levels. +Consider the following example: + +.. code-block:: json + + { + "Dhcp4": { + "allocator": "random", + "subnet4": [ + { + "id": 1, + "subnet": "10.0.0.0/8", + "allocator": "iterative" + }, + { + "id": 2, + "subnet": "192.0.2.0/24", + } + ] + } + } + +It overrides the default iterative allocation strategy at the global level and +selects the random allocation instead. The random allocation will be used +for the subnet with id 2. The iterative allocation will be used for the subnet +with id 1. + +In the following sections, we describe the supported allocators and recommend +when to use them. + +.. note:: + + Allocator selection is currently not supported in the Kea Configuration + Backend. + + +Iterative Allocator +------------------- +It is the default allocator used by the Kea DHCPv4 server. It remembers the +last offered address and offers this address increased by 1 to the next client. +For example, it may offer addresses in this order: ``192.0.2.10``, ``192.0.2.11``, +``192.0.2.12``, and so on. The time to find and offer the next address is very +short. Thus, it is the highly performant allocator when the pool utilization +is low and there is a high probability that the next address is available. + +The iterative allocation underperforms when multiple DHCP servers share a lease +database or are connected to a cluster. The servers tend to offer and allocate +the same blocks of addresses to different clients independently. It causes many +allocation conflicts between the servers and retransmissions by clients. A random +allocation deals with it by dispersing the allocations order. + +Random Allocator +---------------- + +The random allocator uses a uniform randomization function to select offered +addresses from the subnet pools. It improves the server's resilience against +attacks based on allocation predictability. In addition, the random allocation +is suitable in deployments where multiple servers are connected to a shared +database or a database cluster. By dispersing the offered addresses, the servers +minimize the risk of allocating the same address to two different clients at +the same or nearly the same time. + +The random allocator is, however, slightly slower than the iterative allocator. +Moreover, it increases the server's memory consumption because it must remember +randomized addresses to avoid offering them repeatedly. Memory consumption grows +with the number of offered addresses. In other words, larger pools and more +clients increase memory consumption by random allocation. + diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst index bda1c1ad18..4e73c42983 100644 --- a/doc/sphinx/arm/dhcp6-srv.rst +++ b/doc/sphinx/arm/dhcp6-srv.rst @@ -7015,3 +7015,91 @@ MiNID. } } } + +.. _dhcp6_allocation_strategies: + +Address Allocation Strategies in DHCPv6 +======================================= + +A DHCP server follows a complicated algorithm to select a DHCPv6 lease for a client. +It prefers assigning specific addresses or delegated prefixes requested by the client +and the ones for which the client has reservations. If the client requests no particular +lease, has no reservations, or other clients already use these leases, the server must +find another available lease within the configured pools. A server function called +"allocator" is responsible in Kea for finding an available leases in such a case. + +Kea DHCPv6 server provides configuration parameters to select different allocators +(allocation strategies) at the global, shared network, and subnet levels. It also +allows for selecting different allocation strategies for address assignments and +prefix delegation. + + +Consider the following example: + +.. code-block:: json + + { + "Dhcp6": { + "allocator": "iterative", + "pd-allocator": "random", + "subnet6": [ + { + "id": 1, + "subnet": "2001:db8:1::/64", + "allocator": "random" + }, + { + "id": 2, + "subnet": "2001:db8:2::/64", + "pd-allocator": "iterative" + } + ] + } + } + +The iterative allocator is globally selected for address assignments. The +random allocator is globally selected for prefix delegation. These settings +are selectively overridden at the subnet level. + + +In the following sections, we describe the supported allocators and recommend +when to use them. + +.. note:: + + Allocator selection is currently not supported in the Kea Configuration + Backend. + +Iterative Allocator +------------------- +It is the default allocator used by the Kea DHCPv6 server. It remembers the +last offered lease and offers the following lease to the next client. +For example, it may offer addresses in this order: ``2001:db8:1::10``, +``2001:db8:1::11``, ``2001:db8:1::12``, and so on. Similarly, it offers the +delegated prefix following the previous one to the next client. The time to +find and offer the next lease is very short. Thus, it is the highly performant +allocator when the pool utilization is low and there is a high probability +that the next selected lease is available. + +The iterative allocation underperforms when multiple DHCP servers share a lease +database or are connected to a cluster. The servers tend to offer and allocate +the same blocks of addresses to different clients independently. It causes many +allocation conflicts between the servers and retransmissions by clients. A random +allocation deals with it by dispersing the allocations order. + +Random Allocator +---------------- + +The random allocator uses a uniform randomization function to select offered +addresses and delegated prefixes from the subnet pools. It improves the server's +resilience against attacks based on allocation predictability. In addition, the +random allocation is suitable in deployments where multiple servers are connected +to a shared database or a database cluster. By dispersing the offered leases, the +servers minimize the risk of allocating the same lease to two different clients at +the same or nearly the same time. + +The random allocator is, however, slightly slower than the iterative allocator. +Moreover, it increases the server's memory consumption because it must remember +randomized leases to avoid offering them repeatedly. Memory consumption grows +with the number of offered leases. In other words, larger pools and more +clients increase memory consumption by random allocation.