From: Tomek Mrugalski Date: Mon, 26 Jan 2015 16:53:01 +0000 (+0100) Subject: [3575] Reservations for v4 documented. X-Git-Tag: trac3723_base~35^2~5 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5f134d8beb60de4b76d00a38d7d5654142c7e3e4;p=thirdparty%2Fkea.git [3575] Reservations for v4 documented. --- diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index dee22e5b6b..4fd3ff93c3 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -1729,6 +1729,159 @@ temporarily override a list of interface names and listen on all interfaces. + +
+ Host reservation 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 specific, static + address for exclusive use by a given client ‐ returning client will get + the same address every time and other clients will never get that + address. Other example may be a host that has specific requirements, e.g. a + printer that needs additional options. Yes another possible use case for + host reservation is to define unique host names for hosts. Although not all + of those scenarios are possible yet, Kea software will support them in the + near future. + + Hosts are defined as parameters for each subnet. Each host has to be + identified by its hardware/MAC address. There is an optional + reservation array. Each element in that array is a + structure, that holds information about a single host. In particular, such + a structure has to have an indentifer that uniquely identifies a host. + In DHCPv4 context, such an identifier is a hardware or MAC address. + In most cases, also an address will be specified. It is possible to specify + a hostname. Additional capabilities are planed. + + The following example shows how to reserve addresses for specific + hosts: + + +"subnet4": [ + { + "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], + "subnet": "192.0.2.0/24", + "interface": "eth0", + "reservations": [ + { + "hw-address": "1a:1b:1c:1d:1e:1f", + "ip-address": "192.0.2.202", + "hostname": "alice-laptop" + }, + { + "hw-address": "0a:0b:0c:0d:0e:0f", + "ip-address": "192.0.2.100" + } + ] + } +] + + + + Making a reservation for a mobile host that may visit multiple subnets + requires a separate host definition in each subnet it is expected to visit. + It is not allowed to define multiple host definitions with the same hardware + address in a single subnet. It is a valid configuration, if such definitions + are specified in different subnets, though. + + + Adding host reservation incurs a performance penalty. In principle, + when the server that does not support host reservation responds to a query, + it needs to check whether there is a lease for a given address being + considered for allocation or renewal. The server that also supports host + reservation, has to perform additional checks: not only if the address is + currently used (if there is a lease for it), but also whether the address + could be used by someone else (if there is a reservation for it). That + additional check incurs performance penalty. + +
+ Address reservation types + + In a typical scenario there's an IPv4 subnet defined, + e.g. 192.0.2.0/24 with 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 the host reservation can reserve any address + that belongs to the subnet. The reservations that specify an address that + belong to configure pools are called in-pool reservations. + In contract, those that do not belong to dynamic pools are called + out-of-pool reservations. This is no formal difference + in the reservation syntax. As of 0.9.1, both reservation types are + handled uniformly. However, upcoming releases may offer improved performance + if there are only out-of-pool reservations as the server will be able + to skip reservation checks when dealing with existing leases. Therefore + system administrators are encouraged to use out-of-pool reservations, if + possible. +
+ +
+ Conflicts in DHCPv4 reservations + As reservations and lease information are kept in different places, + conflict may arrise. Consider the following series of events. The server + has configured 192.0.2.10 to 192.0.2.20 dynamic pool range. Host A + requests an address and gets 19.0.2.10. Now the system administrator + decides to reserve an address for host B. He decides to reserve 192.0.2.10 + for that purpose. In general, reserving an address that is currently + assigned to someone else is not recommended, but there are valid use + cases where such an operation is warranted. + + The server now has a conflict to resolve. Let's analyze the + situation here. If host B boots up and request an address, the server + is not able to assign the requested address 192.0.2.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 get the address, it will detect that the address is already in use + by someone else (host A) and would send Decline. Therefore in this situation, + the server has to temporarily assign a different address to host B. + + When the host A renews its address, the server will discover that + the address being renewed is now reserved for someone else (host + B). Therefore the server will remove the lease and will inform the host A + that it is no longer allowed to use it by sending NAK message. Host A + will then revert to server discovery and will eventually get a different + address. The address 192.0.2.10 is now no longer used. When host B tries + to renew its temporary address, the server will detect that it has a valid + lease, but there is a reservation for a different address. The server will + send NAK to inform host B that its address is no longer usable. The + server will also remove its temporary lease. It will revert to the server + discovery phase and will eventually send a REQUEST message. This time the + server will find out that there is a reservation for that host and the + reserved address 192.0.2.10 is not used, so it will be granted. + + This recovery will succeed, even if other hosts will attempt to get + the reserved address. Had the host C requested address 192.0.2.10 after + the reservation was made, the server will either propose a different + address (when responding to DISCOVER) or would send NAK (when responding + to REQUEST). + + This recovery mechanism allows the server to fully recover from a + case where reservations conflict with existing leases. This procedure + takes time and will roughly take as long as renew-timer value specified. + The best way to avoid such recovery is to not 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 + pool, there is no way that other clients could get this address (note that + having multiple reservations for the same address is not allowed). + +
+ +
+ Reserving a hostname + + Reserving a hostname is currently not supported. It is possible + to specify that information in the configuration file, but that data + is not used by the server engine yet. +
+ +
+ Reserving specific options + + Currently it is not possible to specify options in host + reservation. Such a feature will be added in the upcoming Kea + releases. +
+
+ +
Server Identifier in DHCPv4