Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-13T18:35:36Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/237ISC DHCP per class lease limit2023-07-13T18:35:36ZFrancis DupontISC DHCP per class lease limitQuote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficul...Quote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficult for a
new client in a class to get an address. Once a class with such a
limit has reached its limit, the only way a new client in that class
can get a lease is for an existing client to relinquish its lease,
either by letting it expire, or by sending a DHCPRELEASE packet.
Classes with lease limits are specified as follows:
class "limited-1" {
lease limit 4;
}
This will produce a class in which a maximum of four members may hold a
lease at one time.
>>>
Often associated with cloned classes. Requested by a customer but a priori not easy to implement.
Note that in Kea lease assignment is done before calling setReservedClientClasses.
Support tickets: [support#18293](https://support.isc.org/Ticket/Display.html?id=18293), [support#17523](https://support.isc.org/Ticket/Display.html?id=17523), [support#19968](https://support.isc.org/Ticket/Display.html?id=19968)
Being implemented in Kea.ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/234ISC DHCP log executable statement2023-07-13T18:33:07ZFrancis DupontISC DHCP log executable statementAccording to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
...According to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
(fatal, error, info, or debug), and a data expression.
Logging statements take only a single data expression argument, so if
you want to output multiple data values, you will need to use the
concat operator to concatenate them.
>>>
It is an interesting feature which was discussed before (cf #4124).
To implement it in the ISC DHCP style we need 3 parameters:
- a boolean expression
- a priority
- a string expression to log
It does not seem so hard to do...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/232Kea supports only Ethernet hardware type2022-11-02T15:08:43ZFrancis DupontKea supports only Ethernet hardware typeISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.ISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/226ISC DHCP server config option adaptive-lease-time-threshold2022-11-02T15:08:42ZFrancis DupontISC DHCP server config option adaptive-lease-time-threshold>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease len...>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease length for new clients within this pool to min-lease-time sec-
onds. Clients renewing an already valid (long) leases get at least
the remaining time from the current lease. Since the leases expire
faster, the server may either recover more quickly or avoid pool
exhaustion entirely. Once the number of allocated leases drop below
the threshold, the server reverts back to normal lease times. Valid
percentages are between 1 and 99.
>>>
A good idea for a lease allocation hook library.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/221Kea vs ISC DHCP timers2022-11-02T15:08:43ZFrancis DupontKea vs ISC DHCP timersISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are...ISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are different). As the valid-lifetime is a mandatory config parameter this means Kea is rigid (same comment).
For other timers ISC DHCP has preferred-lifetime but derives t1 and t2 (aka renew and rebind timers) from the valid one using standard formula. ISC DHCP follows more the client query, i.e., it uses configured values including computed values only as default and bounds.
This is not a call to change something: it is just a summary for documentation and some infos in the case a customer requests more flexibility.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/218ISC DHCP server config option stash-agent-options2023-07-12T16:34:35ZFrancis DupontISC DHCP server config option stash-agent-optionsThe stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST...The stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST message when the client
was in the SELECTING state and behave as if those options are
included in all subsequent DHCPREQUEST messages sent in the RENEWING
state. This works around a problem with relay agent information
options, which is that they usually not appear in DHCPREQUEST
messages sent by the client in the RENEWING state, because such
messages are unicast directly to the server and not sent through a
relay agent.
>>>
It is a real issue (for DHCPv4, in DHCPv6 the server controls the use of unicast (i.e. direct communication) by the client) but I have no idea how (or whether) it is handled by Kea...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/217scoped D2 client config2022-11-02T15:08:43ZFrancis Dupontscoped D2 client configReading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue a...Reading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue about this but if we do the minimum it should be this.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/266ISC DHCP release on roam flag2022-11-02T15:08:42ZFrancis DupontISC DHCP release on roam flag>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on t...>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on the old network and emit a log statement
similiar to the following:
"Client: <id> roamed to new network, releasing lease:
<address>"
The server will carry out all of the same steps that would nor-
mally occur when a client explicitly releases a lease. When
release-on-roam is disabled (the default) the server makes such
leases unavailable until they expire or the server is restarted.
Clients that need leases in multiple networks must supply a
unique IAID in each IA. This parameter may only be specified at
the global level.
>>>
Make sense for a moving client which for some reasons does not release its address at the previous location. Can be implemented in Kea if there is an easy and fast way to get leases by IAID+DUID only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/265ISC DHCP eui-64 based allocation2022-11-02T15:08:42ZFrancis DupontISC DHCP eui-64 based allocationQuoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (...Quoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (Type 3, HW
Type EUI-64), rather than creating an address using the dynamic
algorithm. This means that a given DUID will always generate
the same address for a given pool and further that the address
is guaranteed to be unique to that DUID. The IPv6 address will
be calculated from the EUI-64 link layer address, conforming to
RFC 2373, unless there is a host declaration for the client-id.
The range6 statement for EUI-64 must define full /64 bit ranges.
Invalid ranges will be flagged during configuration parsing as
errors. See the following example:
subnet6 fc00:e4::/64 {
use-eui-64 true;
range6 fc00:e4::/64;
}
The statement may be specified down to the pool level, allowing
a mixture of dynamic and EUI-64 based pools.
During lease file parsing, any leases which map to an EUI-64
pool, that have a non-EUI-64 DUID or for which the lease address
is not the EUI-64 address for that DUID in that pool, will be
discarded.
If a host declaration exists for the DUID, the server grants the
address (fixed-prefix6, fixed-address6) according to the host
declaration, regardless of the DUID type of the client (even for
EUI-64 DUIDs).
If a client request's an EUI-64 lease for a given network, and
the resultant address conflicts with a fixed address reserva-
tion, the server will send the client a "no addresses available"
response.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Pools that are configured for EUI-64 will be skipped for dynamic
allocation. If there are no pools in the shared network from
which to allocate, the client will get back a no addresses
available status.
On an EUI-64 enabled pool, any client with a DUID 3, HW Type
EUI-64, requesting a solicit/renew and including IA_NA that do
not match the EUI-64 policy, they will be treated as though they
are "outside" the subnet for a given client message:
Solicit - Server will advertise with EUI-64 ia suboption,
but with rapid
commit off
Request - Server will send "an address not on link status",
and no ia
suboption Renew/Rebind - Server will send the requested
address ia
suboption with lifetimes of 0, plus an EUI-64 ia
Whether or not EUI-64 based leases are written out to the lease
database may be controlled by persist-eui-64-leases statement.
>>>
Added to ISC DHCP as an optional feature on customer request. Can be ported to Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/250enforce an option in response2023-07-17T19:16:24ZFrancis Dupontenforce an option in responseISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(...ISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(option dhcp-parameter-request-list, fc);
```
The dhcp-parameter-request-list (aka PRL) option in received packets is patched to add the code fc (252) so responses will include it.
This feature was ported to Kea as the **always-send** option-data flag.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/249No shared-network pools2022-11-02T15:08:44ZFrancis DupontNo shared-network poolsIn Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.In Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/247ISC DHCP expression2022-11-02T15:08:44ZFrancis DupontISC DHCP expressionISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to se...ISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to set an option to true:
```
option ip-forwarding = true;
```
This does not work because true is not a keyword and is parsed as a variable reference. As it is not set at runtime it will be evaluated as null so false...
If you try a constant true expression (aka tautology):
```
option ip-forwarding = 'foo' = 'foo';
```
In this case you specify a boolean expression when the system wants a data expression so refused this attempt at parsing time.
Note it is worse for integers, in:
```
option default-ip-ttl = 12;
```
the 12 is in hexadecimal so in fact is 18... If you want a decimal value you need a context where a number is expected.
Cf KB references:
https://kb.isc.org/article/AA-00334/56/Do-the-list-of-parameters-in-the-dhcp-parameter-request-list-need-to-be-in-hex.html
and about inconsistencies in output/display:
https://kb.isc.org/article/AA-01039/56/Formatting-MAC-addresses-in-dhcpd-or-why-does-binary-to-ascii-strip-leading-zeroes.htmlbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/246ISC DHCP supports an ASCII or binary option type2022-11-02T15:08:44ZFrancis DupontISC DHCP supports an ASCII or binary option typeISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches strin...ISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches string but X can be either string or binary.
Now only one standard option has a trailing X so the implementation converts X to string (option-def) and when building data (option-data) converts full binary input to binary with csv-format to false. For trailing X add a comment saying that the last type should be changed to binary.
Unfortunately mostly for documentation purpose.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/245ISC DHCP users specify interfaces on the command line2022-11-02T15:08:42ZFrancis DupontISC DHCP users specify interfaces on the command lineThere is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done o...There is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done other to be aware.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/244ISC DHCP server hostname (vs IPv4 address) in option data2022-11-02T15:08:44ZFrancis DupontISC DHCP server hostname (vs IPv4 address) in option dataWhen it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the fi...When it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the first view but in fact is not, in particular for option values.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/243duplicate in ISC DHCP configuration2023-07-17T19:08:12ZFrancis Dupontduplicate in ISC DHCP configurationISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple...ISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple option definitions
- multiple host (aka reservation) definitions sharing the same address
The last two are IMHO errors so I commented them out. In conclusion the problem is more on the ISC DHCP side and to accept less duplication in Kea is both right and should be spread.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/242ISC DHCP server config option server-id-check2023-07-17T19:04:26ZFrancis DupontISC DHCP server config option server-id-check>>>
The server-id-check statement
**server-id-check** flag;
The server-id-check statement is used to control whether or not a
server, participating in failover, verifies that the value of the
dhcp-server-identifier option in received D...>>>
The server-id-check statement
**server-id-check** flag;
The server-id-check statement is used to control whether or not a
server, participating in failover, verifies that the value of the
dhcp-server-identifier option in received DHCP REQUESTs match the
server's id before processing the request. Server id checking is
disabled by default. Setting this flag enables id checking and
thereafter the server will only process requests that match. Note
the flag setting should be consistent between failover partners.
Unless overridden by use of the server-identifier statement, the
value the server uses as its id will be the first IP address asso-
ciated with the physical network interface on which the request
arrived.
In order to reduce runtime overhead the server only checks for a
server id option in the global and subnet scopes. Complicated
configurations may result in different server ids for this check
and when the server id for a reply packet is determined, which
would prohibit the server from responding.
The primary use for this option is when a client broadcasts a
request but requires that the response come from a specific
failover peer. An example of this would be when a client reboots
while its lease is still active - in this case both servers will
normally respond. Most of the time the client won't check the
server id and can use either of the responses. However if the
client does check the server id it may reject the response if it
came from the wrong peer. If the timing is such that the "wrong"
peer responds first most of the time the client may not get an
address for some time.
Care should be taken before enabling this option.
>>>
Dubious idea: for documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/241ISC DHCP server config option always-broadcast2022-11-02T15:08:44ZFrancis DupontISC DHCP server config option always-broadcast>>>
The always-broadcast statement
**always-broadcast** flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to
set the broadcast bit in the flags field of the BOOTP message header.
Unfortunately, some DHCP and BOOTP ...>>>
The always-broadcast statement
**always-broadcast** flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to
set the broadcast bit in the flags field of the BOOTP message header.
Unfortunately, some DHCP and BOOTP clients do not do this, and there-
fore may not receive responses from the DHCP server. The DHCP server
can be made to always broadcast its responses to clients by setting
this flag to 'on' for the relevant scope; relevant scopes would be
inside a conditional statement, as a parameter for a class, or as a
parameter for a host declaration. To avoid creating excess broadcast
traffic on your network, we recommend that you restrict the use of
this option to as few clients as possible. For example, the
Microsoft DHCP client is known not to have this problem, as are the
OpenTransport and ISC DHCP clients.
>>>
Dubious idea in particular if there is no broken client requiring this hack. For documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/240ISC DHCP server config option get-lease-hostnames2022-11-02T15:08:44ZFrancis DupontISC DHCP server config option get-lease-hostnames>>>
The get-lease-hostnames statement
**get-lease-hostnames** flag;
The get-lease-hostnames statement is used to tell dhcpd whether or
not to look up the domain name corresponding to the IP address of
each address in the lease pool and...>>>
The get-lease-hostnames statement
**get-lease-hostnames** flag;
The get-lease-hostnames statement is used to tell dhcpd whether or
not to look up the domain name corresponding to the IP address of
each address in the lease pool and use that address for the DHCP
hostname option. If flag is true, then this lookup is done for all
addresses in the current scope. By default, or if flag is false, no
lookups are done.
>>>
The idea is to perform a reverse DNS lookup to find the corresponding hostname in place of the provisioning system or the client... For documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/239ISC DHCP server config booting keyword2023-07-17T18:59:35ZFrancis DupontISC DHCP server config booting keyword>>>
The booting keyword
**allow booting;**
**deny booting;**
**ignore booting;**
The booting flag is used to tell dhcpd whether or not to respond to
queries from a particular client. This keyword only has meaning when
it appears in a...>>>
The booting keyword
**allow booting;**
**deny booting;**
**ignore booting;**
The booting flag is used to tell dhcpd whether or not to respond to
queries from a particular client. This keyword only has meaning when
it appears in a host declaration. By default, booting is allowed, but
if it is disabled for a particular client, then that client will not be
able to get an address from the DHCP server.
>>>
It looks like an indirect way to add a reservation without address. The only action should be to check Kea supports this case?backlog