IPv6 PD Address not being assigned

Splitting from 25.12.5 release post.

After upgrading from 25.12.4 to 25.12.5 yesterday morning (2026-07-01), I was no longer being assigned an IPv6 PD address from my ISP.
I tried re-upgrading today (2026-07-02) but this did not resolve the issue.

After rolling my VM back to 25.12.4 (using backups), I still cannot receive an IPv6 PD address from my ISP.

My configuration is:

config interface 'wanv6'
        option proto 'dhcpv6'
        option device 'eth0.7'
        option reqaddress 'try'
        option reqprefix 'auto'
        option norelease '1'
        option multipath 'off'

config interface 'wan'
        option proto 'dhcp'
        option device 'eth0.7'
        option hostname '*'
        option peerdns '0'
        list dns '9.9.9.9'
        option multipath 'off'

and I am seeing the following lines in the system log:

daemon.notice: netifd: wan (3298): udhcpc: started, v1.37.0
daemon.notice: netifd: wanv6 (3343): Failed to send RS (Address not available)
daemon.notice: netifd: wanv6 (3343): eth0.7: error connecting LLA socket
daemon.notice: netifd: wan (3298): udhcpc: broadcasting discover
daemon.err:    odhcpd[2600]: Failed to send to fe80::aaaa:bbbb:cccc:dddd%lan@eth0.100 (Address not available)
daemon.notice: netifd: wan (3298): udhcpc: broadcasting select for 100.x.x.x, server 100.x.x.x
daemon.notice: netifd: wan (3298): udhcpc: lease of 100.x.x.x obtained from 100.x.x.x, lease time 300
daemon.notice: netifd: Interface 'wan' is now up
daemon.notice: netifd: wanv6 (3343): Failed to send SOLICIT message to ff02::1:2 (Address not available)
daemon.warn:   odhcpd[2600]: No default route present, setting ra_lifetime to 0!

I have checked that eth0.7 does have a fe80 address assigned, and tried rebooting the ONT for an extended time.

@el_charlie suggested that I regenerate the DUID, but it turns out I did not have one configured.
I found here that there is an inbuilt DUID generator script - I have run this and now have a DUID, but am still getting the same issue.

I am using a Proxmox Virtual Machine with a VirtIO network adaptor.
This configuration worked previously on 25.12.4 until I upgraded.

Thanks in advance for the help.

I had the same experience including the LLA socket error message. Also running inside ProxMox VM. Rolling back restored functionality

It appears my situation is unique.
I've rolled back to backups from the 29th and I'm still not getting an IPv6 address from the ISP, and am getting the same message in the logs.

Perhaps there's an issue on the ISP side? Or maybe I need to rotate my MAC address?

How about contacting customer service?

I’m currently rebuilding the VM, if that doesn’t resolve it, that was my next step.

[4 Jul 2026, 13:00:52 UTC] daemon.notice: netifd: Interface 'wan6' is enabled
[4 Jul 2026, 13:00:52 UTC] daemon.notice: netifd: Interface 'wan6' has link connectivity
[4 Jul 2026, 13:00:52 UTC] daemon.notice: netifd: Interface 'wan6' is setting up now
[4 Jul 2026, 13:00:52 UTC] daemon.notice: netifd: wan6 (8504): Failed to send RS (Address not available)
[4 Jul 2026, 13:00:52 UTC] daemon.notice: netifd: wan6 (8504): wan: error connecting LLA socket
[4 Jul 2026, 13:00:53 UTC] daemon.notice: netifd: wan6 (8504): wan: error connecting LLA socket
[4 Jul 2026, 13:00:53 UTC] daemon.notice: netifd: wan6 (8504): Failed to send SOLICIT message to ff02::1:2 (Address not available)

Same issue after spending an hour rebuilding!!
Will be ringing the ISP...

Worth mentioning that the new build had a DUID by default.
Only thing I had to change was the ULA-Prefix to match the old VM.

Current config:

config interface 'wan'
        option proto 'dhcp'
        option device 'wan'
        option hostname '*'
        option multipath 'off'

config interface 'wan6'
        option proto 'dhcpv6'
        option device '@wan'
        option reqaddress 'try'
        option reqprefix 'auto'
        option norelease '1'
        option multipath 'off'

copy it and then delete it , reboot and check again

Completed as instructed, the box is now blank.
Please let me know if I should put the DUID back.

Just to be sure, can you check:

ip -6 addr show dev wan scope link

The error comes from:

root@OpenWrt:~# ip -6 addr show dev wan scope link
13: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 fe80::be24:11aa:bbcc:eab/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Thanks!

Same for me, I do not get a IPv6-PD. Rolling back to 25.12.4 solved the issue.

This is strange because wan does have an LLA. What happens with:
ping ff02::2%wan
You should see two replies, one from your own LLA and one from the ISP's router.

See no problems getting prefix (/56) with my old config (I have dhcp_default_duid specified):

config interface 'wan'
	option proto 'pppoe'
	option device 'wan'
	option username USERNAME
	option password PASSWORD
	option ipv6 '1'

config interface 'wan6'
	option proto 'dhcpv6'
	option device '@wan'
	option reqaddress 'try'
	option reqprefix 'auto'
	option norelease '1'

https://ip.bieringer.net - shows expected results both on Linux and Android.

I get similar reply:

root@router:~# ip -6 addr show dev wan scope link
3: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 fe80::d6da:21ff:fe77:b57c/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Just one reply from the localhost:

root@OpenWrt:~# ping ff02::2%wan
PING ff02::2%wan (ff02::2%13): 56 data bytes
64 bytes from fe80::be24:11aa:bbcc:eab: seq=0 ttl=64 time=0.155 ms
64 bytes from fe80::be24:11aa:bbcc:eab: seq=1 ttl=64 time=0.149 ms
64 bytes from fe80::be24:11aa:bbcc:eab: seq=2 ttl=64 time=0.214 ms
64 bytes from fe80::be24:11aa:bbcc:eab: seq=3 ttl=64 time=0.158 ms
64 bytes from fe80::be24:11aa:bbcc:eab: seq=4 ttl=64 time=0.156 ms

Thanks!

Try on WAN6

option reqprefix '0:1'

I was having the same issue (pulling ipv6 IP address but not an ipv6-pd), and setting the reqprefix to '0:1' restored it for me, pulling a /56 (and in fact, the original prefix I had about 4 hours earlier on 25.12.4). Can you explain a bit about what this did and how it solved it?

I have the Ubiquiti Edgerouter X with the latest OpenWrt 25.12.5 installed. I have made zero changes to the default configuration. Plugging the router into my fiber ONT, ipv4 comes up fine but ipv6 does not. My previous router (a Netgear raxe300 not running OpenWrt, if it matters) served up ipv6 plugged into the same ONT.

Looking at the system log I see the following:

[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: Network device 'eth0' link is up
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: Interface 'wan' has link connectivity
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: Interface 'wan' is setting up now
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: Interface 'wan6' has link connectivity
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: Interface 'wan6' is setting up now
[Jun 29, 2026 at 12:59:38 PM UTC] kern.info: [   36.239241] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.warn: odhcpd[1603]: No default route present, setting ra_lifetime to 0!
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.warn: odhcpd[1603]: rfc9096: br-lan: piofile updated
[Jun 29, 2026 at 12:59:38 PM UTC] daemon.notice: netifd: wan (2735): udhcpc: started, v1.37.0
[Jun 29, 2026 at 12:59:39 PM UTC] daemon.notice: netifd: wan (2735): udhcpc: broadcasting discover
[Jun 29, 2026 at 12:59:39 PM UTC] daemon.notice: netifd: wan6 (2747): Failed to send RS (Address not available)
[Jun 29, 2026 at 12:59:39 PM UTC] daemon.notice: netifd: wan6 (2747): eth0: error connecting LLA socket
[Jun 29, 2026 at 12:59:39 PM UTC] daemon.notice: netifd: wan6 (2747): Failed to send SOLICIT message to ff02::1:2 (Address not available)

It appears that somehow there is an issue getting a link local ipv6 address, and because of that the dhcpv6 solicit message cannot be sent properly? I do not know why or how that would occur, or how to fix it.

The weird thing is that when I look at the addresses, there does appear to be a link local assigned???

root@OpenWrt:~# ip -6 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: dsa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 state UP qlen 1000
    inet6 fe80::7683:c2ff:fe4e:aba4/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::7683:c2ff:fe4e:aba4/64 scope link 
       valid_lft forever preferred_lft forever
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fda9:4ef0:5f23::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::7683:c2ff:fe4e:aba5/64 scope link 
       valid_lft forever preferred_lft forever

It looks like others had a good ipv6 system and then migrated from 25.12.4 and have this same issue, but when I install 25.12.4 it still doesn’t work for me. I get the exact same log messages and issue. I also tried 25.12.2, 24.10.6, and 23.5.6 with no luck.

After many days of online searches I cannot figure out how to get ipv6 working at all and I’m extremely frustrated. What am I doing wrong? Any help is greatly appreciated.

In 25.12.5, the update of ocdhcp pulled more refactor and most notably, they updated how the IAID (a kind of identifier) is computed when your router requests the prefix.

Before 25.12 serie, it was always "1" and with 25.12.4, it was 1, 2, 3 (if multiple). On 25.12.5, it was updated so that the IAID is computed from the network interface name instead (so no more 1).

Your ISP is likely to have assigned your prefix to the old IAID (1) and with the new IAID based on the IF name, your ISP couldn't give you the same prefix or maybe doesn't allow you to have more than 1 prefix assigned. If you could "release" the assignation, maybe you could return to the new default configuration based on the IF name but I'm not sure about this.

"0:1" means that your request any prefix (0 = auto) with IAID = 1.

The original PR of this change: https://github.com/openwrt/openwrt/pull/23758