No IPv6 after upgrade to 23.01
-
@maverickws said in No IPv6 after upgrade to 23.01:
DHCP6 should take care of this without the need of having to find out the GW for the next hop and adding static gateways.
IPv6 does not get its default next-hop from DHCP[6] like IPv4 does. It relies on router advertisements. To reiterate, there is nothing built into DHCP6 to propagate a next-hop gateway. It must be in an acceptable router advertisement.
If the router advertisements are non-standard then the problem is at the ISP.
I, personally, find it pretty appalling that an ISP would deploy IPv6 in such a manner, breaking customer routers that adhere to the standards and locking customers into ISP gear that works around the non-standard behavior.
-
@derelict The ISP you're talking about is actually the #1 ISP around here, with the biggest fibre optics infrastructure, most clients, both in the B2C as B2B.
They work with all kinds of OEMs: Cisco, Huawei, Ericsson/Alcatel and others.
The way they implement their solution worked before the update. It still works for all customers who do not use this solution, which will likely be over 95% of the customers. So yeah you can find it appalling, I'd say it isn't them (the ISP) but the OEM's yet many customers around the world will face these issues, but never enough to force them.
If I plug a Cisco where the pfSense is now, will IPv6 work? [YES, it does].
Now, what do you think it will happen? An infinitely small percentage of the customers will make the OEM's and the ISP's to change, or people will just move to something that works?
I believe you know the answer. It's not even a matter of personal opinion, it's a very simple business decision.
-
@maverickws This ipv6 problem started a few updates ago and before that everything worked for years now its just problems .
-
@maverickws
If you only define a fixed gateway and don't use DHCPv6 for prefix delegation too, the ISP's GW probably will answer pings from pfSense, but as it has no associaton between the delegated internal prefix and the routing address of the pfSense appliance it refuses to route anything else coming from the public address of your router. This is the whole point of keeping the DHCPV6 configuration (even if it doesn't work correctly): IA-NA to IA-PD binding. The routing infrastructure of your ISP must know which is YOUR local GUA that has the delegated prefix behind itself for the packets to get there...
This gets even worse if the particular ISP does not keep the delegated prefix fixed (as in our case) changing it randomly when our router issues a DHCP REFRESH message. To resolve this latter issue we use ULA + NPt for our internal network, with the added benefit of easy IPv6 gateway failover (we use several ISP's on the same router) without mandatory internal renumbering of hosts as the prefix changes. Such a configuration mimicks NAT of IPv4 but only changing the first 64 bits of your local host to the public delegated prefix on the pfSense router. -
T Tzvia referenced this topic on
-
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp I really appreciate the report, thank you.
You guys address the issue description way better than me. -
@jimp We have another twist to the already acknowledged regression: our ISP refuses to delegate a prefix shorter than a /64, but grants as many(?) /64 prefix delegations as we request as long as the IA-PD identifier is unique. This gives roughly the same result as requesting a shorter PD and splitting it up on the track interface, but regrettably there is no way to inform unique IAID´s from the IA-PD request to individual track interfaces in order to create an association between the granted PD and the local interfaces onto which these PD´s should be assigned. The implied logic in pfSense is that we only get one PD of a certain length and associate it to the routing interface via its name, not the IAID. It might be useful to consider this use case too, as I have read somewhere that even ATT has this use policy.
The following should be possible and not restricted/blocked by the pfSense configuration (0 and 1 are the IAID's):
interface ix2 {
send ia-na 0;
send ia-pd 0;
send ia-pd 1;
script "/var/etc/dhcp6c_opt13_script.sh";
};
id-assoc na 0 { };
id-assoc pd 0 {
prefix-interface ix2.666 {
sla-id 0;
sla-len 0;
};
};
id-assoc pd 1 {
prefix-interface ix2.667 {
sla-id 0;
sla-len 0;
};
}; -
That is completely unrelated to the problem here and wouldn't have changed in 23.01. It belongs in a separate thread.
-
@jimp sorry, my mistake. I´ve started a new thread already.
-
@jimp said in No IPv6 after upgrade to 23.01:
I was thinking as a solution, what about having an option that when selected executes the script even if the ISP doesn't have a correct config, and when unselected has the supposed to be correct behaviour? Would that work?
-
@maverickws I believe this would be equivalent to always run the script, as it uses the same script for both flags already.
-
@mhillmann yeah but I mean if we assume the current behaviour is the correct behaviour and by default should be so, it would make sense, imo, the option to override the default behaviour and then run the script regardless. (so when that option is selected, always run the script)
-
@maverickws I agree, this may be the best option.
-
@maverickws said in No IPv6 after upgrade to 23.01:
https://forum.netgate.com/post/1088842
Well, it took me 22 days to realize that ipv6 is no longer working since upgrading.
It seems that a problem has been identified. Has a workaround been proposed? All of my google home devices (which use SLAAC) are no longer working reliably. If I turn off IPV6 on that VLAN, it works.
Thanks,
Devan
-
Take with a grain of salt... I was suffering from this issue and enabled the DHCPv6 server on my LAN interface and that seemed to fix it.
I thought I had the DHCPv6 server enabled on my LAN interface before upgrading to 23.01, but I found it not enabled when troubleshooting this issue.
Just thought I would share in case this helps anyone.
-
@jpwoodbu
Thanks.I checked on DSL reports and a few NJ users are reporting IPv6 outages. I just removed all traces of IPv6 from pfsense and called it a day. I'll try again in a year. IPv6 really didn't offer any noticeable benefits but introduced much more instability, mostly from Verizon.
-
@ddbnj Its not just NJ FiOS users. I'm in NoVA and IPv6 isn't working for me either.
-
I will say it's not your Isp because i can use the ips router and ipv6 works .Pfsense version 22 works fine just can't install packages because the package manager is out of date ,So is there going to going to be fix any time this year ?
The no help is not good for anyone
The ipv6 problem is not funny !! -
@nighthawk1967 I disagree with that. I have a Mikrotik on another FiOS network that should support IPv6. I'm pretty sure that's doesn't have ipv6 working either...
-
@compuguy said in No IPv6 after upgrade to 23.01:
@ddbnj Its not just NJ FiOS users. I'm in NoVA and IPv6 isn't working for me either.
Yep... after some overnight maintenance early Tuesday morning, I've lost my IPv6 connectivity in Northern VA. Clearly Verizon has changed something, but it sounds like pfSense may need to change something also... looking forward to whenever the patch is available for the fix!!
