Hello,
We have been working on a number of IPv6 improvements and I'd like to ask willing users to help test them with us!
1. dhcp6c improvements
dhcp6c has received a lot of refactoring and cleanups and can now set the lifetime of prefixes (formerly set to infinite by the code even though that's not what is being e). The code changed to offer the valid life time as preferred/valid life times during configuration, which makes them expire automatically. We found a few bugs in the FreeBSD kernel that were fixed in 25.7.11 so testing the new dhcp6c code is possible now.
Again: make sure you are on 25.7.11 :)
# opnsense-code dhcp6c
# cd /usr/dhcp6c
# ./configure
# make upgrade
dhcp6c will not restart automatically. The best way to use the new version is to reboot.
If you want to revert to the version that belongs to 25.7.11 you can do:
# opnsense-revert dhcp6c
(and reboot)
The first two pages here are the relevant changes: https://github.com/opnsense/dhcp6c/commits/master/
2. We're testing multi-dhcp6c again after deciding against it many years ago. There are some downsides to using one daemon for all WANs a patch exists to split the daemons up! This also makes it possible to get better control of individual PD associations requested from the ISP.
This requires the 25.7.11 DEVELOPMENT version to apply cleanly. I recommend using a snapshot before switching since a number of things will be migrated and it's not easy to switch back as some settings will be in the wrong place. A config backup and restore is also an idea if you make the direct transition back using the firmware GUI.
# opnsense-patch https://github.com/opnsense/core/commit/5b8c2a862e
A reboot would be the best course of action here too.
More context on the work we did here is in https://github.com/opnsense/core/issues/7647
If you have any questions please let me know. All feedback is welcome, especially from multi-WAN IPv6 users! :)
Cheers,
Franco
Hey Franco,
Multi-WAN IPv6 user here. :) WAN1 requests address + prefix, WAN2 only requests an address.
I performed 1. and don't see any immediate issues after the reboot.
Can we see the (remaining) lifetime somewhere? It doesn't seem to be reflected in the prefix lifetime advertised by radvd on tracking LAN interfaces.
If there aren't any issues in the next two days or so, I'll go ahead and test 2., too.
Cheers
Maurice
Nice, you can see configured lifetimes in ifconfig and with -L switch you can see how much is left (actually found and fixed this switch for 25.7.11).
Note that dhcp6c sets vltime = pltime for prefixes. It's all a bit odd that NA was setting vltime and pltime correctly but PD set infinite for both. To crawl towards a better solution we avoid deprecation of prefixes for now but from my testing so far dhcp6c renews far more frequently than pltime so in a next step we can probably set the real pltime too.
The key thing here is that we want to see the ifconfig -L times so we can actually distinguish which prefix was the last one assigned and use that as the primary one for e.g. radvd. Some ISPs renew with a new prefix but having the first one stick around and no way to distinguish because they both do not expire was suboptimal and at some point the old one disappears but there is no renew triggering a radvd reload so then the prefix stops working for clients.
I was a bit surprised to find all these related bugs for just trying to do what the standard intended. ;)
Thanks a lot,
Franco
Quote from: franco on January 16, 2026, 10:25:16 PMyou can see configured lifetimes in ifconfig and with -L switch you can see how much is left
On the WAN interface, ifconfig shows the lifetime of the interface address (IA_NA). But where do I see the lifetime of the prefix (IA_PD)? On the tracking LAN interface, ifconfig does not show a lifetime.
Quote from: franco on January 16, 2026, 10:25:16 PMNA was setting vltime and pltime correctly
I can confirm this. IA_NA pltime is lower than vltime:
inet6 2001:db8:6490:5d00::2 prefixlen 128 pltime 270 vltime 300Quote from: franco on January 16, 2026, 10:25:16 PMfrom my testing so far dhcp6c renews far more frequently than pltime
From my testing, dhcp6c renews after half of vltime. So as long as pltime > vltime/2, no problem.
Quote from: franco on January 16, 2026, 10:25:16 PMThe key thing here is that we want to see the ifconfig -L times so we can actually distinguish which prefix was the last one assigned and use that as the primary one for e.g. radvd. Some ISPs renew with a new prefix but having the first one stick around and no way to distinguish because they both do not expire was suboptimal and at some point the old one disappears but there is no renew triggering a radvd reload so then the prefix stops working for clients.
Excellent! This has plagued me a lot and the workarounds I had to implement are nightmare fuel.
Quote from: franco on January 16, 2026, 10:25:16 PMI was a bit surprised to find all these related bugs for just trying to do what the standard intended.
Unfortunately, I'm not surprised at all.
Cheers
Maurice
Oh, I probably have to perform 2. (switch to development branch and apply patch) to see the IA_PD lifetime?
> On the WAN interface, ifconfig shows the lifetime of the interface address (IA_NA). But where do I see the lifetime of the prefix (IA_PD)? On the tracking LAN interface, ifconfig does not show a lifetime.
No it sounds to me that the dhcp6c service wasn't restarted. If you skipped the reboot you need to "killall dhcp6c" and reconfigure otherwise SIGHUP is used and the old binary remains active.
> Excellent! This has plagued me a lot and the workarounds I had to implement are nightmare fuel.
> Oh, I probably have to perform 2. (switch to development branch and apply patch) to see the IA_PD lifetime?
No, this issue should be fixed on 25.7.11 with the latest dhcp6c code from the repository active. If not it's a bit of core glue that is not entirely correct but that will be easy to fix with an ifconfig -L dump at the time of the renewal where it tells radvd.conf to still use the old prefix.
Cheers,
Franco
Quote from: franco on January 17, 2026, 08:09:56 AMNo it sounds to me that the dhcp6c service wasn't restarted.
I did reboot.
For the WAN interface, ifconfig only shows the addresses configured on the interface itself (obviously), not the delegated prefix. So no lifetime information for IA_PD there:
~ # ifconfig -L vtnet0
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN_GPON (wan)
options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
ether 00:15:5d:2a:fe:16
inet6 fe80::215:5dff:fe2a:fe16%vtnet0 prefixlen 64 scopeid 0x1
inet6 2001:db8:5812:800::2 prefixlen 128 pltime 209 vltime 239
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>For the tracking LAN interface, ifconfig doesn't show lifetimes:
~ # ifconfig -L vtnet2
vtnet2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN_IPv6 (lan)
options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
ether 00:15:5d:2a:fe:02
inet6 fe80::215:5dff:fe2a:fe02%vtnet2 prefixlen 64 scopeid 0x3
inet6 fd03:2148:cea2:1::1 prefixlen 64
inet6 2001:db8:5812:801::1 prefixlen 64
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>What does work is that the GUA gets removed from the tracking LAN interface when the valid lifetime of the prefix delegation expires. It just seems you can't see that lifetime anywhere.
Cheers
Maurice
Then the code in dhcp6c repo wasn't pulled correctly? Or are you using the "no release" option, too? With that option it is rather hard to do anything sane and I've kept it to use infinite lifetimes otherwise it breaks the promise of the option...
https://github.com/opnsense/dhcp6c/commit/52dfc21489
1.) is still evolving on the master branch. Had a wrong assumption that RENEW would already trigger a full reload but that wasn't the case.
The two commits seem to be needed as well and I'm not sure they apply cleanly to 25.7.11. Still testing a bit.
https://github.com/opnsense/core/commit/c31d9430e
https://github.com/opnsense/core/commit/fafe519de
Cheers,
Franco
Quote from: franco on January 18, 2026, 01:52:51 PMThen the code in dhcp6c repo wasn't pulled correctly?
Pulled, compiled and installed correctly.
Quote from: franco on January 18, 2026, 01:52:51 PMOr are you using the "no release" option, too?
Nope.
But I now made the next step and switched to opnsense-devel (26.1.b_143). ifconfig now shows pltime and vltime for the GUA on the tracking LAN interface. So it seems devel is indeed required for this to work.
Did not apply the multi-dhcp6c patch yet, maybe tomorrow.
Great new radvd features by the way, like PREF64! 👍
Cheers
Maurice
Hey,
I've tried to test 1) but sadly dhcp6c fails to establish ipv6 connection despite fetching prefix correctly in the logs. It fails with following message: failed to parse options, malformed DHCP option: type 64, len 21. Revert fixes it of course. Might be something specific to my ISP?
Option 64 is the AFTR FQDN for DS-Lite. OPNsense doesn't support configuring DS-Lite automatically using this option, but dhcp6c should just ignore it - unless it's indeed malformed. I'd perform a packet capture to confirm.
Cheers
Maurice
@pataps: yay, great, thanks! Among other things AFTR is now natively supported by the daemon (and advertised to the dhcp6c_script as "new_aftr_name") but I made a small mistake with the initial implementation:
https://github.com/opnsense/dhcp6c/commit/60c87d02c
Can you try again?
Cheers,
Franco
@franco Nice! That's just the foundation though, correct? The dhcp6c_script doesn't do anything with this information yet, or does it?
Correct, I also added IFNAME and NAINFO as well as finished the implementation of "new_raw_option_nnnnn" with a user which shows what else is there in the server response in raw hex format.
On my install I see this one for example:
new_raw_option_86=XXXXXXXXXXXXXXXXde396ffffed8ee9a
Once we ship the new version of dhcp6c we can start using these things. IFNAME is pretty useful because we can stop building separate script files and use a static separate script, see https://github.com/opnsense/core/commit/e8f35e9dc
Cheers,
Franco
Quote from: franco on January 19, 2026, 04:01:36 AM@pataps: yay, great, thanks! Among other things AFTR is now natively supported by the daemon (and advertised to the dhcp6c_script as "new_aftr_name") but I made a small mistake with the initial implementation:
https://github.com/opnsense/dhcp6c/commit/60c87d02c
Can you try again?
Cheers,
Franco
Yes, I can confirm it works as expected now. I can see "AFTR domain name" in the dhcp6c logs. Connectivity resorted after restart. Thanks!
Great. Can you share the log line here or via PM? I don't have a setup obviously. Just for double-checking.
Thanks,
Franco
@franco If you need a DHCPv6 server which offers this option for testing, you can simply use OPNsense's ISC DHCPv6 server with a custom config:
echo "option dhcp6.aftr-name test.aftr.example.com;" > /usr/local/etc/dhcpd6.opnsense.d/aftr.conf
I've done this before and it works just fine.
Cheers
Maurice
Ok, I hadn't thought of that. That will make testing via VM client easy. :)
I mostly test against the Fritzbox these days. Still pondering how to build an effective test suite around dhcp6c in the codebase itself to emulate such things, perhaps with packet captures.
Thanks,
Franco
As upstream routers for testing, I mostly use OPNsense VMs (radvd, ISC DHCPv6 etc.) as well as MikroTik RouterOS VMs (they have free VM images for testing and offer some features which OPNsense doesn't have, like a PPPoE server).
Cheers
Maurice
I have done part 1 here, everything seems ok so far. I'll keep an eye on things. I got a bit confused by whether I should see lifetimes, but I'm using "prevent release" for reasons I can no longer remember, so if I've understood correctly, I shouldn't expect to see lifetimes in that case.
I haven't done part 2, as I'm not running the development version.
Nice, thanks. Yes that is expected.
Part 2 is mostly for multi-wan but can wait. Still weighing if part 1 is good enough for 26.1 or if it should move to 26.1.1 just to have a revert target with 26.1.
Cheers,
Franco
I have also completed the first part, and so far everything seems to be fine.
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=880008<VLAN_MTU,LINKSTATE,HWSTATS>
ether bc:24:11:e4:42:08
inet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255
inet6 fe80::be24:11ff:fee4:4208%vtnet0 prefixlen 64 scopeid 0x1
inet6 2601:2c1:c600:5671:be24:11ff:fee4:4208 prefixlen 64 pltime 3700 vltime 3700
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
vtnet1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=880008<VLAN_MTU,LINKSTATE,HWSTATS>
ether bc:24:11:e3:3c:83
inet 76.30.75.80 netmask 0xfffffc00 broadcast 255.255.255.255
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::be24:11ff:fee3:3c83%vtnet1 prefixlen 64 scopeid 0x2
inet6 2001:558:6022:c6:b103:3def:f639:2dfb prefixlen 128 pltime 5505 vltime 5505
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
vlan0.10: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: iot (opt1)
options=80000<LINKSTATE>
ether bc:24:11:e4:42:08
inet 172.16.127.1 netmask 0xffffff00 broadcast 172.16.127.255
inet6 fe80::be24:11ff:fee4:4208%vlan0.10 prefixlen 64 scopeid 0x7
inet6 2601:2c1:c600:5672:be24:11ff:fee4:4208 prefixlen 64 pltime 3700 vltime 3700
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: vtnet0
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
I don't have multi-WAN but I just tried the first part. I also see pltime = vltime and both are counting down.
I'm not using Prevent Release, but my /60 delegation doesn't change often so I don't think I should see anything interesting except these timers will eventually reset?
root@firewall:~ # ifconfig -L
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 64:xx:xx:xx:xx:9e
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::66xx:xxxx:xxxx:xx9e%igc0 prefixlen 64 scopeid 0x1
inet6 2601:xx:xxxx:3161::1 prefixlen 64 pltime 4588 vltime 4588
groups: IG_LOCAL IG_OUT_WAN IG_DNS IG_NTP IG_DROP_LOW
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 02:xx:xx:xx:xx:b2
hwaddr 64:xx:xx:xx:xx:9f
inet 69.xxx.xx.99 netmask 0xfffffc00 broadcast 255.255.255.255
inet6 fe80::xx:xxxx:xxxx:xxb2%igc1 prefixlen 64 scopeid 0x2
inet6 2601:xx:xxxx:3160:xxxx:xxxx:xxxx:xxxx prefixlen 64 pltime 4588 vltime 4588
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
...
> I'm not using Prevent Release, but my /60 delegation doesn't change often so I don't think I should see anything interesting except these timers will eventually reset?
Yes, correct.
The biggest issue we've had here was a kernel bug that would not update the link route lifetimes when they were renewed by the deamon. Ifconfig was fine but the route disappeared. This was fixed in 25.7.11 with https://github.com/opnsense/src/commit/46f807c0c
So you should see your prefix renew and your clients still able to connect after each renewal.
Thank you for testing. The last few reports have improved the confidence to tag and ship the new dhcp6c code in 26.1 so we will probably do that.
Cheers,
Franco
@franco, as we were typing the timers already refreshed. It seemed like a very short interval. The router uptime since the reboot is ~45 min.
No issues seen on the client(s) yet. Will keep an eye on it.
root@firewall:~ # ifconfig -L
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 64:xx:xx:xx:xx:9e
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::66xx:xxxx:xxxx:xx9e%igc0 prefixlen 64 scopeid 0x1
inet6 2601:xx:xxxx:3161::1 prefixlen 64 pltime 6448 vltime 6448
groups: IG_LOCAL IG_OUT_WAN IG_DNS IG_NTP IG_DROP_LOW
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 02:xx:xx:xx:xx:b2
hwaddr 64:xx:xx:xx:xx:9f
inet 69.xxx.xx.99 netmask 0xfffffc00 broadcast 255.255.255.255
inet6 fe80::xx:xxxx:xxxx:xxb2%igc1 prefixlen 64 scopeid 0x2
inet6 2601:xx:xxxx:3160:xxxx:xxxx:xxxx:xxxx prefixlen 64 pltime 6448 vltime 6448
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
...
Yup, renew intervals can be short. In my setup it's 30 minutes.
Cheers,
Franco
It's stuck on 7200 now for all interfaces and no longer counting down. This all in short succession (sorry for the spam).
Expected?
igc1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 02:xx:xx:xx:xx:b2
hwaddr 64:xx:xx:xx:xx:9f
inet 69.xxx.xx.99 netmask 0xfffffc00 broadcast 255.255.255.255
inet6 fe80::xx:xxxx:xxxx:xxb2%igc1 prefixlen 64 scopeid 0x2
inet6 2601:xx:xxxx:3160:xxxx:xxxx:xxxx:xxxx prefixlen 64 pltime 7200 vltime 7200
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
-L is important to view the remaining lifetime :)
Ah! Didn't notice I had dropped it. All looks fine.
So https://github.com/opnsense/ports/commit/a1996a8fe27 is coming to 26.1-RC2 soon. That more or less concludes 1.)
For 2.) I'll publish new patch instructions after 26.1 is out. I think they don't apply cleanly in all cases anymore since there were more moving parts and some things from the patch have been extracted and moved to the master branch because they were safe as is.
Thanks,
Franco
I'm closing the CFT and open a new one for 26.1. Thanks for everyone's time and input! <3
Cheers,
Franco