Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:10:18Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/872Use hardware address in name generation for DDNS update requests2022-11-02T15:10:18ZGhost UserUse hardware address in name generation for DDNS update requests---
name: kea-dhcp4 Name Generation for DDNS Update Requests
about: Use hardware address (or something else) instead of ip address
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea ...---
name: kea-dhcp4 Name Generation for DDNS Update Requests
about: Use hardware address (or something else) instead of ip address
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? **Yes**
- Are you sure what you would like to do is not possible using some other mechanisms? **Maybe with hooks?**
- Have you discussed your idea on kea-users or kea-dev mailing lists? **No**
**Is your feature request related to a problem? Please describe.**
The automatic generation of a name for the DDNS update request is: [generated-prefix]-[address-text].[qualifying-suffix].
I need a name because I don't know the IP address, but this auto generated name contains the IP address... I need to manage some equipments that don't request the hostname or don't have it set.
**Describe the solution you'd like**
A solution can be to mangle the hw address instead of the IP address, or the possibility to choose. An example:
aa:bb:cc:dd:ee:ff -> aa-bb-cc-dd-ee-ff
**Describe alternatives you've considered**
Write an hook...
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? **No**
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? **Yes**
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/972Pool level DHCP options are ignored while returning ACK to client's INFORM2021-10-20T10:30:59ZGhost UserPool level DHCP options are ignored while returning ACK to client's INFORM**Bug Description**
For a client's DHCPINFORM message that requests (option 55) for a set of DHCP options, Kea ignores DHCP options in the pool configuration and only returns options specified in the subnet configuration while returning...**Bug Description**
For a client's DHCPINFORM message that requests (option 55) for a set of DHCP options, Kea ignores DHCP options in the pool configuration and only returns options specified in the subnet configuration while returning the DHCPACK
**To Reproduce**
For the example below, randomly selected option 67 (bootfile name) to test
1. Run Kea dhcpv4 with the following subnet config
```
"subnet4": [
{
"subnet": "192.168.5.0/24",
"pools": [
{
"pool": "192.168.5.111 - 192.168.5.222",
"option-data": [
{
"name": "boot-file-name",
"data": "poolLevel"
}]
}],
"option-data": [
{
"name": "boot-file-name",
"data": "subnetLevel"
}]
}
]
```
2. Client sends DHCPDISCOVER wherein client requests for Bootfile name (option 67) in the Parameter Request List (option 55)
3. Kea responds with DHCPOFFER that includes Bootfile name (option 67) with value `poolLevel` from pool configuration
4. Client follows up with DHCPREQUEST with the same list of options and Kea returns DHCPACK with the OFFER'd values.
5. Client sends DHCPINFORM requesting for Bootfile name (option 67) in the Parameter Request List (option 55)
6. Kea returns DHCPACK including Bootfile name (option 67) with unexpected value `subnetLevel`
**Expected behavior**
Server must respond to DHCPINFORM with values from the client's matching pool configuration in the DHCPACK, unless no such option is defined in the pool configuration.
In context of the example above, at step 6, server must return DHCPACK with value of Bootfile name (option 67) as `poolLevel`
**Environment:**
- Kea version: 1.7.1-git
git cf6a766d28c565bd4a0abe8631422dd9fdeb27ce
- OS: Ubuntu 18.04.2outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1012Add a require at least version in config syntax2019-12-12T16:59:48ZFrancis DupontAdd a require at least version in config syntaxThis feature will provide a way to say the configuration file requires at least a specified Kea version. Useful for Keama and Stork, or in general for any tool which builds configuration files.This feature will provide a way to say the configuration file requires at least a specified Kea version. Useful for Keama and Stork, or in general for any tool which builds configuration files.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1027Database reconnect settings ignored during startup2023-11-18T09:34:42ZChrisDatabase reconnect settings ignored during startup**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut...**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut down despite reconnect settings.
Since there is a chance for the SQL database to be available after kea is being started this can lead to kea not running after boot despite being expected to.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure Kea with mysql leases/reservations including reconnect options ("max-reconnect-tries": 10,"reconnect-wait-time": 1000)
2. Stop and start kea + mysql, kea before mysql
```
service isc-kea-dhcp4-server stop; service mysql stop; service isc-kea-dhcp4-server start; service mysql start; sleep 1; service isc-kea-dhcp4-server status;
```
3. See that no reconnect attempts were made
**Expected behavior**
Kea to use the reconnect options during startup
**Environment:**
- Kea version: 1.6.0
- OS: Ubuntu 18.04 x64
- From ISC Kea repository
- If/which hooks where loaded in: lease-commands, haoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1084Kea does not recover from interface down when Kea starts2024-02-08T14:35:31ZRob AusteinKea does not recover from interface down when Kea startsProblem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server i...Problem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server is part of a large rack of equipment, and we have no control over the order in which things come up, not to mention various replacement and reinstall scenarios. Kea quietly fails to listen on interfaces that show no carrier at the time Kea first starts, and never notices when they come up.
So far I have not thought of anything better than a separate process which monitors link states (eg with PyRoute2) and sends a config-reload control message whenever any of the interfaces comes up. This seems kind of lame.
Is this a known issue? Note that this is not the "new interface" problem: we know all the interfaces and list them in the config file, we just can't guarantee that they'll be up (and in some cases they *can't* come up until after Kea does because they're waiting for a DHCP lease in order to install the software that will eventually bring up the other end of the link).
Is this something ISC is likely to be able to fix anytime soon? Is there a better workaround?
Thanks! (Obligatory note: on the whole I'm very happy with Kea as a replacement for isc-dhcpd, don't think I'm complaining about the new thing... I just need to find a solution to this problem.)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1186JSON translator tool for CB2024-03-21T12:21:55ZPeter DaviesJSON translator tool for CB---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "pa...---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "parser libraries for servers (for netconf)
**Is your feature request related to a problem? Please describe.**
When migrating from a json based configuration to the Configuration Backend the user must identify each element in the configuration, locate the correct hooks command and apply the appropriate parameters
**Describe the solution you'd like**
A tool which takes a json configuration file as an input. The tool should identify any elements that are CB configurable for the current Kea version and produce a set of command which will create the appropriate elements in the CB.
**Describe alternatives you've considered**
As an extra function of keama
**Additional context**
Customer ticket RT [#16203](https://support.isc.org/Ticket/Display.html?id=16203)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1281Explore methods of enhancing lease synchronization2024-01-09T21:14:42ZPeter DaviesExplore methods of enhancing lease synchronization**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it...**Explore methods of enhancing lease synchronization**
To minimise the time taken to synchronize lease data when a primary Kea server comes online after an outage. Thereby minimise the time in which dhcp traffic is not processed.
Is it possible to speed up the convergence of lease data on a HA pair by giving a server knowledge of what leases its partner has?
Or a mechanism where Kea server could request only lease updates that were made while it was off line. Based either on time or maybe some serial nr? The case where one Kea server can be standby for more than one primary could make this difficult to implement.
Or some out-of-bounds method of copying the lease file contents?
RT [#16560](https://support.isc.org/Ticket/Display.html?id=16560)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1345Ability to always-respond to all requests in HA active-active mode to support...2021-01-22T13:30:51ZEwald van GeffenAbility to always-respond to all requests in HA active-active mode to support anycast DHCPMy impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closes...My impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closest ISC KEA instance according to BGP. Load balancing is externally handled. This means KEA should respond to all requests it receives and not impose any load-balancing logic.
I think this is where the magic happens [1]
From my understanding active_servers needs to reflect the current server instance id (pri,sec).
[1] https://github.com/isc-projects/kea/blob/457111f9db051723ff9f8e7fb621872d0aa10363/src/hooks/dhcp/high_availability/query_filter.cc#L316outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1365Implement MAC assignment (IA_LL option) - RFC8947, RFC89482022-10-14T11:20:06ZTomek MrugalskiImplement MAC assignment (IA_LL option) - RFC8947, RFC8948There are two drafts at IETF that are clearing IESG review and will likely soon be published as RFCs:
- [dhc-mac-assign](https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/) - now RFC8947
- [dhc-slap-quadrant](https://datatracke...There are two drafts at IETF that are clearing IESG review and will likely soon be published as RFCs:
- [dhc-mac-assign](https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/) - now RFC8947
- [dhc-slap-quadrant](https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/) - now RFC8948
The first one defines a MAC address assignment mechanism. It is similar to IPv6 address assignment, but manages link-layer (MAC) addresses. It defines two new options: IA_LL (a container similar to IA_NA) and LLADDR option (similar to IAADDR).
The second draft extends this mechanism slightly. The whole MAC address space is split into 4 ranges (quadrants) that has different intended usage purpose. This draft introduces a SLAP_QUAD option, which signals between clients and the server, which pool of MAC addresses should be used for allocation.
Yes, the MAC assignment by DHCPv6 (which requires MAC to send and receive data) seems backwards, but there are at least two major use cases for this: assigning MAC addresses to new VMs in large scale datacenters and handling IoT devices, especially disposable ones.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1387Support RFC6603 Prefix Exclude with host reservations not just pd-pools2023-07-05T10:39:18ZDax KelsonSupport RFC6603 Prefix Exclude with host reservations not just pd-poolsIn RFC7084 (Basic Requirements for IPv6 Customer Edge Routers) it says CPE SHOULD IMPLEMENT support for RFC6603.
In [RIPE-690](https://www.ripe.net/publications/docs/ripe-690) Best Current Operational Practice for Operators: IPv6 prefix...In RFC7084 (Basic Requirements for IPv6 Customer Edge Routers) it says CPE SHOULD IMPLEMENT support for RFC6603.
In [RIPE-690](https://www.ripe.net/publications/docs/ripe-690) Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users, it says
Not using a pd-pool, but with a host specific reservation I would like be able to set the RFC6603 prefix to exclude:
Perhaps something like this syntax?
```
"reservations": [
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:DB8::101" ],
"prefixes": [ "2001:DB8:10:200::/56" ],
"prefixes_excluded": [ "2001:DB8:10:200::/64" ]
}
]
```
Per RFC6603 exactly one prefix can be excluded from a delegated prefix. So a validity check should be done on the intersection between the prefixes and prefixes_excluded.
Further elaborating, note that prefixes is an array as multiple prefixes can be listed (although a single prefix is the most common). Thus prefixes_excluded must also be array so that you could technically specify an excluded prefix for each prefix.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1444LeaseX-update and leaseX-del cmds must be propaged to ha members2021-10-19T07:34:04Zmirackle-spbLeaseX-update and leaseX-del cmds must be propaged to ha members---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request ...---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request to primary is not enough. I need to send same request to stand-by member.
**Describe the solution you'd like**
Send update and del cmds to all ha members after completion on one node to maintain sync.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1596Include subnet and pool user context in lease database2023-04-06T12:02:31ZPeter DaviesInclude subnet and pool user context in lease databaseI would like the option to copy the information from user-context on subnet level and from pool level to user-context in lease4/lease6 table after a lease accepted. What I would like to see it is :
Example config:
```
{
"...I would like the option to copy the information from user-context on subnet level and from pool level to user-context in lease4/lease6 table after a lease accepted. What I would like to see it is :
Example config:
```
{
"name": "CMTS-4",
"relay": {
"ip-addresses": [ "0123:4567:891b:cd::1" ]
},
"subnet6": [
{
"subnet": "0123:4567:891b:cd::/64",
"id": 40001,
"pools": [
{ "pool": "0123:4567:891b:cd:4000::a - 0123:4567:891b:cd:7fff:ffff:ffff:ffff" ,"client-class": "pool_one", "user-context": { "pool": "pool_one", "name" : "av", "size" : "10" }} ,
{ "pool": "0123:4567:891b:cd::a - 0123:4567:891b:cd:3fff:ffff:ffff:ffff" ,"client-class": "gamers", "user-context": { "pool": "gamers", "name" : "computers", "size" : "1000" } } ,
{ "pool": "0123:4567:891b:cd:8000::a - 0123:4567:891b:cd:bfff:ffff:ffff:ffff" ,"client-class": "internet"}
],
"pd-pools": [
{
"prefix": "abcd:ef01:9044::",
"client-class": "pool_one",
"prefix-len": 46,
"delegated-len": 56,
"user-context": { "pdpool": "pool_one", "name" : "av" }
},
{
"prefix": "abcd:ef01:9444::",
"client-class": "gamers",
"prefix-len": 46,
"delegated-len": 56,
"user-context": { "pdpool": "gamers", "name" : "lan" }
},
{
"prefix": "abcd:ef01:8120::",
"client-class": "internet",
"prefix-len": 44,
"delegated-len": 56
}
],
"user-context": {
"device": "CMTS-4",
"location": "Partner"
}
}
]
}
```
When a user gets a lease with "client-class: gamers" then on the lease record in the lease table he will have the next json:
```
"user-context": {
shared-network: {}, ## <- came from shared-network level
"subnet" : { "device": "CMTS-4", "location": "Partner"}, ## <- came from subnet level
"pd-pool" : { "pdpool": "gamers", "name" : "lan" }, ## <- came from pd-pool level
"pool" : { "pool": "gamers", "name" : "computers", "size" : "1000" } ## <- came from pool level
}
```
This will help me get info on my subscribers, the lease table doesnt have specific info,
Lets say that I have a few pools under one subnet(like the example),
with that info I can get more accurate statistics on the leased addresses.
How many subscribers I have in gamers.
Another idea is to add info from other hook,
We are using radius hook,
So If was I able to select fields from radius hook, like "username" or some other attribute (that came from radius) and put it inside user-context:
```
"user-context": {
"radius" : { "username" : "xxxxx", }
}
```
[RT #17374 ](https://support.isc.org/Ticket/Display.html?id=17374)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1623Config Backend migration tool2024-03-21T12:22:05ZCathy AlmondConfig Backend migration tool---
name: Control block/configuration migration tool
about: Similar to #1078, this is a request for tools to assist Kea users who decide to change their back-end provisioning - in this instance, their configuration. This should (ideally...---
name: Control block/configuration migration tool
about: Similar to #1078, this is a request for tools to assist Kea users who decide to change their back-end provisioning - in this instance, their configuration. This should (ideally) cater for all scenarios, so not just changing which DB backend is being used, but also migration from not-CB to CB and vice versa
---
I don't think anyone else has opened this yet - but if we do tackle this, it would be worth bearing in mind that configuration/CB backend version control or logging might also turn out to be A Thing - so we need to consider that use case/evolution in the design too.
**Is your feature request related to a problem? **
See [Support ticket #17332](https://support.isc.org/Ticket/Display.html?id=17332) for details of which customer for whom this would be useful.
The likelihood is that they will wish to implement CB backend on the DB backend on which it's available now, but migrate to their preferred DB backend, once there is CB support there too (as well as complete coverage of all configuration options in the CB - at the moment there isn't).
**Update**: As discussed in [Porto](https://pad.isc.org/p/porto2022-stork-roadmap-and-backlog#L31), we'd like to make more generic. While the ultimate solution will likely cover Stork overseeing the migration, some parts of the functionality should be implemented in Kea. In particular, the following was discussed:
- `config-get`/`config-set` like commands that would retrieve/set the full configuration from CB
Once the above is implemented, it will open up plenty of opportunities for Stork. In particular, scenarios such as: "add subnets defined in a config file to CB, delete subents from config file, write updated config file to disk". The same can be repeated for other configuration elements (shared networks, classes, HR, etc).next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1688Auto-detect congestion (busy state thresholds)2022-11-02T15:10:18ZVicky Riskvicky@isc.orgAuto-detect congestion (busy state thresholds)This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service provider...This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service providers. Congestion handling features attempts to improve the DHCP performance when the service becomes busy and is not able to fulfill all incoming requests. In cable operators the following scenarios are usual:
- Massive firmware updates- causing cable modems to restart
- Power outages- affecting cable modems in a region or fiber node.
- A fiber node might serve up to ~2,000 subscribers
- CMTS reboots- due to scheduled maintenance or outages
- RF plant rearrangements- where fiber nodes are combined or splitted causing cable modems within the node to re register
- DDI infrastructure maintenance or outages.
- Business requirements- such as massive actions to customers, i.e. disabling customers with unpaid bills.
Suggestion
**Busy state threshold**
Defines a mechanism to allow Kea to evaluate whether it is operating in a normal or busy state. Kea could use the value of the “packet-queue-size” parameter in the multi-threaded configuration section to evaluate if the system should enter a busy state, for example when the queue capacity is 75% full the system transitions to a busy state and may take actions to improve DHCP performance, such as enabling one or more congestion handling features on the fly, like reducing logging, packet prioritization, and/or batch insertion. When the queue capacity is 25% full or less, the system should return from busy to normal state.
It is likely that customers would want to be able to adjust these high and low watermarks.
It should be possible to explicitly enable/disable this feature.
The various actions that Kea will take to handle the congestion should be determined based on some analysis of what will have the most impact in maintaining normal responsiveness to clients under peak loads.
```
# example suggested configuration section
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 4,
"packet-queue-size": 16
"busy-state-pct" : 75,
"normal-state-pct" : 25
}
```
The “capacity” value in the “dhcp-queue-control” configuration section might also be used to evaluate busy state.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1729Feature request: DHCPv6 - use real MAC address from dhcp6 request (mac-source...2024-01-25T14:53:47ZVojtech PithartFeature request: DHCPv6 - use real MAC address from dhcp6 request (mac-sources=raw)This is a request to implement
```
"mac-sources": [ "raw" ]
```
within DHCPv6 configuration.
As the [documentation](https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6) suggests, in principle DHCPv6 ...This is a request to implement
```
"mac-sources": [ "raw" ]
```
within DHCPv6 configuration.
As the [documentation](https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6) suggests, in principle DHCPv6 server could extract MAC/hardware address information from raw sockets. :pray: Please do so.
Neither Kea nor [ISC DHCP](https://www.isc.org/dhcp/) nor any DHCPv6 server known to me can do this.
**Is your feature request related to a problem? Please describe.**
Yes. Deployment of IPv6 itself. It's no-go without reliable MAC-address-based DHCP in a large scale networks. All the other methods (`ipv6-link-local`, `client-link-addr-option`, etc) aren't reliable.
And unfortunately the whole concept of DUIDs is wrong.
**Describe the solution you'd like**
We simply need the reservation configuration like this
```
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:db8:1::101", "2001:db8:1::102" ]
},
```
to work reliably.
**Describe alternatives you've considered**
- rely on `client-link-addr-option` (option 79) ... many clients provide wrong MAC address here (for example of their *other* interface)
- try manage to acquire DUID of all current and future client hardware pieces ... too complicated (DUID not printed on stickers; many don't even show it on web interface; some randomly change it on firmware upgrade; dual-boot PCs have more than one)
**Funding its development** ...
no
**Participating in development** ...
I am willing to participate in the feature development. I'm a seasoned developer, new to Kea though. With some basic steering, I'd be able to help.
**Contacting you** ...
E-mail in my profile.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1739Implement FORCERENEW support (RFC3203)2022-11-02T17:06:58ZTomek MrugalskiImplement FORCERENEW support (RFC3203)This is roughly a v4 equivalent of RECONFIGURE message in v6. This is not a popular feature (due to lack of support among clients), but it is being requested sporadically.
* [asking about forcerenew on kea-users](https://lists.isc.org/p...This is roughly a v4 equivalent of RECONFIGURE message in v6. This is not a popular feature (due to lack of support among clients), but it is being requested sporadically.
* [asking about forcerenew on kea-users](https://lists.isc.org/pipermail/kea-users/2020-October/002910.html)
* [another one from 2017](http://kea-users.7364.n8.nabble.com/Kea-users-FORCERENEW-feature-td435.html)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2090Support for supersede together with dhcp-server-identifier2023-03-08T19:10:29ZVeroniqueSupport for supersede together with dhcp-server-identifierWe need to configure *dhcp-server-identifier* using the supersede hook but the server does not send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier".
Here is our configuration:
``` ...We need to configure *dhcp-server-identifier* using the supersede hook but the server does not send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier".
Here is our configuration:
```
[...]
"client-classes": [
{
"name": "Windows",
"user-context": {},
},
{
"name": "Desktop",
"user-context": {},
},
[...]
"reservations": [
{
"hw-address": "aa:aa:aa:aa:aa:01",
"ip-address": "111.111.111.111",
"hostname": "client1",
"client-classes": [
"Desktop"
]
},
{
"hw-address": "aa:aa:aa:aa:aa:02",
"ip-address": "111.111.111.222",
"hostname": "client2",
"client-classes": [
"Windows"
]
},
[...]
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_bootp.so",
"parameters": {}
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_flex_option.so",
"parameters": {
"options": [
{
"code": 54,
"supersede": "ifelse(substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' and member('Desktop'), 'xx.xx.xx.xx', ifelse(substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' and member('Windows'), 'yy.yy.yy.yy', 'zz.zz.zz.zz'))"
}
]
}
}
],
```
Could this be supported in a coming release ?
Knowing that we have 100's of 1000's of clients in each class, we cannot test on their mac address in the class definition because it would generate a HUGE configuration file containing HUGE test expressions, so big that the validation takes hours to complete.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2169ddns-rev-domainname2022-11-02T15:10:41ZPeter Daviesddns-rev-domainnameThe ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0....The ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0.168.192.in-addr.arpa. CNAME 20.0-64.0.168.192.in-addr.arpa.
20.0-64.0.168.192.in-addr.arpa. PTR mypc.example.com.
From a question raised on Kea-users@lists.isc.org mailing list.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2271Extend the infinite lifetime feature to full DHCP2022-11-02T15:10:41ZFrancis DupontExtend the infinite lifetime feature to full DHCPFollowup of #897 which uses infinite lifetime only for BOOTP.
Already discussed design points:
- skip Cassandra/CQL support
- add a new lease state to make static/sticky leases independent of the real lifetime
- by default static/sti...Followup of #897 which uses infinite lifetime only for BOOTP.
Already discussed design points:
- skip Cassandra/CQL support
- add a new lease state to make static/sticky leases independent of the real lifetime
- by default static/sticky leases can't be released
- add new config flags to allow infinite lifetimesbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2297'outbound_interface' support for DHCP6 server?2022-11-02T15:10:40ZKevin Fleming'outbound_interface' support for DHCP6 server?**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes.
- Are you sure what you would like to do is not possible using some other mechanisms? It is possible, but inconvenient and ...**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes.
- Are you sure what you would like to do is not possible using some other mechanisms? It is possible, but inconvenient and inconsistent.
- Have you discussed your idea on kea-users or kea-dev mailing lists? No.
**Is your feature request related to a problem? Please describe.**
I have a pair of Kea DHCP servers without direct connection to the clients (they receive all requests via relay). The machines have a 'transport' interface that is used to route traffic to the rest of the network, but is not the address used for services. The service interface is a 'dummy' interface, and that is the interface configured in the server config files. In spite of that, the server believes that requests are received on the 'transport' interface even though it is only bound to the 'mgmt' interface.
In the DHCP4 server, I can set `outbound_interface` to `use-routing` so that replies can be sent out without having a socket open on the 'transport' interface.
**Describe the solution you'd like**
In the DHCP6 server, support the same `outbound_interface` mechanism as the DHCP4 server supports.
**Describe alternatives you've considered**
If I *also* bind the server to the 'transport' interface, the server can send replies. That is my current configuration.
**Additional context**
I am using Kea 2.0.1, but have checked the docs for 2.1.2 and the code in the repo and this feature is not available in the DHCP6 server.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? Possibly.
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Yes to all.backlog