Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-07-13T18:33:07Zhttps://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/235ISC DHCP "class-like" if statements2023-07-17T18:49:15ZFrancis DupontISC DHCP "class-like" if statementsThis ticket is about how to convert this ISC DHCP config style:
```
subnet 10.208.0.0 netmask 255.255.128.0 {
option subnet-mask 255.255.128.0 ;
if substring (option vendor-class-identifier,0,4) = "MSFT"{
...This ticket is about how to convert this ISC DHCP config style:
```
subnet 10.208.0.0 netmask 255.255.128.0 {
option subnet-mask 255.255.128.0 ;
if substring (option vendor-class-identifier,0,4) = "MSFT"{
option routers 10.208.0.1 ;
option domain-name-servers 10.237.3.4, 10.237.3.5 ;
}
if substring (option vendor-class-identifier,0,2) = "RG"{
option classless-routes = 0F:0A:EC:0A:D0:00:01 ;
}
pool {
deny members of "MotoVIP";
range 10.208.64.1 10.208.127.254;
}
}
```
(old discussion)
The 2 if (and the "MotoVIIP" class uses an test expression which can be easily converted into a match if defining a class. The domain-name-servers option shares the same value but not the routers or the classless-routes so it is not possible to set all these parameters in class definitions.
As there is no subnet related class selector (for two reasons: classes are globally defined and classes are used to select subnets so can't depend on them) the idea should to split the subnet into class-dependent subnets. It works well for the subnet selection and parameter setting but not for the pool: range conflicts are detected when they occur inside a subnet, not yet (cf Trac 2346) between subnets but clearly do *not* work.
So IMHO it is a good place for shared networks (cf Kea 5273)... (implemented since this comment)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/236ISC DHCP and Kea shared-networks are not the same2023-07-13T18:42:08ZFrancis DupontISC DHCP and Kea shared-networks are not the sameThis ticket documents differences between ISC DHCP and Kea shared-networks:
- in ISC DHCP any subnet is a member of a shared-network, e.g. the config parser creates an anonymous one when it finds a "plain" subnet
- in ISC DHCP localizat...This ticket documents differences between ISC DHCP and Kea shared-networks:
- in ISC DHCP any subnet is a member of a shared-network, e.g. the config parser creates an anonymous one when it finds a "plain" subnet
- in ISC DHCP localization aka subnet selection in fact selects a shared-network. In Kea the selected subnet has some kind of priority over its siblings in the shared-network
- Kea shared-networks come with a performance penalty for resources to access at the shared-network level vs the selected subnet
To be reference by the MA for shared-networks with more than one subnet (with one subnet the shared-network is removed).backloghttps://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/238ISC DHCP server config option one-lease-per-client2023-07-13T18:45:31ZFrancis DupontISC DHCP server config option one-lease-per-client>>>
The one-lease-per-client statement
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presume...>>>
The one-lease-per-client statement
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presumes that when the client sends a DHCPRE-
QUEST, it has forgotten any lease not mentioned in the DHCPREQUEST -
i.e., the client has only a single network interface and it does not
remember leases it's holding on networks to which it is not currently
attached. Neither of these assumptions are guaranteed or provable,
so we urge caution in the use of this statement.
>>>
Dubious utility: put here only for documentation purpose.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?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/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/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/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/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/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/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/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/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/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/251if hook is defined in config twice then all operations are made 2 times2023-07-31T13:52:07ZMichal Nowikowskiif hook is defined in config twice then all operations are made 2 timesif in config there is:
```
{
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}, {
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}
```
then operations like 'class-add' are performed 2 times.
In case of 'class-add...if in config there is:
```
{
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}, {
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}
```
then operations like 'class-add' are performed 2 times.
In case of 'class-add' the second one fails as there is already given class present.
UPDATE: See the discussion below. This is uncommon, but valid. However, Kea should print a warning if the same hook is loaded more than once.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/255kea-netconf (and other servers/agents) creating incorrectly named pid file2022-11-02T15:08:42ZWlodzimierz Wencelkea-netconf (and other servers/agents) creating incorrectly named pid filefile name is ```kea-netconf.kea-netconf.pid``` instead of ```kea-netconf.pid```
```
wlodek@debian9-64-2:~/installed$ cat git/var/kea/kea-netconf.kea-netconf.pid
16207
wlodek@debian9-64-2:~/installed$ ps -aux | grep kea
root 16206 0...file name is ```kea-netconf.kea-netconf.pid``` instead of ```kea-netconf.pid```
```
wlodek@debian9-64-2:~/installed$ cat git/var/kea/kea-netconf.kea-netconf.pid
16207
wlodek@debian9-64-2:~/installed$ ps -aux | grep kea
root 16206 0.0 0.2 47612 3216 pts/0 S+ 07:10 0:00 sudo git/sbin/kea-netconf -c kea-netconf.conf -d
root 16207 0.0 0.5 158128 9332 pts/0 S+ 07:10 0:00 git/sbin/kea-netconf -c kea-netconf.conf -d
wlodek 16341 0.0 0.0 11112 940 pts/1 S+ 07:11 0:00 grep kea
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/257Improve doxygen for IfaceMgr2022-11-02T15:08:44ZThomas MarkwalderImprove doxygen for IfaceMgrThe class commentary for IfaceMgr is extremely terse and needs to be expanded.The class commentary for IfaceMgr is extremely terse and needs to be expanded.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.backlog