pfSense » pfSense Plus

IPv4 WAN setup ?

Ethernet to [Nokia] Fibre ONT [Verizon US]

Multi WAN or not ?

Single WAN.

What is your IPv6 setup ?

Configuration Type: DHCP6
Prefix: /56
Send IPv6 prefix hint: enabled
Do not wait for RA: Enabled.
Do not allow PD/Address release: Enabled

I'm unable to reproduce this. I have two WANs with IPv6 and when I unplug the cable on either one, then reconnect it 30 seconds later, they immediately show both IPv4 and IPv6 as available and online.

Correction: I was able to reproduce this with one of my two ISPs after I changed some settings.

Disabling the option "Do not wait for RA" caused the mentioned issue. However, enabling this option on the WAN caused IPv6 to work normally.

Likely your ISP doesn't send RAs until a DHCP6 request is received (like mine). This is likely not a bug, but expected behavior with some ISPs.

Kris Phillips wrote in #note-3:

Correction: I was able to reproduce this with one of my two ISPs after I changed some settings.

Disabling the option "Do not wait for RA" caused the mentioned issue. However, enabling this option on the WAN caused IPv6 to work normally.

Likely your ISP doesn't send RAs until a DHCP6 request is received (like mine). This is likely not a bug, but expected behavior with some ISPs.

I believe RAs are sent prior to a DHCP6 request being sent. My ISP is Verizon (USA). I simply do not see any once the ip6 link is broken (pulling cable from WAN port). Rebooting immediately brings back the ip6 link. This is not normal / expected behaviour.

[22.05-RELEASE][@pfSense] sudo /sbin/rtsol -DF igc0
rtsol: checking if igc0 is ready...
rtsol: cap_llflags_get() failed, anyway I'll try
rtsol: set timer for igc0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on igc0, state = 1
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 4s
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 4s
rtsol: timer expiration on igc0, state = 2
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 4s
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 1s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: timer expiration on igc0, state = 2
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on igc0, state = 2
rtsol: No answer after sending 3 RSs
rtsol: stop timer for igc0
rtsol: there is no timer


This redmine can be closed as Not a Bug

Kris Phillips wrote in #note-5:

This redmine can be closed as Not a Bug

No. It can't. It is reproducable on every Verizon line I have tried this on. Did you reproduce this on a Verizon FTTP ONT connection? I suspect not.

Disabling the option "Do not wait for RA" caused the mentioned issue.

..and yet, I have that option checked and the issue still occurs.

This is likely not a bug, but expected behavior with some ISPs.

This is a bug. If this was 'expected behaviour', how does an ip6 lease only ever get assigned when the router is rebooted. This is ridiculous. What logs can I supply to help get this fixed?

It may be helpful to have DHCP6 debugging enabled under System / Advanced / Networking and getting the full logs both while it's working and not working. Additionally if possible, testing the latest 2.7 snapshot to see if the issue is already resolved there.