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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information