Context Navigation

Requirements for Decline support in Kea 1.0

Kea 0.9.2 does not support Decline messages, so any duplicates detected by the clients and reported to the server are ignored. This shortcoming is going to be addressed in Kea 1.0. The actual design is described here: DeclineDesign.

The following lists enumerate all requirements for the Decline support planned for Kea 1.0:

Terminology

Declined address - an address that was reported by a client as already used by unknown entity in the network.

Declined state - a state in which an address is marked by the server as unvailable for the assignment.

Declined address recovery (or Address Recovery) - a process by which the server marks an address in the declined state as available for assignment again, i.e. moves it out of the declined state. This may be automatic (after period time elapses) or manual (an explicit administrative action).

Probation period - a time when address is kept in the declined state.

General

G1 DHCPDECLINE message in DHCPv4 MUST be supported.

G2 DECLINE message in DHCPv6 MUST be supported.

G3 A declined address MUST NOT be assigned to a client.

G4 There MUST be a mechanism to automatically recover declined address, i.e. to return it to the available pool.

G5 There SHOULD be a mechanism to administratively recover address from declined state at any time.

G6 The information about currently declined addresses MUST NOT be lost after system restart or crash.

G7 There MUST be dedicated log entries for putting and recovering an address from the declined state. They must include the address, the client's details and the amount of time the address being declined will remain in the declined state.

Configuration

There are several requirements for the configuration:

C1 DECLINE support MUST be working out of the box and MUST NOT require any additional parameters.

C2 The amount of time an address remains in the declined state MUST be configurable.

C3 It MUST be possible to keep an address in the declined state until sysadmin intervention.

Hooks

Decline should be covered by hooks mechanism. There will be additional hook points for it:

H1 There MUST be a hook point for marking an address as declined.

H2 There MUST be a hook point for recovering an address from declined state.

Statistics

S1 There MUST be a statistic for the number of addresses currently in the declined state. This statistic will go back to 0 when all declined addresses are recovered. (declined-addresses)

S2 There MUST be a statistic for the total cases of addresses declined and recovered. This statistic will only go up. (reclaimed-declined-addresses)

S3 There MUST be a per-subnet statistic that specifies number of addresses currently in the declined state. This statistic will go back to 0 when all addresses are recovered. (subnet[id].declined-addresses)

S4 There MUST be a per-subnet statistic that specifies the number of address declined and recovered. This statistic will only go up. (subnet[id].reclaimed-declined-addresses)

Note: As with all other runtime statistics, they are considered runtime property. As such, they will be reset upon server restart.