TopologyISP (DHCPv6-PD /48)
│
▼
OPNsense (pppoe0, dhcp6c)
│
Legacy Track Interface
(assign /64s via Prefix IDs)
│
┌──────┼────────┐
│ │ │
LAN VLAN1 VLAN2
ID 0 ID 4 ID 6
│
▼
FritzBox
├─ non-guest (/64)
└─ guest (/64)
(Fritz runs its own RA/DHCPv6/DNSv6)Core requirement:OPNsense must behave like an
IPv6 ISP, so the downstream FritzBox can operate
fully autonomously.
Working Setup (Stable)- Legacy Track Interface on all internal interfaces
- ISC DHCPv6 enabled
- Router Advertisements enabled (basic / unmanaged)
- FritzBox internal DHCPv6 + DNSv6 enabled
Behavior:
- OPNsense slices the ISP /48 using Prefix IDs
- FritzBox successfully receives sub-delegated prefixes
- Guest and non-guest IPv6 work reliably
- Prefix renewals and reboots are handled cleanly
ISC DHCPv6 (Working, Anonymized)option dhcp6.domain-search "internal";
option dhcp6.rapid-commit;
default-lease-time 7200;
max-lease-time 86400;
authoritative;
subnet6 2001:db8:abcd::/64 {
range6 2001:db8:abcd::1000 2001:db8:abcd::2000;
option dhcp6.name-servers 2001:db8:abcd::1;
# Prefix delegation to downstream router (FritzBox)
prefix6 2001:db8:abcd:8000:: 2001:db8:abcd:ff00::/60;
}This configuration:
- Delegates prefixes cleanly
- Automatically installs kernel routes
- Aligns PD lifetimes with RA behavior
- Allows FritzBox to act as a real downstream ISP customer
Attempted Setup (Problematic)- Identity Association (IA) addressing
- KEA DHCPv6
- Parameterized Router Advertisements
Despite many variations, this does
not allow FritzBox to function autonomously.
Observed problems:
- Delegated prefixes not reliably routed
- Guest IPv6 disappears
- IPv6 breaks when KEA is stopped/restarted
- Removing PD pools breaks downstream IPv6 even though OPNsense still has global IPv6
- FritzBox internal DHCPv6/DNSv6 cannot be enabled reliably
KEA DHCPv6 (Attempted, Anonymized){
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "lan0" ]
},
"subnet6": [
{
"subnet": "2001:db8:abcd::/48",
"pd-pools": [
{
"prefix": "2001:db8:abcd:ff00::",
"prefix-len": 60,
"delegated-len": 64
}
],
"reservations": [
{
"duid": "00:03:00:01:xx:xx:xx:xx:xx:xx",
"ip-addresses": [ "2001:db8:abcd::2000" ]
}
]
}
]
}
}Even with variations:
- PD routing is fragile or missing
- RA behavior must be manually aligned
- Downstream router does not behave as with ISC DHCPv6
Key ObservationFritzBox internal DHCPv6/DNSv6
only works when upstream behaves exactly like an ISP.
- ✔ Track Interface + ISC DHCPv6 → Fritz autonomous
- ✖ IA + KEA + RA → Fritz breaks or degrades
This suggests that either:
- KEA lacks functionality needed for downstream routers, or
- OPNsense's current KEA + IA + RA integration does not fully model ISP-like behavior
Questions / Migration Path- Is it currently possible to fully replace
Track Interface + ISC DHCPv6 + basic RA
with
IA + KEA + RA
while still supporting autonomous downstream routers? - Are PD pools mandatory in KEA for downstream routers?
- Is the lack of automatic route installation for delegated prefixes a known limitation?
- Is ISC DHCPv6 expected to remain for this use case, or is there a recommended migration path?
Summary- My setup is stable today
- I am not looking for workarounds
- I want to understand whether a clean KEA/IA migration path exists for "OPNsense as ISP" deployments
Any guidance from developers or users running downstream routers would be appreciated.
For a static IPv6 prefix in Kea yes. For a dynamic one no. We'll be discussing some things related to Kea in the upcoming roadmap discussion for 26.7.
Cheers,
Franco
My opinionated view on this, being an ISP requires a static prefix.
So the OPNsense can already behave like an ISP, when the surrounding infrastructure provides ISP requirements.
The ISPs decided that the edge (their customers) should have dynamic IPv6 prefix. In the above schema, the OPNsense is right at the edge, terminating the ISP.
Dynamic prefixes are not designed to be used at more hops than the exact edge between the "real" ISP and the "real" customer.
The ISPs know this, and offer higher paid tiers for customers who want to shift the edge further away from themselves, via static prefixes.
Thanks for the insight! To give some context, my home setup is designed primarily to segregate IoT devices and other traffic that I don't want in my home network into separate VLANs, so that all non‑trusted devices are kept outside of the main home network. This allows me to apply more granular firewalling, intrusion detection, logging and overall network management, which dictated the current topology.
Beyond this, there is an ambition to get IPv6 running as cleanly and reliably as possible. One might argue "if IPv4 works, why bother with IPv6?" — but for my use case, I want a consistent and future-proof setup, including autonomous operation of downstream routers like FritzBox.
My observation is that:
Using Track Interface + ISC DHCPv6 + basic RA, the FritzBox operates autonomously and reliably, with PD sub-delegation working for both guest and non-guest networks.
Attempts to replicate the same behavior with IA + KEA + parameterized RA have so far been fragile; small misconfigurations can break downstream IPv6 connectivity.
I'm sharing this to highlight that there are real-world home/own built domotica scenarios where OPNsense essentially behaves like an ISP, even with dynamic PD. It would be useful if future KEA/IA guidance explicitly addressed such use cases, so that advanced setups can migrate cleanly when ISC DHCPv6 is eventually deprecated.
I understand the usecase, I'm just saying it could also be solved with money. (I do not mean that in a mean way, just stating how it is).
ISPs are the culprit here, they want you to pay more for a static prefix that allows all of this cleanly with no hoops.
Thanks for the explanation — there is one important detail in my setup that may change the assessment.
I do not receive a changing IPv6 prefix. My ISP (Freedom Internet NL) has assigned me a fixed (anonymized) 2001:db8:abcd ::/48 for years, which is also visible in their customer configuration, and I additionally have a static IPv4 address.
From an architectural perspective, this places my OPNsense much closer to an "ISP edge" than a typical residential dynamic-PD setup.
Given this, I would expect IA + KEA + RA with downstream PD (e.g. to a FritzBox) to work in principle. However, in practice only legacy Track Interface + ISC DHCPv6 behaves correctly.
This leads me to suspect interoperability gaps between KEA, RA, and downstream routers rather than a fundamental IPv6 design issue.
If you have a static prefix you can use KEA with prefix delegation:
https://docs.opnsense.org/manual/kea.html#prefix-delegation-ia-pd
It also sets static routes now automatically via a helper script, targeting the link local address of a device that request IA_PD.
If the routing does not work as expected for some reason, let us know.
E.g. show the routing table after KEA leased IA_PD to the downstream devices.
# netstat -rn6
(Please note you might have to reboot once after disabling isc and enabling kea, as the routing table might have old entries otherwise that route traffic wrong)
Quote from: GerhardHeus on Today at 02:36:18 PMMy ISP (Freedom Internet NL)
- You have got one of, if not THE BEST ISP in The Netherlands.
- You have got one of, if not THE BEST Router Software in use.
- You have probably also got nice Managed Switches & Accesspoints in use.
Why the heck do you bother using a crappy Fritz!Box on your network ?!
Why not just a nice seperate VLAN for all the stuff you need seperated ?!
In the 20 years or so that I had xDSL from KPN that whole weird AVM company was THE BRAND TO AVOID for me and I always bought DrayTek Routers instead and never had any issue! :)
Please keep it focused for now, I want to find out if there is a bug or issue first in this thread (Since I partially implemented and tested the KEA prefix delegation in OPNsense)
Thanks for all the discussion so far — it helped clarify a lot. I wanted to summarize my situation and share some observations for others who might have similar setups:
Current Setup
My ISP provides a fixed /48 IPv6 prefix, anonymized: ( 2001:db8:abcd ::/48) that has been assigned to me for years.
On the OPNsense WAN (PPPoE), this prefix is delivered via DHCPv6-PD, and OPNsense relies on it to configure the global IPv6 address, default route, and delegated prefixes.
Internally, I run Track Interface + ISC DHCPv6 + RA on LAN and VLANs. Downstream devices (including a FritzBox managing its own guest and non-guest subnets) receive IPv6 addresses properly, and IPv6 routing works.
Why KEA / IA_PD did not work
KEA requires full static ownership of the prefix to assign delegated prefixes and manage routes.
Even though my /48 is "fixed" at the ISP level, it is still delivered dynamically via DHCPv6-PD. IA_PD with KEA cannot safely manage this prefix without risk of breaking downstream connectivity.
This is why earlier attempts to migrate to KEA with Identity Association and RA parameterization failed.
IPv4 vs IPv6 distinction
Fixed IPv4 works fine; OPNsense can assign it manually.
Fixed IPv6 is technically possible to test, but OPNsense may not route properly without DHCPv6-PD. The WAN address, default route, and RA to downstream networks may fail if the ISP expects dynamic PD delivery.
Future Considerations
For now, I will keep the current working setup (Track Interface + ISC DHCPv6 + RA).
Once ISC DHCPv6 is retired in OPNsense, I will need to explore:
Whether Static IPv6 can be safely used with a fixed /48 from my ISP.
Whether KEA could be configured to support this type of "fixed but delivered via DHCPv6-PD" scenario.
I think you are mixing up concepts.
The DHCPv6 client already handles IPv6 prefixes you receive from the provider.
KEA is a DHCPv6 server, it just needs the correct configuration and it will work, and set the correct routes into the routing table.
I tested and verified that myself with a PPPoE setup in the same constellation as you above.
I assume a configuration error for now.
In other words if you reliably (because the contract says so) get a static prefix from your ISP, then configure your WAN with DHCPv6 but forget all "track" and similar crap on your internal interfaces and use static configuration throughout. Then Kea can - also by static configuration - perform PD to downstream clients.
Patrick is right.
And to make it even more precise, the IPv6 setup could be configured statically entirely.
Static IPv6 on LAN/vlan etc.
Static route of a subnet (prefix) to the fritzbox.
Static IPv6 configuration on the Fritzbox WAN port.
Router Advertisements is all thats needed to advertise the default route.
No DHCPv6 server needed anywhere, only the WAN DHCPv6 Client configuration.
Essentially this is completely normal manual subnetting almost the same as IPv4.
Quote from: Monviech (Cedrik) on Today at 11:52:12 AMDynamic prefixes are not designed to be used at more hops than the exact edge between the "real" ISP and the "real" customer.
That's the only point where I'd disagree. DHCPv6-PD is absolutely designed to work over multiple hierarchy levels. And it's further gaining importance with recent developments like RFC 9762 (P flag in RAs) and Android now starting to prefer DHCPv6-PD over SLAAC.
Cheers
Maurice
Its cool that the clients want to do all that stuff but where is the server software implementation (better would be a combined dhcpv6 client + server that internalises the full running state) that can do this out of the box?
KEA doesnt even install routes for PD without a watcher python script crawling its lease database.
IPv6 is being made consistently more convoluted by stacking more and more concepts on top of each other.
My argument is more grounded inside the deployment reality of this, not the RFC suggestions.
Though this right now is an emotional argument. Im happy in my own RA only world due to personal projects that allow that :D
Thanks everyone for the detailed explanations and for pointing me to the KEA static PD documentation.
After working through the feedback and testing different approaches, my conclusion is that there are two valid and clean solutions for my use case with a downstream FritzBox:
1. Stay entirely within the ISP-provided global prefix and configure everything statically
In this model, OPNsense acts as a classic border router. The /48 is subnetted manually into /64s for LAN, VLANs, and a routed /64 toward the FritzBox. Router Advertisements are sufficient; no internal DHCPv6 server is required. This is very robust and avoids all PD lifecycle issues.
2. Use a locally generated ULA prefix for the FritzBox side and KEA DHCPv6
Here, the FritzBox receives IA_NA and IA_PD from KEA exactly as described in the documentation, but using ULAs instead of the ISP prefix. This cleanly avoids any dependency on the ISP PD lifecycle and keeps everything manageable through the OPNsense GUI.
For now, I'll keep my working legacy setup, but this gives me a clear migration path once ISC DHCPv6 is retired. Thanks again for the insights — especially around prefix ownership and lifecycle, which turned out to be the key point.
@Monviech
Well, the deployment reality on the router / firewall side is that OpenWrt, AVM, MikroTik and many others support downstream PD with a dynamic upstream. OPNsense is rather the exception. (Yes, ISC kind of supports it, but only with tricks, and it's EOL.)
The P flag in RAs is rather new, but trivial to implement on the server side. OpenWrt (odhcpd) supports it in 25.12 and there is an open pull request for radvd (https://github.com/radvd-project/radvd/pull/276).
ndp-proxy-go is a great piece of software! But I don't see it as a replacement for prefix delegation, just like a traditional ARP proxy is not a replacement for proper IPv4 routing.
@GerhardHeus
No one mentioned ULAs. If you want to use DHCPv6-PD, you can simply configure KEA with a static GUA prefix. If your ISP provides you with fixed prefix 2001:db8:abcd::/48, you can e. g. use 2001:db8:abcd:ff00::/56 for KEA's PD pool. This allows it to delegate e. g. 16x /60.