Feature Requst: KEA DHCPv6 "shared subnets"

[Ed V.]

Kea DHCP does have a provision for what are known as "shared networks".

Kea Doc Examples

My use case (which I cannot imagine is unique) is:

ISP that provides a "public" range of IPv6 (/56), which can (and does) change based on when the router/modem reboots.

The need for internal non-public IPv6 to point at NTP, DNS (PiHole) and so on, since the ISP assigned addresses change and there is no graceful or smooth way to re-publish service related addresses that I have found (yet - I'm willing to be wrong).

The configuration looks straightforward in the example document, so maybe a dropdown or somewhere in the "Advanced" options?

[meyergru]

Your IPv6 prefix probably does not only chenge when the router reboots, but also when the connection drops - this is also known as dynamic IPv6 prefixes, which sadly, most ISPs use these days.

If your aim is to use LUA IPv6 for internal services: This is problematic if your DNS names point to both GUA an LUA IPs, because the priority is GUA > IPv4 > LUA, so the latter will never be used.

I would suggest you take a look at https://forum.opnsense.org/index.php?topic=45822.0 for a viable approach.

[Ed V.]

Oh, I'm familiar with your write-up - that's how I got IPv6 working at the start of things.

But the "variability" of the public IP space lead me down the path of using an internal private space (fde4:b3e2:db9e:: in this case) so that my internal PiHole servers, NAS boxes, and so on will have at least one "static" IP.  Yes, they end up with additional IPs based on need, but they always have one outside of the pool that is attached to their network adapter.

Poking around a bit on the Kea DHCP mailing list, my situation is not uncommon.

In fact, it's so common that Kea built a specific method to accommodate the need (shared networks for IPv6).

There are several Rube Goldberg-ish solutions to running my own internal Kea (or ISC, or PiHole) DHCP platform, but I'd rather have it all live in the same place (OpnSense) as the interface tracking to update the dynamic Public IPs makes things much easier.

I can set up and validate a .conf file, but even doing manual configuration fails since something in the OpnSense platform "nukes" the config on restart.

Thus the request that "shared networks" be made available...

[meyergru]

Since you probably want to address the devices from your LAN only and not by IP, but by DNS for practicability reasons: Do you want to have DNS to reflect both the GUA and LUA address? Because, as noted, that will not work.

I think (IDK) that once you use DHCP for assigning addresses, many clients do not accept any SLAAC address any more, so you would need to have both assignment by DHCPv6 and I assume that both get registered into DNS, unless you only create a separate Unbound override only alongside.

[Ed V.]

Correct on DNS hostname registration.

I'm not sure on the SLAAC part, but testing (which left things kinda weird) using PiHole DHCPv6 for private and OpnSense for Public, I was able to pull SLAAC from OpnSense for Public IPs, and also get valid DHCPv6 for my internal subnet.

Since PiHole uses dnsmasq for pretty much everything including DHCP, it is not capable of performing TSIG updates from it's own internal database (flatfile).

I have found that enabling 'kea-dhcp_ddns' works (as long as I re-enable after updates or reboots, since again it reverts any .conf changes "automagickally") and pushes data to my internal DNS master for A, AAAA and PTR records.

My desired outcome is to have Kea DHCPv4 and v6 running on OpnSense, then use DHCP-DDNS to send dynamic assignment updates to the DNS master server.

I'd even accept running Unbound on the OpnSense if the any of the DHCP flavors (Kea, ISC, dnsmasq) were capable of shared networks - as long as it would push DDNS to my internal DNS master.

[Leo999]

In my case, the OPNsense team seems to have made some changes from 25.7.5, resulting in the use of ULA in KEA DHCPv6 Server, the inability to update the lease, and the no ULA IPv6 addresses was assigned for new devices. But it is all normal if in slacc mode.