From: Sebastian Schrader Date: Mon, 22 Oct 2018 09:42:46 +0000 (+0200) Subject: [5184] Add authoritative documentation X-Git-Tag: 259-libyang-adapt-authoritative_base~11 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=798691a0364134ac451fb6b78974a3bc6d321d9c;p=thirdparty%2Fkea.git [5184] Add authoritative documentation --- diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index d7a7720e49..c5c3c43054 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -3229,6 +3229,37 @@ It is merely echoed by the server +
+ Authoritative DHCPv4 Server Behavior + The original DHCPv4 specification + (RFC 2131) + states that if a clients requests an address in the INIT-REBOOT state of + which, the server has no knowledge of, the server must remain silent, + except if the server knows that the client requests an IP address from the + wrong network. + By default Kea follows the behavior of the ISC dhcpd instead of the + specification and also remains silent, if the client requests an IP + address from the wrong network, + because configuration information about a given network segment is not + known to be correct. + Kea only rejects a client's DHCPREQUEST with a DHCPNAK message, if it + already has a lease for the client, but with a different IP address. + Administrators can override this behavior through the + boolean authoritative (false + by default) setting. + + + In authoritative mode, authoritative set to + true, Kea always rejects INIT-REBOOT requests from + unknown clients with DHCPNAK messages. + The authoritative setting can be specified in + global, shared-network, and subnet configuration scope and is + automatically inherited from the parent scope, if not specified. + All subnets in a shared-network must have the same + authoritative setting. + +
+
DHCPv4-over-DHCPv6: DHCPv4 Side