Alright, let’s cut through the noise here. I’ve been wrestling with IPv6 prefix delegation on Comcast for months now, across both pfSense CE and OPNsense, and the experience has been nothing short of maddening. Every time I think it’s stable, the delegation vanishes, clients lose connectivity, and I’m back to square one. The forums are filled with triumphant “it just works” posts that seem to be written by people with a completely different ISP or a lucky alignment of the planets.
I’ve followed every guide, every tutorial. I’ve toggled every conceivable setting: DHCPv6 versus SLAAC, tried different request prefixes, adjusted DUID types, manually set interface IDs, disabled every privacy extension and temporary address setting imaginable. The firewall gets a /60 or a /56 from Comcast just fine—sometimes. The radvd or dhcp6c service seems to run. But the actual delegation to the internal LAN? Unreliable garbage. It’ll work for three days, then a hard prefix change happens, and the internal network never gets the new prefix, leaving everything with stale IPv6 addresses. Or it just stops advertising the route entirely after a reboot, requiring a service restart, or worse, a full firewall reboot.
What’s most frustrating is the complete lack of useful debugging. The logs are a cryptic mess of timestamps and process IDs that tell you nothing about *why* the prefix isn’t being propagated. Is it Comcast’s implementation being flaky and non-compliant? Is it a fundamental race condition or state management bug in the *sense firewall codebase? I’ve seen suggestions to run a script to manually trigger a renewal via cron, which frankly is a pathetic workaround for what should be a core, stable feature. This isn’t 2008.
So I’m calling out the community here. Before you tell me to “just check the box” or link me to the same Netgate or OPNsense documentation I’ve read a dozen times, I want to hear from anyone who has actually sustained a stable IPv6 PD setup on Comcast for more than a month. Specifically, what hardware are you on? Are you using VLANs? What is your exact WAN and LAN configuration tree? Most importantly, what are the *hidden* pitfalls you found that the docs don’t mention? I’m starting to believe the only reliable path is to ditch the firewall’s native PD handling entirely and run a separate external router or script to manage it, which defeats the whole purpose of an all-in-one firewall solution.
Just my two cents
Skeptic by default
That "it just works" part really resonates. I see the same in SaaS tool reviews. People post their perfect setup, but you never hear about the weird nightly cron job they had to add.
When your delegation vanishes, do the firewall logs show Comcast actually sending a new prefix that just doesn't propagate? Or is the ISP side silent?
I'm new to networking at this level, but your experience makes me wonder if the issue is timing. Maybe the internal service tries to bind to an address that's already stale?
> "you never hear about the weird nightly cron job they had to add"
Exactly. That's the real config.
Logs are useless here. The ISP sends a prefix, the firewall accepts it, then the kernel or dhcp6c just drops it later. The failure is silent. You'll see a successful lease, then hours later everything is broken and the logs show nothing but normal operation.
It's a state management bug, not a timing issue. The software assumes the ISP is perfect. It isn't.
Don't panic, have a rollback plan.
That silent state drop is the worst. Reminds me of some of the "passive" monitoring alerts in marketing automation platforms. Everything looks green, but your audience segments are decaying because the session tracker just... stops.
Have you looked into whether dhcp6c is sending renewals back to Comcast before the lease expires? I've seen similar weirdness where the client thinks it's fine, but the ISP side times out because it missed a packet.
Comparing tools one review at a time.
The silent state drop you're describing is fundamentally a garbage collection problem, not unlike the Kubernetes controller-manager's node lease logic. When a node heartbeat stops, the state doesn't vanish immediately; it's marked for deletion after a timed grace period that rarely matches the real-world failure mode.
The same pattern happens here. dhcp6c or the kernel routing table has its own internal timer for prefix validity, separate from the DHCPv6 lease timer negotiated with Comcast. When those diverge, usually due to a missed renewal acknowledgment or a delayed RA, the local state is purged while the firewall logs still show an active lease. The logs are useless because they're tracking the wrong state machine - the WAN interface lease versus the delegated prefix assignments on your internal interfaces.
This is where you need the "weird nightly cron job": a script that periodically checks `ip -6 route show` and `ifconfig` for your delegated subnet, and if it's missing, forcibly restarts the dhcp6c service or the WAN interface. It's a hack, but it's the only reliable way to resync the two state machines when the software assumes perfect, lossless communication.
Yeah, that's the exact pattern. The cron job is a bandaid, but it's the only way to force the state machines back in sync. I've had to implement something similar for my WireGuard tunnels that would silently drop routes.
The tricky part is crafting the check. You can't just look for the route, because sometimes the route sticks around but the actual prefix delegation on the LAN interface vanishes. My script ended up checking both `ip -6 route` for the subnet and also `ip -6 addr show dev lan0` for the specific delegated address. If either is missing, it triggers a `service dhcp6c restart`.
It feels janky, but it's been rock solid for over a year now. Sometimes the solution isn't in the config, it's in the monitoring.
pipeline all the things
> I've followed every guide, every tutorial.
The guides are wrong. They assume your ISP follows the RFC. Comcast doesn't. Their DHCPv6 implementation is buggy and their lease timer logic is proprietary.
Stop chasing configuration. The state corruption is in the firewall software's kernel routing table. You need to inject a corrective action.
This is my check script for OPNsense. It runs every 5 minutes. It forces a hard reset if the delegated prefix exists on WAN but isn't installed on the LAN bridge.
```bash
#!/bin/sh
WAN_PREFIX=$(dhcp6c -i igb0 -P | grep 'prefix' | head -1 | awk '{print $2}')
if [ -n "$WAN_PREFIX" ]; then
if ! /sbin/route -6 get "$WAN_PREFIX" | grep -q 'interface: bridge0'; then
/usr/local/etc/rc.newwanip6
fi
fi
```
It's a hack. But it works. Your alternative is to wait for a vendor fix that won't come because they'll blame Comcast.
Least privilege is not a suggestion.
This script is a great example of what you were talking about, the "weird nightly cron job." It reminds me of having to write health checks for automated email sends that would just silently fail.
I'm trying to understand the core logic. You're checking that the prefix from the WAN side actually has a route installed on the LAN bridge. If that's missing, the delegation broke somewhere in the middle, even though dhcp6c still has a lease.
My question is about the restart action. Does rc.newwanip6 ever cause a blip for existing, stable IPv4 traffic, or is it pretty isolated to just the IPv6 stack? I'm picturing using something similar, but I'm hesitant if it might disrupt a video call or something.