IPv6 downstream router (FritzBox) requires OPNsense to behave like ISP

[GerhardHeus]

Topology

Code Select Expand

ISP (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)

Code Select Expand

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)

Code Select Expand

{
  "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 Observation
FritzBox 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.

[franco]

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

[Monviech (Cedrik)]

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.

[GerhardHeus]

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.

[Monviech (Cedrik)]

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.

[GerhardHeus]

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.

[Monviech (Cedrik)]

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)