path: root/src/lib/dhcpsrv/alloc_engine_messages.mes

# Copyright (C) 2015-2023 Internet Systems Consortium, Inc. ("ISC")
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

$NAMESPACE isc::dhcp

% ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS ignoring globally reserved address %1, it falls outside %2
This debug message is issued when the allocation engine determines that
the globally reserved address falls outside the selected subnet or
shared-network.  The server should ignore the reserved address and
attempt a dynamic allocation.

% ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS6 ignoring globally reserved address %1, it falls outside %2
This debug message is issued when the allocation engine determines that
the globally reserved address falls outside the selected subnet or
shared-network.  The server should ignore the reserved address and
attempt a dynamic allocation.

% ALLOC_ENGINE_LEASE_RECLAIMED successfully reclaimed lease %1
This debug message is logged when the allocation engine successfully
reclaims a lease. The lease is now available for assignment.

% ALLOC_ENGINE_REMOVAL_NCR_FAILED sending removal name change request failed for lease %1: %2
This error message is logged when sending a removal NameChangeRequest
to DHCP DDNS failed. This NameChangeRequest is usually generated when
the lease reclamation routine acts upon expired leases. If a lease being
reclaimed has a corresponding DNS entry it needs to be removed.
This message indicates that removal of the DNS entry has failed.
Nevertheless the lease will be reclaimed.

% ALLOC_ENGINE_V4_ALLOC_ERROR %1: error during attempt to allocate an IPv4 address: %2
An error occurred during an attempt to allocate an IPv4 address, the
reason for the failure being contained in the message.  The server will
return a message to the client refusing a lease. The first argument
includes the client identification information.

% ALLOC_ENGINE_V4_ALLOC_FAIL %1: failed to allocate an IPv4 address after %2 attempt(s)
This is an old warning message issued when the allocation engine fails to allocate a
lease for a client. This message includes a number of lease allocation attempts
that the engine made before giving up. If the number of attempts is 0 because the
engine was unable to use any of the address pools for the particular client, this
message is not logged. Even though, several more detailed logs precede this message,
it was left for backward compatibility.

This message may indicate that your address pool is too small for the
number of clients you are trying to service and should be expanded.
Alternatively, if the you know that the number of concurrently active
clients is less than the addresses you have available, you may want to
consider reducing the lease lifetime. This way, addresses allocated
to clients that are no longer active on the network will become available
sooner.

% ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES %1: Failed to allocate an IPv4 address for client with classes: %2
This warning message is printed when Kea failed to allocate an address
and the client's packet belongs to one or more classes. There may be several
reasons why a lease was not assigned. One of them may be a case when all
pools require packet to belong to certain classes and the incoming packet
didn't belong to any of them. Another case where this information may be
useful is to point out that the pool reserved to a given class has ran
out of addresses. When you see this message, you may consider checking your
pool size and your classification definitions.

% ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS %1: no pools were available for the address allocation
This warning message is issued when the allocation engine fails to
allocate a lease because it could not use any configured pools for the
particular client. It is also possible that all of the subnets from
which the allocation engine attempted to assign an address lack address
pools. In this case, it should be considered misconfiguration if an
operator expects that some clients should be assigned dynamic addresses.
A subnet may lack any pools only when all clients should be assigned
reserved IP addresses.

Suppose the subnets connected to a shared network or a single subnet to
which the client belongs have pools configured. In that case, this
message is an indication that none of the pools could be used for the
client because the client does not belong to appropriate client classes.

% ALLOC_ENGINE_V4_ALLOC_FAIL_SHARED_NETWORK %1: failed to allocate an IPv4 address in the shared network %2: %3 subnets have no available addresses, %4 subnets have no matching pools
This warning message is issued when the allocation engine fails to allocate
a lease for a client connected to a shared network. The shared network should
contain at least one subnet, but typically it aggregates multiple subnets.
This log message indicates that the allocation engine could not find and
allocate any suitable lease in any of the subnets within the shared network.

The first argument includes the client identification information. The
second argument specifies the shared network name. The remaining two
arguments provide additional information useful for debugging why the
allocation engine could not assign a lease. The allocation engine tries
to allocate addresses from different subnets in the shared network, and
it may fail for some subnets because there are no leases available in
those subnets or the free leases are reserved to other clients. The
number of such subnets is specified in the third argument. For other
subnets the allocation may fail because their pools may not be available
to the particular client. These pools are guarded by client classes that
the client does not belong to. The fourth argument specifies the number
of such subnets. By looking at the values in the third and fourth argument,
an operator can identify the situations when there are no addresses left
in some of the pools. He or she can also identify a client classification
misconfigurations causing some clients to be refused the service.

% ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET %1: failed to allocate an IPv4 lease in the subnet %2, subnet-id %3, shared network %4
This warning message is issued when the allocation engine fails to allocate
a lease for a client connected to a subnet. The first argument includes the
client identification information. The second and third arguments identify
the subnet. The fourth argument specifies the shared network, if the subnet
belongs to a shared network.

There are many reasons for failing lease allocations. One of them may be the
pools exhaustion or existing reservations for the free leases. However, in
some cases, the allocation engine may fail to find a suitable pool for the
client when the pools are only available to certain client classes, but the
requesting client does not belong to them. Further log messages provide more
information to distinguish between these different cases.

% ALLOC_ENGINE_V4_DECLINED_RECOVERED IPv4 address %1 was recovered after %2 seconds of probation-period
This informational message indicates that the specified address was reported
as duplicate (client sent DECLINE) and the server marked this address as
unavailable for a period of time. This time now has elapsed and the address
has been returned to the available pool. This step concludes the decline recovery
process.

% ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT %1: conflicting reservation for address %2 with existing lease %3
This warning message is issued when the DHCP server finds that the
address reserved for the client can't be offered because this address
is currently allocated to another client. The server will try to allocate
a different address to the client to use until the conflict is resolved.
The first argument includes the client identification information.

% ALLOC_ENGINE_V4_DISCOVER_HR client %1 sending DHCPDISCOVER has reservation for the address %2
This message is issued when the allocation engine determines that the
client sending the DHCPDISCOVER has a reservation for the specified
address. The allocation engine will try to offer this address to
the client.

% ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed %1 leases in %2
This debug message is logged when the allocation engine completes
reclamation of a set of expired leases. The maximum number of leases
to be reclaimed in a single pass of the lease reclamation routine
is configurable using 'max-reclaim-leases' parameter. However,
the number of reclaimed leases may also be limited by the timeout
value, configured with 'max-reclaim-time'. The message includes the
number of reclaimed leases and the total time.

% ALLOC_ENGINE_V4_LEASES_RECLAMATION_FAILED reclamation of expired leases failed: %1
This error message is issued when the reclamation of the expired leases failed.
The error message is displayed.

% ALLOC_ENGINE_V4_LEASES_RECLAMATION_SLOW expired leases still exist after %1 reclamations
This warning message is issued when the server has been unable to
reclaim all expired leases in a specified number of consecutive
attempts. This indicates that the value of "reclaim-timer-wait-time"
may be too high. However, if this is just a short burst of leases'
expirations the value does not have to be modified and the server
should deal with this in subsequent reclamation attempts. If this
is a result of a permanent increase of the server load, the value
of "reclaim-timer-wait-time" should be decreased, or the
values of "max-reclaim-leases" and "max-reclaim-time" should be
increased to allow processing more leases in a single cycle.
Alternatively, these values may be set to 0 to remove the
limitations on the number of leases and duration. However, this
may result in longer periods of server's unresponsiveness to
DHCP packets, while it processes the expired leases.

% ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)
This debug message is issued when the allocation engine starts the
reclamation of the expired leases. The maximum number of leases to
be reclaimed and the timeout is included in the message. If any of
these values is 0, it means "unlimited".

% ALLOC_ENGINE_V4_LEASES_RECLAMATION_TIMEOUT timeout of %1 ms reached while reclaiming IPv4 leases
This debug message is issued when the allocation engine hits the
timeout for performing reclamation of the expired leases. The
reclamation will now be interrupted and all leases which haven't
been reclaimed, because of the timeout, will be reclaimed when the
next scheduled reclamation is started. The argument is the timeout
value expressed in milliseconds.

% ALLOC_ENGINE_V4_LEASE_RECLAIM %1: reclaiming expired lease for address %2
This debug message is issued when the server begins reclamation of the
expired DHCPv4 lease. The first argument specifies the client identification
information. The second argument holds the leased IPv4 address.

% ALLOC_ENGINE_V4_LEASE_RECLAMATION_FAILED failed to reclaim the lease %1: %2
This error message is logged when the allocation engine fails to
reclaim an expired lease. The reason for the failure is included in the
message. The error may be triggered in the lease expiration hook or
while performing the operation on the lease database.

% ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
This debug message is issued when the server reclaims all expired
DHCPv4 leases in the database.

% ALLOC_ENGINE_V4_OFFER_EXISTING_LEASE allocation engine will try to offer existing lease to the client %1
This message is issued when the allocation engine determines that
the client has a lease in the lease database, it doesn't have
reservation for any other lease, and the leased address is not
reserved for any other client. The allocation engine will try
to offer the same lease to the client.

% ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client %1
This message is issued when the allocation engine will try to
offer a new lease to the client. This is the case when the
client doesn't have any existing lease, it has no reservation
or the existing or reserved address is leased to another client.
Also, the client didn't specify a hint, or the address in
the hint is in use.

% ALLOC_ENGINE_V4_OFFER_REQUESTED_LEASE allocation engine will try to offer requested lease %1 to the client %2
This message is issued when the allocation engine will try to
offer the lease specified in the hint. This situation may occur
when: (a) client doesn't have any reservations, (b) client has
reservation but the reserved address is leased to another client.

% ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than %1 seconds ago
This debug message is issued when the allocation engine begins
deletion of the reclaimed leases which have expired more than
a specified number of seconds ago. This operation is triggered
periodically according to the "flush-reclaimed-timer-wait-time"
parameter. The "hold-reclaimed-time" parameter defines a number
of seconds for which the leases are stored before they are
removed.

% ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted %1 expired-reclaimed leases
This debug message is issued when the server successfully deletes
"expired-reclaimed" leases from the lease database. The number of
deleted leases is included in the log message.

% ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: %1
This error message is issued when the deletion of "expired-reclaimed"
leases from the database failed. The error message is appended to
the log message.

% ALLOC_ENGINE_V4_REQUEST_ADDRESS_RESERVED %1: requested address %2 is reserved
This message is issued when the allocation engine refused to
allocate address requested by the client because this
address is reserved for another client. The first argument
includes the client identification information.

% ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED %1: trying to allocate requested address %2
This message is issued when the allocation engine is trying
to allocate (or reuse an expired) address which has been
requested by the client. The first argument includes the
client identification information.

% ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE %1: extending lifetime of the lease for address %2
This message is issued when the allocation engine determines
that the client already has a lease whose lifetime can be
extended, and which can be returned to the client.
The first argument includes the client identification information.

% ALLOC_ENGINE_V4_REQUEST_INVALID client %1 having a reservation for address %2 is requesting invalid address %3
This message is logged when the client, having a reservation for
one address, is requesting a different address. The client is
only allowed to do this when the reserved address is in use by
another client. However, the allocation engine has
determined that the reserved address is available and the
client should request the reserved address.

% ALLOC_ENGINE_V4_REQUEST_IN_USE %1: requested address %2 is in use
This message is issued when the client is requesting or has a
reservation for an address which is in use. The first argument
includes the client identification information.

% ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL client %1, which doesn't have a reservation, requested address %2 out of the dynamic pool
This message is issued when the client has requested allocation
of the address which doesn't belong to any address pool from
which addresses are dynamically allocated. The client also
doesn't have reservation for this address. This address
could only be allocated if the client had reservation for it.

% ALLOC_ENGINE_V4_REQUEST_PICK_ADDRESS client %1 hasn't specified an address - picking available address from the pool
This message is logged when the client hasn't specified any
preferred address (the client should always do it, but Kea
tries to be forgiving). The allocation engine will try to pick an available
address from the dynamic pool and allocate it to the client.

% ALLOC_ENGINE_V4_REQUEST_REMOVE_LEASE %1: removing previous client's lease %2
This message is logged when the allocation engine removes previous
lease for the client because the client has been allocated new one.

% ALLOC_ENGINE_V4_REQUEST_USE_HR client %1 hasn't requested specific address, using reserved address %2
This message is issued when the client is not requesting any specific
address but the allocation engine has determined that there is a
reservation for this client. The allocation engine will try to
allocate the reserved address.

% ALLOC_ENGINE_V4_REUSE_EXPIRED_LEASE_DATA %1: reusing expired lease, updated lease information: %2
This message is logged when the allocation engine is reusing
an existing lease. The details of the updated lease are
printed. The first argument includes the client identification
information.

% ALLOC_ENGINE_V6_ALLOC_ERROR %1: error during attempt to allocate an IPv6 address: %2
An error occurred during an attempt to allocate an IPv6 address, the
reason for the failure being contained in the message.  The server will
return a message to the client refusing a lease. The first argument
includes the client identification information.

% ALLOC_ENGINE_V6_ALLOC_FAIL %1: failed to allocate an IPv6 lease after %2 attempt(s)
This is an old warning message issued when the allocation engine fails to allocate a
lease for a client. This message includes a number of lease allocation attempts
that the engine made before giving up. If the number of attempts is 0 because the
engine was unable to use any of the pools for the particular client, this message
is not logged. Even though, several more detailed logs precede this message, it was
left for backward compatibility.

This message may indicate that your pool is too small for the number of clients
you are trying to service and should be expanded. Alternatively, if the you know
that the number of concurrently active clients is less than the leases you have
available, you may want to consider reducing the lease lifetime. This way, leases
allocated to clients that are no longer active on the network will become available
sooner.

% ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES %1: Failed to allocate an IPv6 address for client with classes: %2
This warning message is printed when Kea failed to allocate an address
and the client's packet belongs to one or more classes. There may be several
reasons why a lease was not assigned. One of them may be a case when all
pools require packet to belong to certain classes and the incoming packet
didn't belong to any of them. Another case where this information may be
useful is to point out that the pool reserved to a given class has ran
out of addresses. When you see this message, you may consider checking your
pool size and your classification definitions.

% ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS %1: no pools were available for the lease allocation
This warning message is issued when the allocation engine fails to
allocate a lease because it could not use any configured pools for the
particular client. It is also possible that all of the subnets from
which the allocation engine attempted to assign an address lack address
pools. In this case, it should be considered misconfiguration if an
operator expects that some clients should be assigned dynamic addresses.
A subnet may lack any pools only when all clients should be assigned
reserved leases.

Suppose the subnets connected to a shared network or a single subnet to
which the client belongs have pools configured. In that case, this
message is an indication that none of the pools could be used for the
client because the client does not belong to appropriate client classes.

% ALLOC_ENGINE_V6_ALLOC_FAIL_SHARED_NETWORK %1: failed to allocate a lease in the shared network %2: %3 subnets have no available leases, %4 subnets have no matching pools
This warning message is issued when the allocation engine fails to allocate
a lease for a client connected to a shared network. The shared network should
contain at least one subnet, but typically it aggregates multiple subnets.
This log message indicates that the allocation engine could not find and
allocate any suitable lease in any of the subnets within the shared network.

The first argument includes the client identification information. The
second argument specifies the shared network name. The remaining two
arguments provide additional information useful for debugging why the
allocation engine could not assign a lease. The allocation engine tries
to allocate leases from different subnets in the shared network, and
it may fail for some subnets because there are no leases available in
those subnets or the free leases are reserved to other clients. The
number of such subnets is specified in the third argument. For other
subnets the allocation may fail because their pools may not be available
to the particular client. These pools are guarded by client classes that
the client does not belong to. The fourth argument specifies the number
of such subnets. By looking at the values in the third and fourth argument,
an operator can identify the situations when there are no leases left
in some of the pools. He or she can also identify client classification
misconfigurations causing some clients to be refused the service.

% ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET %1: failed to allocate an IPv6 lease in the subnet %2, subnet-id %3, shared network %4
This warning message is issued when the allocation engine fails to allocate
a lease for a client connected to a subnet. The first argument includes the
client identification information. The second and third arguments identify
the subnet. The fourth argument specifies the shared network, if the subnet
belongs to a shared network.

There are many reasons for failing lease allocations. One of them may be the
pools exhaustion or existing reservations for the free leases. However, in
some cases, the allocation engine may fail to find a suitable pool for the
client when the pools are only available to certain client classes, but the
requesting client does not belong to them. Further log messages provide more
information to distinguish between these different cases.

% ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS %1: lease type %2 for reserved address/prefix %3 already exists
This debug message is issued when the allocation engine determines that
the lease for the IPv6 address or prefix has already been allocated
for the client and the client can continue using it. The first argument
includes the client identification information.

% ALLOC_ENGINE_V6_ALLOC_LEASES_HR leases and static reservations found for client %1
This message is logged when the allocation engine is in the process of
allocating leases for the client, it found existing leases and static
reservations for the client. The allocation engine will verify if
existing leases match reservations. Those leases that are reserved for
other clients and those that are not reserved for the client will
be removed. All leases matching the reservations will be renewed
and returned.

% ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR no reservations found but leases exist for client %1
This message is logged when the allocation engine is in the process if
allocating leases for the client, there are no static reservations,
but lease(s) exist for the client. The allocation engine will remove
leases which are reserved for other clients, and return all
remaining leases to the client.

% ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for client %1
This message is logged when the allocation engine is in the process of
allocating leases for the client. It hasn't found any existing leases
for this client, but the client appears to have static reservations.
The allocation engine will try to allocate the reserved resources for
the client.

% ALLOC_ENGINE_V6_ALLOC_NO_V6_HR %1: unable to allocate reserved leases - no IPv6 reservations
This message is logged when the allocation engine determines that the
client has no IPv6 reservations and thus the allocation engine will have
to try to allocate allocating leases from the dynamic pool or stop
the allocation process if none can be allocated. The first argument
includes the client identification information.

% ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available - trying to dynamically allocate leases for client %1
This debug message is issued when the allocation engine will attempt
to allocate leases from the dynamic pools.  This may be due to one of
(a) there are no reservations for this client, (b) there are
reservations for the client but they are not usable because the addresses
are in use by another client or (c) we had a reserved lease but that
has now been allocated to another client.

% ALLOC_ENGINE_V6_CALCULATED_PREFERRED_LIFETIME %1: using a calculated preferred-lifetime of %2
This debug message indicates that the preferred-lifetime being returned
to the client is defaulting to 62.5% of the valid-lifetime.  This may
occur if either the preferred-lifetime has not been explicitly configured,
or the configured value is larger than the valid-lifetime.  The arguments
detail the client and the preferred-lifetime that will be used.

% ALLOC_ENGINE_V6_DECLINED_RECOVERED IPv6 address %1 was recovered after %2 seconds of probation-period
This informational message indicates that the specified address was reported
as duplicate (client sent DECLINE) and the server marked this address as
unavailable for a period of time. This time now has elapsed and the address
has been returned to the available pool. This step concludes the decline recovery
process.

% ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED %1: expired lease for the client's hint %2 is reserved for another client
This message is logged when the allocation engine finds that the
expired lease for the client's hint can't be reused because it
is reserved for another client. The first argument includes the
client identification information.

% ALLOC_ENGINE_V6_EXTEND_ALLOC_UNRESERVED allocate new (unreserved) leases for the renewing client %1
This debug message is issued when the allocation engine is trying to
allocate new leases for the renewing client because it was unable to
renew any of the existing client's leases, e.g. because leases are
reserved for another client or for any other reason.

% ALLOC_ENGINE_V6_EXTEND_ERROR %1: allocation engine experienced error with attempting to extend lease lifetime: %2
This error message indicates that an error was experienced during Renew
or Rebind processing. Additional explanation is provided with this
message. Depending on its nature, manual intervention may be required to
continue processing messages from this particular client; other clients
will be unaffected. The first argument includes the client identification
information.

% ALLOC_ENGINE_V6_EXTEND_LEASE %1: extending lifetime of the lease type %2, address %3
This debug message is issued when the allocation engine is trying
to extend lifetime of the lease. The first argument includes the
client identification information.

% ALLOC_ENGINE_V6_EXTEND_LEASE_DATA %1: detailed information about the lease being extended: %2
This debug message prints detailed information about the lease which
lifetime is being extended (renew or rebind). The first argument
includes the client identification information.

% ALLOC_ENGINE_V6_EXTEND_NEW_LEASE_DATA %1: new lease information for the lease being extended: %2
This debug message prints updated information about the lease to be
extended. If the lease update is successful, the information printed
by this message will be stored in the database. The first argument
includes the client identification information.

% ALLOC_ENGINE_V6_HINT_RESERVED %1: lease for the client's hint %2 is reserved for another client
This message is logged when the allocation engine cannot allocate
the lease using the client's hint because the lease for this hint
is reserved for another client. The first argument includes the
client identification information.

% ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address %1 was assigned to client %2
This informational message signals that the specified client was assigned the address
reserved for it.

% ALLOC_ENGINE_V6_HR_PREFIX_GRANTED reserved prefix %1/%2 was assigned to client %3
This informational message signals that the specified client was assigned the prefix
reserved for it.

% ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE reclaimed %1 leases in %2
This debug message is logged when the allocation engine completes
reclamation of a set of expired leases. The maximum number of leases
to be reclaimed in a single pass of the lease reclamation routine
is configurable using 'max-reclaim-leases' parameter. However,
the number of reclaimed leases may also be limited by the timeout
value, configured with 'max-reclaim-time'. The message includes the
number of reclaimed leases and the total time.

% ALLOC_ENGINE_V6_LEASES_RECLAMATION_FAILED reclamation of expired leases failed: %1
This error message is issued when the reclamation of the expired leases failed.
The error message is displayed.

% ALLOC_ENGINE_V6_LEASES_RECLAMATION_SLOW expired leases still exist after %1 reclamations
This warning message is issued when the server has been unable to
reclaim all expired leases in a specified number of consecutive
attempts. This indicates that the value of "reclaim-timer-wait-time"
may be too high. However, if this is just a short burst of leases'
expirations the value does not have to be modified and the server
should deal with this in subsequent reclamation attempts. If this
is a result of a permanent increase of the server load, the value
of "reclaim-timer-wait-time" should be decreased, or the
values of "max-reclaim-leases" and "max-reclaim-time" should be
increased to allow processing more leases in a single cycle.
Alternatively, these values may be set to 0 to remove the
limitations on the number of leases and duration. However, this
may result in longer periods of server's unresponsiveness to
DHCP packets, while it processes the expired leases.

% ALLOC_ENGINE_V6_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)
This debug message is issued when the allocation engine starts the
reclamation of the expired leases. The maximum number of leases to
be reclaimed and the timeout is included in the message. If any of
these values is 0, it means "unlimited".

% ALLOC_ENGINE_V6_LEASES_RECLAMATION_TIMEOUT timeout of %1 ms reached while reclaiming IPv6 leases
This debug message is issued when the allocation engine hits the
timeout for performing reclamation of the expired leases. The
reclamation will now be interrupted and all leases which haven't
been reclaimed, because of the timeout, will be reclaimed when the
next scheduled reclamation is started. The argument is the timeout
value expressed in milliseconds.

% ALLOC_ENGINE_V6_LEASE_RECLAIM %1: reclaiming expired lease for prefix %2/%3
This debug message is issued when the server begins reclamation of the
expired DHCPv6 lease. The reclaimed lease may either be an address lease
or delegated prefix. The first argument provides the client identification
information. The other arguments specify the prefix and the prefix length
for the lease. The prefix length for address lease is equal to 128.

% ALLOC_ENGINE_V6_LEASE_RECLAMATION_FAILED failed to reclaim the lease %1: %2
This error message is logged when the allocation engine fails to
reclaim an expired lease. The reason for the failure is included in the
message. The error may be triggered in the lease expiration hook or
while performing the operation on the lease database.

% ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
This debug message is issued when the server reclaims all expired
DHCPv6 leases in the database.

% ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than %1 seconds ago
This debug message is issued when the allocation engine begins
deletion of the reclaimed leases which have expired more than
a specified number of seconds ago. This operation is triggered
periodically according to the "flush-reclaimed-timer-wait-time"
parameter. The "hold-reclaimed-time" parameter defines a number
of seconds for which the leases are stored before they are
removed.

% ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted %1 expired-reclaimed leases
This debug message is issued when the server successfully deletes
"expired-reclaimed" leases from the lease database. The number of
deleted leases is included in the log message.

% ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_FAILED deletion of expired-reclaimed leases failed: %1
This error message is issued when the deletion of "expired-reclaimed"
leases from the database failed. The error message is appended to
the log message.

% ALLOC_ENGINE_V6_RENEW_HR allocating leases reserved for the client %1 as a result of Renew
This debug message is issued when the allocation engine tries to
allocate reserved leases for the client sending a Renew message.
The server will also remove any leases that the client is trying
to renew that are not reserved for the client.

% ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED %1: checking if existing client's leases are reserved for another client
This message is logged when the allocation engine finds leases for
the client and will check if these leases are reserved for another
client. If they are, they will not be renewed for the client
requesting their renewal. The first argument includes the client
identification information.

% ALLOC_ENGINE_V6_RENEW_REMOVE_UNRESERVED dynamically allocating leases for the renewing client %1
This debug message is issued as the allocation engine is trying
to dynamically allocate new leases for the renewing client. This
is the case when the server couldn't renew any of the existing
client's leases, e.g. because leased resources are reserved for
another client.

% ALLOC_ENGINE_V6_REUSE_EXPIRED_LEASE_DATA %1: reusing expired lease, updated lease information: %2
This message is logged when the allocation engine is reusing
an existing lease. The details of the updated lease are
printed. The first argument includes the client identification
information.

% ALLOC_ENGINE_V6_REVOKED_ADDR_LEASE address %1 was revoked from client %2 as it is reserved for client %3
This informational message is an indication that the specified IPv6
address was used by client A but it is now reserved for client B. Client
A has been told to stop using it so that it can be leased to client B.
This is a normal occurrence during conflict resolution, which can occur
in cases such as the system administrator adding a reservation for an
address that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their addresses.

% ALLOC_ENGINE_V6_REVOKED_PREFIX_LEASE prefix %1/%2 was revoked from client %3 as it is reserved for client %4
This informational message is an indication that the specified IPv6
prefix was used by client A but it is now reserved for client B. Client
A has been told to stop using it so that it can be leased to client B.
This is a normal occurrence during conflict resolution, which can occur
in cases such as the system administrator adding a reservation for an
address that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their prefixes.

% ALLOC_ENGINE_V6_REVOKED_SHARED_ADDR_LEASE address %1 was revoked from client %2 as it is reserved for %3 other clients
This informational message is an indication that the specified IPv6
address was used by client A but it is now reserved for multiple other
clients. Client A has been told to stop using it so that it can be
leased to one of the clients having the reservation for it. This is a
normal occurrence during conflict resolution, which can occur in cases
such as the system administrator adding reservations for an address
that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their addresses.

% ALLOC_ENGINE_V6_REVOKED_SHARED_PREFIX_LEASE prefix %1/%2 was revoked from client %3 as it is reserved for %4 other clients
This informational message is an indication that the specified IPv6
prefix was used by client A but it is now reserved for multiple other
clients. Client A has been told to stop using it so that it can be
leased to one of the clients having the reservation for it. This is a
normal occurrence during conflict resolution, which can occur in cases
such as the system administrator adding reservations for an address
that is currently in use by another client.  The server will fully
recover from this situation, but clients will change their prefixes.