From a104287eb44b743519e02d7c3d6a20e38412a039 Mon Sep 17 00:00:00 2001 From: Marcin Siodelski Date: Mon, 16 Feb 2015 19:40:43 +0100 Subject: [PATCH] [3565] Updated the wording in the kea user guide for reservation-mode param. --- doc/guide/dhcp4-srv.xml | 30 +++++++++++++++++------------- doc/guide/dhcp6-srv.xml | 28 ++++++++++++++++------------ 2 files changed, 33 insertions(+), 25 deletions(-) diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index 859b9742bc..188eb169ab 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -1891,24 +1891,28 @@ temporarily override a list of interface names and listen on all interfaces. Fine Tuning IPv4 Host Reservation - reservation-mode in DHCPv6 server in 0.9.1 beta is - accepted, but not used. Full implementation will be available in the upcoming - releases. + reservation-mode configuration parameter in DHCPv4 + server is accepted, but not used in the Kea 0.9.1 beta. Full implementation + will be available in the upcoming releases. Host reservation capability introduces additional restrictions for the allocation engine 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 be not used by anyone else. It also must - not be reserved for anyone else. Second, when renewing a lease, additional - check must be performed whether the address being renewed is not reserved - for anyone else. Finally, when a host renews an address, the server has to - check whether there's a reservation for this host, so the exisiting (dynamically - allocated) address should be revoked and the reserved one be used instead. - - Some of those checks in certain deployments may be not necessary. Skipping - them may improve performance. The Kea server allows configuration of the - reservation types allowed for each subnet using reservation-mode. + sufficient for a candidate lease to be not used by another DHCP client. It + also must not be reserved for another client. Second, when renewing a lease, + additional check must be performed whether the address being renewed is not + reserved for another client. Finally, when a host renews an address, the server + has to check whether there's a reservation for this host, so the exisiting + (dynamically allocated) address should be revoked and the reserved one be + used instead. + + Some of those checks may be unnecessary in certain deployments. Not + performing them may improve performance. The Kea server provides the + reservation-mode configuration parameter to select the + types of reservations allowed for the 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: diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml index 6f609ece96..b7578e000c 100644 --- a/doc/guide/dhcp6-srv.xml +++ b/doc/guide/dhcp6-srv.xml @@ -1898,23 +1898,27 @@ should include options from the isc option space: Fine Tuning IPv6 Host Reservation - reservation-mode in the DHCPv6 server in 0.9.1 beta is - implemented, but was not tested and is considered experimental. + reservation-mode in the DHCPv6 server is + implemented in Kea 0.9.1 beta, but has not been tested and is + considered experimental. Host reservation capability introduces additional restrictions for the allocation engine 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 be not used by anyone else. It also must - not be reserved for anyone else. Second, when renewing a lease, additional - check must be performed whether the address being renewed is not reserved - for anyone else. Finally, when a host renews an address, the server has to - check whether there's a reservation for this host, so the exisiting (dynamically - allocated) address should be revoked and the reserved one be used instead. - - Some of those checks in certain deployments may be not necessary. Skipping - them may improve performance. The Kea server allows configuration of the - reservation types allowed for each subnet using reservation-mode. + sufficient for a candidate lease to be not used by another DHCP client. It + also must not be reserved for another client. Second, when renewing a lease, + additional check must be performed whether the address being renewed is not + reserved for another client. Finally, when a host renews an address or a + prefix, the server has to check whether there's a reservation for this host, + so 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. Not + performing them may improve performance. The Kea server provides the + reservation-mode configuration parameter to select the + types of reservations allowed for the 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: -- 2.47.2