diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5 index 1e0aedca..500d1bf2 100644 --- a/server/dhcpd.conf.5 +++ b/server/dhcpd.conf.5 @@ -1723,12 +1723,22 @@ lease the server has offered is not valid. When the server receives a DHCPDECLINE for a particular address, it normally abandons that address, assuming that some unauthorized system is using it. Unfortunately, a malicious or buggy client can, using DHCPDECLINE -messages, to completely exhaust the DHCP server's allocation pool. The +messages, completely exhaust the DHCP server's allocation pool. The server will eventually reclaim these leases, but not while the client is running through the pool. This may cause serious thrashing in the DNS, and it will also cause the DHCP server to forget old DHCP client address allocations. .PP +The \fBdeclines\fR flag tells the DHCP server whether or not to honor +DHCPDECLINE messages. If it is set to \fBdeny\fR or \fBignore\fR in +a particular scope, the DHCP server will not respond to DHCPDECLINE +messages. +.PP +The \fBdeclines\fR flag is only supported by DHCPv4 servers. Given the large +IPv6 address space and the internal limits imposed by the server's +address generation mechanism we don't think it is necessary for DHCPv6 +servers at this time. +.PP Currently, abandoned IPv6 addresses are reclaimed in one of two ways: a) Client renews a specific address: If a client using a given DUID submits a DHCP REQUEST containing @@ -1761,11 +1771,6 @@ condition: where is an actual DUID value depicted as colon separated string of bytes in hexadecimal values. .PP -The \fBdeclines\fR flag tells the DHCP server whether or not to honor -DHCPDECLINE messages. If it is set to \fBdeny\fR or \fBignore\fR in -a particular scope, the DHCP server will not respond to DHCPDECLINE -messages. -.PP .B The .I client-updates .B keyword