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

[GerhardHeus]

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.

[Maurice]

@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.

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.

[OPNenthu]

The sublinked article on the Android Developers Blog and RFC 9663 are interesting.

Does it apply for home internet subscribers where the delegated prefix is often /60 or /56?  I get a /60 from my ISP so I only have 16 /64s to play with.  In what world would I want to delegate an entire /64 to a single Android device and its connected gadgets?

(I'm sure I'm either misinterpreting or missing some context...)

[Monviech (Cedrik)]

A real life usecase would be a Chromebook running Android Apps on it as VMs. Thats already out there in the wild.

So I would say as soon as a client becomes more of a hypervisor.

Guess like:

ISP -> "Real" Router -> "Semi" Router (Client) -> Actual consumer (VM)

[Maurice]

@OPNenthu
No ISP should delegate less than a /56, even for the cheapest consumer plan. If you use one /57 for numbering the LANs and the other /57 for PD, 128 devices can request their very own /64 (or 64x /63, 32x /62, ...). Should be fine for a home network.

A single /60 is just nasty and a reason to complain. I once was with an ISP who only delegated a /59, but they eventually switched to /56, adopting the de-facto industry standard.

[Patrick M. Hausen]

RIPE recommends to give every residential line, even for consumers, a /48. 🙄

A /56 is fine for most, though.

I don't get it. It's not like IPv6 addresses were scarce ...

[OPNenthu]

A single /60 is just nasty and a reason to complain.

I hope a critical mass of such complaints comes forward, but unless more subscribers decide to ditch their WiFi routers and learn a bit about networking... I don't see it.

Maybe Google will force the issue :-)

I don't get it. It's not like IPv6 addresses were scarce ...

I came across one argument for this which claims that it mostly comes down to two things:

- Operational complexity for cable providers.  There's apparently some cost with mapping and tracking migratory prefixes on CMTS networks.

- Product differentiation so that business subscribers don't start complaining about why they pay more for a /48.

I can't verify these claims.  The second one is understandable.  The first one, if true, implies something about cable networks at scale.  It's interesting to note that Verizon (one of the large fiber ISPs here) do provide a /56 on their residential FiOS plans.