2
0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-31 06:15:55 +00:00

[master] Add comment that declines is only usable for v4 servers

[rt40206] Add comment that declines is only usable for v4 servers
This commit is contained in:
Shawn Routhier
2015-08-20 13:05:05 -07:00
parent 6c8eb5442c
commit e690fa7c58

View File

@@ -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 <XX> 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