IPv6 addresses not deprecated on PPPoE periodic reset
-
I am a pfSense user, but I follow the posts on the OPNsense forum so that I can keep tabs on any Suricata issues that may be applicable to the pfSense package.
With that said, I see OPNsense users complaining and posting about a number of IPv6, DHCP6, and SLAAC issues that are present in FreeBSD- particularly when PPPoE is involved on the WAN side. There seems to be a lot of weirdness with how FreeBSD itself and system tools like the DHCPv6 client handles prefix changes.
ISP's do not make this any easier as many of them expect weird data exchanges and/or certain priority tags set on this type of traffic. This is my personal anecdotal observation, but this appears to impact OPNsense users a bit more because those users are concentrated in Europe and IPv6 is more widely adopted there than here in the US. IPv6 is catching on in the US, but I think our percentage of ISPs offering IPv6 lags behind those in Europe and other parts of the world. As more IPv6 happens among the ISPs of the world, I expect more of this weirdness to appear before standards settle down and become "real" standards that all ISPs observe.
As IPv6 use spreads in the US, I would not be surprised to see more IPv6 weirdness reported by pfSense users.
-
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
I expect more of this weirdness to appear before standards settle down and become "real" standards that all ISPs observe.
Some of those ISPs stopping to use PPPoE on FTTH would be a great start... but oh well.
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
As IPv6 use spreads in the US, I would not be surprised to see more IPv6 weirdness reported by pfSense users.
Well if this really is a finding, is there a way to open a redmine about this?
-
@adude42069 said in IPv6 addresses not deprecated on PPPoE periodic reset:
Well if this really is a finding, is there a way to open a redmine about this?
You can create Redmine reports for pfSense here: https://redmine.pfsense.org/projects/pfsense.
However, I would not expect miracles
. As one with many years of programming experience myself, I can say that anticipating every possible combination of hardware, firmware, and software that vendors and an ISP might cobble together for IPv6 and then making it all work for every situation in a product like pfSense is a daunting task -- some might even say impossible.The various vendors typically have no incentive to cooperate with each other when they are not forced to do so, and each vendor attempts individually to convince customers (ISPs, for example) that the vendor has the "ultimate solution" for the ISP. ISPs also, understandably, want you to use their provided hardware which will work without issue as it was designed and sold to them as a package. Their support folks are trained for only the ISP's chosen hardware. And then there are those ISPs who's network engineers seem clueless about IPv6 and want to treat it just like IPv4.
I, too, detest something like PPPoE. But ISPs want something to authenticate users so that they can be sure only "Bob" who paid for access is using "Bob's" connection. They would not be happy if "Bob's" connection was such that Paul and Peter could piggy-back off the physical line without paying.
-
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
You can create Redmine reports for pfSense here: https://redmine.pfsense.org/projects/pfsense.
Oh, I thought a forum post was mandatory. Will look into this, thanks!
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
I, too, detest something like PPPoE. But ISPs want something to authenticate users so that they can be sure only "Bob" who paid for access is using "Bob's" connection. They would not be happy if "Bob's" connection was such that Paul and Peter could piggy-back off the physical line without paying.
Well, yes, but why is DHCP used in cable networks (as in DOCSIS) then :)
So PPPoE is not the only way it seems -
@adude42069 said in IPv6 addresses not deprecated on PPPoE periodic reset:
Well, yes, but why is DHCP used in cable networks (as in DOCSIS) then :)
So PPPoE is not the only way it seemsYes, either DHCP or PPPoE is typically used by ISPs. I don't know why some prefer one over the other. My FTTH provider uses simple DHCP. Many years ago when I had DSL, that provider used PPPoA and then later PPPoE.
-
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
Yes, either DHCP or PPPoE is typically used by ISPs. I don't know why some prefer one over the other. My FTTH provider uses simple DHCP. Many years ago when I had DSL, that provider used PPPoA and then later PPPoE.
That's the thing. I would be fine with DHCP, but PPPoE over FTTH is kinda stupid imo, espicially if it "helps" create these IPv6 problems in FreeBSD (refering to this):
@bmeeks said in IPv6 addresses not deprecated on PPPoE periodic reset:
With that said, I see OPNsense users complaining and posting about a number of IPv6, DHCP6, and SLAAC issues that are present in FreeBSD- particularly when PPPoE is involved on the WAN side.
-
I have exactly the same issue (ISP Deutsche Telekom, Fiber FTTH) and found a workaround:
-
Use "Managed" in RA:
 -
Enable DHCPv6 an client VLAN(s)
The clients are getting one global IPv6 "dynamic". This IP get's updated when the IPv6 prefix changes on the LAN Interface(s).
I had a second issue: ISP prefix change not detected/configured by pfSense.
Workaround: https://github.com/geschke/ccw-ipv6Greetings.
-
-
@UweV said in IPv6 addresses not deprecated on PPPoE periodic reset:
I have exactly the same issue (ISP Deutsche Telekom, Fiber FTTH)
Off topic, but keep their peering practices in mind...
and found a workaround:
-
Use "Managed" in RA:
 -
Enable DHCPv6 an client VLAN(s)
The clients are getting one global IPv6 "dynamic". This IP get's updated when the IPv6 prefix changes on the LAN Interface(s).
I had a second issue: ISP prefix change not detected/configured by pfSense.
Workaround: https://github.com/geschke/ccw-ipv6Thanks for the workaround, but DHCP6 is not universally supported, Android has been known to only support SLAAC. Maybe this has changed and/or my sources are wrong.
Also, I planned to use SLAAC Only on my setup for now, which is why I also try to get Netgate to look into this issue.
As I am not a software engineer, I'm sadly unable to contribute myself to the source code to fix it myself. The Redmine is here: https://redmine.pfsense.org/issues/15746
-
-
For sure Netgate needs to fix it.
Problem: Invalid auto-configured (Stateless Address Auto-Configuration (SLAAC)) Pv6 addresses are not marked deprecated after an IPv6 prefix change on LAN Interfaces.In our network it's a valid workaround for now until it will be fixed because we are not using Android based mobile phones. Windows, Linux, MacOS, iPadOS and iOS devices are working fine.
-
Unfortunately this issue still persists in pfsense 2.8.0. At least most European isps still hand out dynamic ipv6 prefixes to their customers which leads to the described issues with slaac.
Refer to: https://redmine.pfsense.org/issues/15746
