IPv6 addresses not deprecated on PPPoE periodic reset

adude42069

Hi,

after a bit of troubleshooting, I was able to reproduce the following:

When I reboot pfSense from the web ui, pfSense sends "something" (probably a Router Advertisement) setting the preffered lifetime of the current (well current right before the reboot) IPv6 prefixes to 0, so that clients know that the route still exists, but it is not preferred anymore and deprecate the route. This can be checked using:

netsh interface ipv6 show addresses

There, you can see that the preffered lifetime gets set to 0 after you hit "reboot" in pfSense, no matter how long the preffered lifetime was before.
Clients use SLAAC, no DHCP6 (except for DNS)

Now, if you use PPPoE and your PPPoE profile is set to have a periodic reset (for ex. daily), you get another IPv6 prefix, depending on the ISP.

In this case, pfSense does not send that "something" (I assume the RA) that deprecates the previous route (the one that was valid before the periodic reset), so it remains preferred on clients for the next 4 hours after the periodic reset.
In parallel, pfSense starts advertising the new prefix after the successful PPPoE reconnect right away, meaning you get two preferred routes in your client. One is not working anymore, because it was only valid before the PPPoE periodic reset, and one route that is valid, because it is advertised.

After the PPPoE periodic reset, the old route is no longer advertised, so the clients deprecate it after the default preffered period, which is 4 hours.

This results in IPv6 not working for 4 hours until the invalid route is naturally deprecated, or you turn wifi off and then on on the client (or yank the LAN cable), or you reboot pfSense so it deprecates the routes.

Hopefully I described this in a understandable manner, but maybe it is not good, let me know.

Is this expected behavior or a finding?

Setup:
pfSense 2.7.2
SLAAC + DNS via RA
Default settings for Router Advertisement lifetimes. (so 1 Day for the valid lifetime, 4 hours for the preferred lifetime, ...)
RA is on Unmanaged, Priority Normal (it is the only router on the network)

Thank you

bmeeks

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.

adude42069

@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?

bmeeks

@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.

adude42069

@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

bmeeks

@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 seems

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.

adude42069

@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.

UweV

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-ipv6

Greetings.

adude42069

@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-ipv6

Thanks 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

UweV

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.

hannesclp

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