<para>The DHCPv4 server is configured with a certain pool of addresses
that it is expected to hand out to the DHCPv4 clients. It is
assumed that the server is authoritative and has complete jurisdiction
- over those addresses. However, due to various reasons, like
- misconfiguration or faulty client implemetation that retains its
- address beyond valid lifetime, there may be devices connected that use
- those addresses without the server's approval or knowledge. Such an
+ over those addresses. However, due to various reasons, such as
+ misconfiguration or a faulty client implemetation that retains its
+ address beyond the valid lifetime, there may be devices connected that use
+ those addresses without the server's approval or knowledge.</para>
+
+ <para>Such an
unwelcome event can be detected by legitimate clients (using ARP or ICMP
- Echo Request mechanisms) and reported to the DHCPv4 server using DHCPDECLINE
- message. The server will sanity check it (if the client declining an
- address really was supposed to use it), and then will conduct clean up
+ Echo Request mechanisms) and reported to the DHCPv4 server using a DHCPDECLINE
+ message. The server will do a sanity check (if the client declining an
+ address really was supposed to use it), and then will conduct a clean up
operation. Any DNS entries related to that address will be removed, the
fact will be logged and hooks will be triggered. After that is done, the
address will be marked as declined (which indicates that it is used by an
- unknown entity and thus not available for assignment to anyone) and
- probation time on it will be set. Unless otherwise configured, the
+ unknown entity and thus not available for assignment to anyone) and a
+ probation time will be set on it. Unless otherwise configured, the
probation period lasts 24 hours. After that period, the server will
- recover the lease, i.e. put it back into available state. The address will
+ recover the lease, i.e. put it back into the available state. The address will
be available for assignment again. It should be noted that if the
underlying issue of a misconfigured device is not resolved, the duplicate
address scenario will repeat. On the other hand, it provides an
opportunity to recover from such an event automatically, without any
sysadmin intervention.</para>
- <para>To configure decline probation period to a value different
+ <para>To configure the decline probation period to a value different
than the default, the following syntax can be used:
<screen>
"Dhcp4": {
the server to recycle declined leases after an hour.</para>
<para>There are several statistics and hook points associated with the
- Decline handling procedure. lease4_decline hook is triggered after the
- incoming DHCPDECLINE message was sanitized and the server is about to
- decline the lease. declined-addresses statistic is increased after the
+ Decline handling procedure. The lease4_decline hook is triggered after the
+ incoming DHCPDECLINE message has been sanitized and the server is about to
+ decline the lease. The declined-addresses statistic is increased after the
hook returns (both global and subnet specific variants).</para>
<para>Once the probation time elapses, the declined lease is recovered
- using standard expired lease reclaimation procedure, with several
+ using the standard expired lease reclaimation procedure, with several
additional steps. In particular, both declined-addresses statistics
- (global and subnet specific) are being decreased. At the same time,
+ (global and subnet specific) are decreased. At the same time,
reclaimed-declined-addresses statistics (again in two variants, global and
subnet specific) are increased.</para>
-
+
<para>Note about statistics: The server does not decrease
- assigned-addresses statistics when DHCPDECLINE is received and processed
+ assigned-addresses statistics when a DHCPDECLINE is received and processed
successfully. While technically a declined address is no longer assigned,
the primary usage of the assigned-addresses statistic is to monitor pool
utilization. Most people would forget to include declined-addresses in the
addresses that it is expected to hand out to the DHCPv6 clients.
It is assumed that the server is authoritative and has complete
jurisdiction over those addresses. However, due to various
- reasons, like misconfiguration or faulty client implenetation
- that retains its address beyond valid lifetime, there may be
+ reasons, such as misconfiguration or a faulty client implenetation
+ that retains its address beyond the valid lifetime, there may be
devices connected that use those addresses without the server's
- approval or knowledge. Such an unwelcome event can be detected
+ approval or knowledge.</para>
+
+ <para>Such an unwelcome event can be detected
by legitimate clients (using Duplicate Address Detection) and
- reported to the DHCPv6 server using DECLINE message. The server
- will sanity check it (if the client declining an address really
- was supposed to use it), then will conduct clean up operation
+ reported to the DHCPv6 server using a DECLINE message. The server
+ will do a sanity check (if the client declining an address really
+ was supposed to use it), then will a conduct clean up operation
and confirm it by sending back a REPLY message. Any DNS entries
related to that address will be removed, the fact will be logged
and hooks will be triggered. After that is done, the address
will be marked as declined (which indicates that it is used by
an unknown entity and thus not available for assignment to
- anyone) and probation time on it will be set. Unless otherwise
+ anyone) and a probation time will be set on it. Unless otherwise
configured, the probation period lasts 24 hours. After that
period, the server will recover the lease, i.e. put it back into
- available state. The address will be available for assignment
+ the available state. The address will be available for assignment
again. It should be noted that if the underlying issue of a
misconfigured device is not resolved, the duplicate address
scenario will repeat. On the other hand, it provides an
opportunity to recover from such an event automatically, without
any sysadmin intervention.</para>
- <para>To configure decline probation period to a value different
+ <para>To configure the decline probation period to a value different
than the default, the following syntax can be used:
<screen>
"Dhcp6": {
the server to recycle declined leases after an hour.</para>
<para>There are several statistics and hook points associated with the
- Decline handling procedure. lease6_decline hook is triggered after the
- incoming Decline message was sanitized and the server is about to decline
- the lease. declined-addresses statistic is increased after the hook
+ Decline handling procedure. The lease6_decline hook is triggered after the
+ incoming Decline message has been sanitized and the server is about to decline
+ the lease. The declined-addresses statistic is increased after the hook
returns (both global and subnet specific variants).</para>
<para>Once the probation time elapses, the declined lease is recovered
- using standard expired lease reclaimation procedure, with several
+ using the standard expired lease reclaimation procedure, with several
additional steps. In particular, both declined-addresses statistics
- (global and subnet specific) are being decreased. At the same time,
+ (global and subnet specific) are decreased. At the same time,
reclaimed-declined-addresses statistics (again in two variants, global and
subnet specific) are increased.</para>
<para>Note about statistics: The server does not decrease
- assigned-addresses statistics when Decline message is received and
+ assigned-addresses statistics when a DECLINE message is received and
processed successfully. While technically a declined address is no longer
assigned, the primary usage of the assigned-addresses statistic is to
monitor pool utilization. Most people would forget to include
<entry>
This statistic shows the number of IPv6 adresses that are
currently declined. This statistic counts the number of leases
- being currently unavailable. Once the lease is recovered, this
- statistic will be decreased. Ideally, this statistic should not
- have non-zero values. If this statistic has non-zero or increasing
- values, a network administrator should investigate if there is
+ currently unavailable. Once a lease is recovered, this
+ statistic will be decreased. Ideally, this statistic should be
+ zero. If this statistic is non-zero (or worse increasing),
+ a network administrator should investigate if there is
a misbehaving device in his network. This is a global statistic
that covers all subnets.
</entry>
<entry>
This statistic shows the number of IPv6 adresses that are
currently declined in a given subnet. This statistic counts the
- number of leases being currently unavailable. Once the lease is
+ number of leases currently unavailable. Once a lease is
recovered, this statistic will be decreased. Ideally, this
- statistic should not have non-zero values. If this statistic has
- non-zero or increasing values, a network administrator should
+ statistic should be zero. If this statistic is
+ non-zero (or worse increasing), a network administrator should
investigate if there is a misbehaving device in his network. The
<emphasis>id</emphasis> is the subnet-id of a given subnet. This
statistic is exposed for each subnet separately.
<entry>integer</entry>
<entry>
This statistic shows the number of IPv6 adresses that were
- declined, but are now recovered. Contrary to the
+ declined, but are now recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
- conducted and recovered from. This is a global statistic that
+ processed and recovered from. This is a global statistic that
covers all subnets.
</entry>
</row>
<entry>integer</entry>
<entry>
This statistic shows the number of IPv6 adresses that were
- declined, but are now recovered. Contrary to the
+ declined, but are now recovered. Unlike
declined-addresses, this statistic never decreases. It can be used
as a long term indicator of how many actual valid Declines were
- conducted and eventually recovered from. The
+ processed and recovered from. The
<emphasis>id</emphasis> is the subnet-id of a given subnet. This
statistic is exposed for each subnet separately.
</entry>
projects / thirdparty / kea.git / commitdiff
