IPv6 setup issues
-
Hmm.
What size PD are you actually getting? Turn on that debug on the WAN DHCP6 settings (Start DHCP6 client in debug mode) and search the DHCP logs for something like this:
**dhcp6c[40011]: update a prefix 2600:dead:beef:a300::/56 pltime=140733193474432, vltime=34359824768** **dhcp6c[40011]: IA_PD prefix: 2600:dead:beef:a300::/56 pltime=86400 vltime=86400** dhcp6c[40011]: IA_NA address: 2600:dead:beef:b00:c11a:aaeb:decd:ff37 pltime=86400 vltime=86400 dhcp6c[40011]: update an address 2600:dead:beef:b00:c11a:aaeb:decd:ff37 pltime=86400, vltime=140733193474432 dhcp6c[40011]: add an address 2600:dead:beef:b00:c11a:aaeb:decd:ff37/128 on igb1You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.
-
I'm not clear why you are referring to your configuration being static. Are you intending to operate with a static lan and not use dhcpv6? What if your prefix changes? If you don't have dhcpv6 enabled, you should do so, using assisted mode. You can set up static mappings later.
Something is causing the mask on your lan to be 60 instead of 64, so I suggest you reset to defaults and start over. At the very least, delete both the lan and wan interfaces and recreate them. I strongly recommend the former. As Derelict said and others will confirm, this works or we wouldn't be using it. It's possible to set up a fully operational dual stack system from scratch in a few minutes. It's been suggested before and I'll say it again, start with defaults wherever possible unless there is a very good reason to change them. When you get things working, then have your way with it. If you change a bunch of things before it's working, you won't know what is causing the problem.
FYI, I'm using a /56 and the prefix id is 8 bits. Since your prefix id is 4 bits, you seem to be getting a /60, but something caused the mask to get messed up so like I said, go back to first principles.
In your case, start with ipv4 and one lan. When that's working, add ipv6 and dhcpv6 using something like ::1000 to ::2000.
-
[…]
You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.That was causing my trouble!
I just tried to request everything from /48 down to /64, but everytime I only get /56 PDs. Looks like my ISP doesn't delegate anything else…Setting the requested PD to /56 solves the problem with the tracking interfaces.
-
Yeah I think there is a logic problem there in track interface. It uses 64 - what you request and adds that to the prefix you receive to determine the prefix length of the tracked interface.
So you were seeing 64 - 60 = 4 then 56 + 4 = 60. But 64 - 56 = 8 and, of course, 56 + 8 = 64.
Not sure why.
So if what you request doesn't match what you receive, it breaks.
-
Yeah I think there is a logic problem there in track interface. It uses 64 - what you request and adds that to the prefix you receive to determine the prefix length of the tracked interface.
So you were seeing 64 - 60 = 4 then 56 + 4 = 60. But 64 - 56 = 8 and, of course, 56 + 8 = 64.
Not sure why.
So if what you request doesn't match what you receive, it breaks.
Looks like a bug.
This is slightly OT, but I've been wondering what pfsense does in cases where the prefix is numerically smaller (e.g., /48). I can only get /56 so I have no way to experiment with prefix size. I understand the prefix id is only up to 8 bits. Does pfsense pad the difference with 0s? I think the prefix id should be up to whatever length is required to pad the delegated prefix to 64 bits. Only allowing up to 8 bits seems arbitrary. Or am I missing something?
-
[…]
You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.That was causing my trouble!
I just tried to request everything from /48 down to /64, but everytime I only get /56 PDs. Looks like my ISP doesn't delegate anything else…Setting the requested PD to /56 solves the problem with the tracking interfaces.
Were you deleting the DUID each time? Pretty sure you have to do that in most cases or you might/should get the same PD you had before.
-
Were you deleting the DUID each time? Pretty sure you have to do that in most cases or you might/should get the same PD you had before.
I even did a complete reboot plus disabling/enbling the WAN interface each time.
I got different PDs with requesting /48, /52, /56, /60 and /64, but they all were /56 according to the logs.Now my only choice is to request what I would get anyway. It's no problem to live with this issue if you know how it works…
I'd vote for an option to show the leased PD in the Status --> Interfaces tab, just to avoid such things in the future.
-
A reboot does not delete the DUID. It is designed to be persistent. You generally want the same prefix delegation each time.
-
You might try unselecting "do not send release". It could be that the edge router will not give a lease when there is an active lease. That's the case with my ISP edge router, which is nokia/alcatel 7750. It goes even further. If there is an active lease associated with a MAC, it will not give another lease for the same MAC until the active lease expires, even if the DUID is changed. The supposed reason for this according to my ISP is that the dhcp relay only looks at the MAC, but the dhcp server only looks at the DUID. It could also be that your ISP only gives /56 prefix, regardless of what you request.
-
It could also be that your ISP only gives /56 prefix, regardless of what you request.
It obviously does.
As I said I got DIFFERENT PDs each try, but they all were /56. At least now I know what caused the issue.
