Feature Requst: KEA DHCPv6 "shared subnets" (redux)

[Ed V.]

My initial thread seems to have been re-purposed for troubleshooting, so a new thread for new data...

I've been testing Kea-DHCP v3.0.2 on a separate FreeBSD box and from that testing I can state:

* Shared Networks works as expected in assigning both GUA and ULA addresses from the configured pools, for the primary "lan" interface and an aliased "vlan01" interface on the same hardware port
  - IPv6 traffic on both GUA and ULA networks from client systems to the Public Internet works
* Data flows to both the "lan" subnet and to the "vlan01" subnet internally with no crossover
* DDNS in both IPv4 and IPv6 works as expected, updating my internal "master" DNS server with IPv4 and both the GUA and ULA IPv6s
  - A, AAAA in the "lan.internal" and "iot.internal" TLDs and PTR records in the right .ip6.arpa /in-addr.arpa zones
  - Using either the "always" or the "when-not-present" flag
* Shared Networks configuration works with just one network /range /pool defined, so it should be possible to use as a default for all networks
  - I don't have access to a full test rack /setup so I cannot be definitive for a broader scope

So it appears (at least locally) that allowing Shared Subnets and DDNS updates in the Kea-DHCP config would work...

And I would prefer to have it running on the OpnSense system, since that's also where radvd and the other upstream "find my PD and populate addresses" scripts are set to run.

Any hope to put this on the roadmap /PoA&M?

[Patrick M. Hausen]

Open a feature request on github, maybe?

[Ed V.]

https://github.com/opnsense/ports/issues/243

Has been submitted - though it appears that the project has been idle since August?

Is there a new /different Git repo where I should have dropped the request?

[Monviech (Cedrik)]

I transfered it to core.

[Ed V.]

Thank you.

I did receive an email from the core "auto-responder" - apparently my feature request used the wrong template?

There was a help link about policies, but it wasn't much help (or I am running on too little sleep and too much caffeine to fully comprehend what I need to change...).

Any clue-by-fours you can swing my direction?

[Monviech (Cedrik)]

You can close the issue and open a new one following the template.

The more focused your request is on a simple topic, also generally with a configuration example and/or documentation, the more likely it will be a feature request.

If its mixing lots of different concepts/features and its a long wall of text it most likely doesnt get that much attention.

Put yourself in the shoes of somebody triaging 10 issues every day, the ones with a simple direction are more likely to get picked up.