ISC DHCP "decline"
According to ISC DHCP dhcpd config doc:
The declines keyword
allow declines;
deny declines;
ignore declines;
The DHCPDECLINE message is used by DHCP clients to indicate that the 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. Unfor-
tunately, a malicious or buggy client can, using DHCPDECLINE 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.
The declines flag tells the DHCP server whether or not to honor DHCPDECLINE messages. If it
is set to deny or ignore in a particular scope, the DHCP server will not respond to DHCPDE-
CLINE messages.
The declines 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.
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
the last address abandoned by that DUID, the address will be
reassigned to that client.
b) Upon the second restart following an address abandonment. When
an address is abandoned it is both recorded as such in the lease
file and retained as abandoned in server memory until the server
is restarted. Upon restart, the server will process the lease file
and all addresses whose last known state is abandoned will be
retained as such in memory but not rewritten to the lease file.
This means that a subsequent restart of the server will not see the
abandoned addresses in the lease file and therefore have no record
of them as abandoned in memory and as such perceive them as free
for assignment.
The total number addresses in a pool, available for a given DUID value, is internally lim-
ited by the server's address generation mechanism. If through mistaken configuration, mul-
tiple clients are using the same DUID they will competing for the same addresses causing the
server to reach this internal limit rather quickly. The internal limit isolates this type
of activity such that address range is not exhausted for other DUID values. The appearance
of the following error log, can be an indication of this condition:
"Best match for DUID <XX> is an abandoned address, This may be a
result of multiple clients attempting to use this DUID"
where <XX> is an actual DUID value depicted as colon separated
string of bytes in hexadecimal values.