# Lease Expiration in DHCPv4 and DHCPv6

The primary role of the DHCP server is to assign addresses and/or delegate prefixes to DHCP clients. These addresses and prefixes are often referred to as "leases." Leases are typically assigned to clients for a finite amount of time, known as the "valid lifetime." DHCP clients who wish to continue using their assigned leases will periodically renew them by sending the appropriate message to the DHCP server. The DHCP server records the time when these leases are renewed and calculates new expiration times for them.

If the client does not renew a lease before its valid lifetime elapses, the lease is considered expired. There are many situations when the client may cease lease renewals; a common scenario is when the machine running the client shuts down for an extended period of time.

The process through which the DHCP server makes expired leases available for reassignment is referred to as "lease reclamation" and expired leases returned to availability through this process are referred to as "reclaimed." The DHCP server attempts to reclaim an expired lease as soon as it detects that it has expired. The server has several possible ways to detect expiration: it may attempt to allocate a lease to a client but find this lease already present in the database and expired; or it can periodically query the lease database for expired leases. Regardless of how an expired lease is detected, it must be reclaimed before it can be assigned to a client.

This chapter explains how to configure the server to periodically query for the expired leases, and how to minimize the impact of the periodic lease reclamation process on the server's responsiveness. Finally, it explains "lease affinity," which provides the means to assign the same lease to a returning client after its lease has expired.

Although all configuration examples in this section are provided for the DHCPv4 server, the same parameters may be used for DHCPv6 server configuration.

## Lease Reclamation

Lease reclamation is the process through which an expired lease becomes available for assignment to the same or a different client. This process involves the following steps for each reclaimed lease:

- Invoke callouts for the `lease4_expire` or `lease6_expire` hook points, if hook libraries supporting those callouts are currently loaded.

- Update the DNS, i.e. remove any DNS entries associated with the expired lease.

- Update lease information in the lease database to indicate that the lease is now available for re-assignment.

- Update counters on the server, a process that includes increasing the number of reclaimed leases and decreasing the number of assigned addresses or delegated prefixes.

Please refer to to see how to configure DNS updates in Kea, and to for information about using hooks libraries.

## Lease Reclamation Configuration Parameters

The following list presents all configuration parameters pertaining to processing expired leases with their default values:

- `reclaim-timer-wait-time` - This parameter governs intervals between completion of previous reclaimation cycle and a start of the next one. Specified in seconds. The default value is 10 [seconds].

- `flush-reclaimed-timer-wait-time` - This parameter controls how often the server initiates lease reclaimation procedure. Expressed in seconds. The default value is 25 [seconds].

- `hold-reclaimed-time` - This parameter governs how long the lease should be kept after it was reclaimed. This enables lease affinity when set to a non-zero value. Expressed in seconds. The default value is 3600 [seconds].

- `max-reclaim-leases` - This parameter specifies the maximum number of reclaimed leases that can be processed in one go. Zero means unlimited (i.e. process all reclaimed leases). The default value is 100.

- `max-reclaim-time` - This parameter specifies an upper bound of how long a lease reclaimation procedure can take. Zero means no time limit. Expressed in milliseconds. The default value is 250 [milliseconds].

- `unwarned-reclaim-cycles` - If lease reclaimation limits are specifed (`max-reclaim-leases` and/oor `max-reclaim-time`), then under certain circumstances the server may not be able to deal with leases to be reclaimed fast enough. This parameter specifies how many consecutive clean up cycles must end with remaining leases to be processed before a warning is printed. The default is 5 [cycles].

The parameters are explained in more detail in the rest of this chapter.

The default value for any parameter is used when this parameter is not explicitly specified in the configuration. Also, the `expired-leases-processing` map may be omitted entirely in the configuration, in which case the default values are used for all parameters listed above.

## Configuring Lease Reclamation

Kea can be configured to periodically detect and reclaim expired leases. During this process the lease entries in the database are modified or removed. While this is happening, the server will not process incoming DHCP messages to avoid issues with concurrent access to database information. As a result, the server will be unresponsive while lease reclamation is performed and DHCP queries will accumulate; responses will be sent once the lease-reclamation cycle is complete.

In deployments where response time is critical, administrators may wish to minimize the interruptions in service caused by lease reclamation. Toward this end, Kea provides configuration parameters to control the frequency of lease reclamation cycles, the maximum number of leases processed in a single reclamation cycle, and the maximum amount of time a single reclamation cycle is allowed to run before being interrupted. The following examples demonstrate how these parameters can be used:

    "Dhcp4": {
        ...

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 5,
            "max-reclaim-leases": 0,
            "max-reclaim-time": 0,
        },

        ...
    }

The first parameter is expressed in seconds and specifies an interval between the two consecutive lease reclamation cycles. This is explained by the following diagram:

    |  c1  |            | c2 |            |c3|            | c4 |
    |<---->|<---------->|<-->|<---------->|<>|<---------->|<-->|
    ---------------------------------------------------------------->
    |      |     5s     |    |     5s     |  |     5s     |    | time

This diagram shows four lease-reclamation cycles (c1 through c4) of variable duration. Note that the duration of the reclamation cycle depends on the number of expired leases detected and processed in the particular cycle. This duration is usually significantly shorter than the interval between the cycles.

According to the `reclaim-timer-wait-time`, the server keeps fixed intervals of five seconds between the end of one cycle and the start of the next cycle. This guarantees the presence of 5s-long periods during which the server remains responsive to DHCP queries and does not perform lease reclamation. The `max-reclaim-leases` and `max-reclaim-time` are set to 0, which sets no restriction on the maximum number of leases reclaimed in the particular cycle, or on the maximum duration of each cycle.

In deployments with high lease-pool utilization, relatively short valid lifetimes, and frequently disconnecting clients which allow leases to expire, the number of expired leases requiring reclamation at any given time may rise significantly. In this case, it is often desirable to apply restrictions to the maximum duration of a reclamation cycle or the maximum number of leases reclaimed in a cycle. The following configuration demonstrates how this can be done:

    "Dhcp4": {
        ...

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 3,
            "max-reclaim-leases": 100,
            "max-reclaim-time": 50,
            "unwarned-reclaim-cycles": 10,
        },

        ...
    }

The `max-reclaim-leases` parameter limits the number of leases reclaimed in a single cycle to 100. The `max-reclaim-time` limits the maximum duration of each cycle to 50ms. The lease-reclamation cycle will be interrupted if either of these limitations is reached. The reclamation of any unreclaimed leases will be attempted in subsequent cycles.

The following diagram illustrates the behavior of the system in the presence of many expired leases, when the limits are applied for the reclamation cycles:

    | c1 |                | c2 |                | c3 |                | c4 |
    |<-->|<-------------->|<-->|<-------------->|<-->|<-------------->|<-->|<--
    ------------------------------------------------------------------------------>
    |50ms|       3s       |50ms|       3s       |50ms|       3s       |50ms|  time

This diagram demonstrates the case when each reclamation cycle takes more than 50ms, and thus is interrupted according to the value of the `max-reclaim-time`. This results in equal durations of all reclamation cycles over time. Note that in this example the limitation of the maximum 100 leases is not reached. This may be the case when database transactions are slow or callouts in the hook libraries attached to the server are slow. Regardless, the chosen values for either the maximum number of leases or a maximum cycle time strongly depend on the particular deployment, the lease database backend being used, and any hooks libraries, etc. Administrators may need to experiment to tune the system to suit the dynamics of their deployment.

It is important to realize that with the use of these limits, there is a risk that expired leases will accumulate faster than the server can reclaim them. This should not be a problem if the server is dealing with a temporary burst of expirations, because it should be able to eventually deal with them over time. However, if leases expire at a high rate for a longer period of time, the unreclaimed leases will pile up in the database. To notify the administrator that the current configuration does not satisfy the needs for reclamation of expired leases, the server issues a warning message in the log if it is unable to reclaim all leases within several reclamation cycles. The number of cycles after which such a warning is issued is specified with the `unwarned-reclaim-cycles` configuration parameter.

Setting the `reclaim-timer-wait-time` to 0 disables periodic reclamation of the expired leases.

## Configuring Lease Affinity

Suppose that a laptop goes into sleep mode after a period of user inactivity. While the laptop is in sleep mode, its DHCP client will not renew leases obtained from the server and these leases will eventually expire. When the laptop wakes up, it is often desirable for it to continue using its previous assigned IP addresses. To facilitate this, the server needs to correlate returning clients with their expired leases. When the client returns, the server will first check for those leases and re-assign them if they have not been assigned to another client. The ability of the server to re-assign the same lease to a returning client is referred to as "lease affinity."

When lease affinity is enabled (i.e. when `hold-reclaimed-time` is configured to a value greater than zero), the server will still reclaim leases according to the parameters described in , but the reclaimed leases will be held in the database (rather than removed) for a specified amount of time. When the client returns, the server will first verify whether there are any reclaimed leases associated with this client and will re-assign them if possible. However, it is important to note that any reclaimed lease may be assigned to another client if that client specifically asks for it. Therefore, lease affinity does not guarantee that the reclaimed lease will be available for the client who used it before; it merely increases the chances for the client to be assigned the same lease. If the lease pool is small (this mostly applies to DHCPv4 for which address space is small), there is an increased likelihood that the expired lease will be assigned to another client.

Consider the following configuration:

    "Dhcp4": {
        ...

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 3,
            "hold-reclaimed-time": 1800,
            "flush-reclaimed-timer-wait-time": 5
        },

        ...
    }

The `hold-reclaim-time` specifies how many seconds after an expiration a reclaimed lease should be held in the database for re-assignment to the same client. In the example given above, reclaimed leases will be held for 30 minutes (1800s) after their expiration. During this time, the server will likely be able to re-assign the same lease to the returning client, unless another client requests this lease and the server assigns it.

The server must periodically remove reclaimed leases for which the time indicated by `hold-reclaim-time` has elapsed. The `flush-reclaimed-timer-wait-time` parameter controls how often the server removes such leases. In the example provided above, the server will initiate removal of such leases 5 seconds after the previous removal attempt was completed. Setting this value to 0 disables lease affinity, in which case leases will be removed from the lease database when they are reclaimed. If lease affinity is enabled, it is recommended that `hold-reclaim-time` be set to a value significantly higher than the `reclaim-timer-wait-time`, as timely removal of expired-reclaimed leases is less critical than the removal process, which may impact server responsiveness.

There is no guarantee that lease affinity will work every time. If a server is running out of addresses, it will reassign expired addresses to new clients. Also, clients can request specific addresses and the server will try to honor such a request if possible. If you want to ensure a client keeps its address, even after periods of inactivity, consider using host reservations or leases with very long lifetimes.

## Reclaiming Expired Leases with Command

The leases-reclaim command can be used to trigger lease reclamation at any time. Please consult the section for details about using this command.