Loss of IPv6 upon link up event on any track6 because of dhcp6c kill
-
Hello,
I have a configuration with
WAN: dhcp6 with Prefix Delegation (/60 though it does not matter as prefix delegation is enabled)
LAN1: track6, prefix 0
LAN2: track6, prefix 1
...The various machines on LAN1, LAN2, etc can end up being brought up/down through the day.
Upon a link down for any of the LANs (let's say LAN1 for this example), IPv6 connectivity stays on, that is all other machines of any of the other interfaces are capable to connect fine with ipv6 (and v4), that is LAN2 is completely unaffected (as one would expect).However, as soon as the LAN1 is brought up, ipv6 connectivity is lost on all interfaces, the LAN*, but also WAN.
Debugging shows that
rc.linkupends up callinginterface_configurefor LAN1 insideinterfaces.inc, which in turn will callinterface_track6_configurewhich will finally kill the dhcp6c_process:case "dhcp6": if ($linkupevent == true) { /* * NOTE: Usually come here from rc.linkup calling so just call directly instead of generating event * Instead of disrupting all other v4 configuration just restart DHCPv6 client for now * * XXX: Probably DHCPv6 client should handle this automagically itself? */ $pidv6 = find_dhcp6c_process(); if ($pidv6) { posix_kill($pidv6, SIGHUP); } } break;Clearly, if the dhcp6 client running on WAN is killed and restarted, it will release its dhcp v6 PD, and invalidate all ipv6 on all dependent track6 interfaces. I tried a small VM and reproduced it easily with a minimum config. Upon commenting out the posix_kill, the problem is gone (but clearly, this is not correct since I suspect that the client might not work properly any more, which I suspect was the reason the kill was added in the first place, though I could not check)
From the code (the 'XXX' and 'for now' in the comment), it seems clear that this was never meant to be the ideal solution, and looks like a bug.
Unfortunately, this is 100% reproducible, and happens multiple times a day in our installation as machines directly connected is power cycled (or for that matter every time there is an update on a switch, etc), disrupting our site heavily (and it would be difficult to reduce the number of up events).
Any recommendation to fix ? Or pointers to what the solution might be ? (if small enough with enough details about the edge case scenarios to test for, I might be able to propose a patch). Should I file a bug (or maybe there is one I have missed) ?
Thanks
-
@FrenchToastDev said in Loss of IPv6 upon link up event on any track6 because of dhcp6c kill:
Clearly, if the dhcp6 client running on WAN is killed and restarted, it will release its dhcp v6 PD, and invalidate all ipv6 on all dependent track6 interfaces. I tried a small VM and reproduced it easily with a minimum config. Upon commenting out the posix_kill, the problem is gone (but clearly, this is not correct since I suspect that the client might not work properly any more, which I suspect was the reason the kill was added in the first place, though I could not check)
It can release the prefix(es) as it gets the 'stop' signal, but you can control that behavior.
You check the usage of :
after all, if the IPv6 (prefixes) get released then it is very possible (?) that a new prefix will change everything.
But, totally IMHO (no scientific reason from my side, just my "common sense") : do everything, or more, so that all pfSense interfaces don't go 'down'. If needed, uses witches and UPSes on all sides ^^ Don't use a pfSense NIC as a port that has a device on it that pulls down the interface.
pfSense will all interfaces up all the time is a happy pfSense. And thus : a happy admin.
As pfSense is a router (firewall), when interface go down (and up again), a lot is triggered at that moment. Much of the event is a purely random, and you don't want to be the one that finds a race condition with some setup at that moment, as these are hard to debug.All this said, I agree, if your pfSense LAN goes down, related process that use that interface will stop. Like a DHCP6 server. As soon as the LAN gets up (again), DHCP6 server is started on that interface, and it might need a prefix (using tracking). Maybe that the reason why the WAN side process dhcp6c needs to be restarted at that moment.
Again : not perfect, but do like me : keep them up, and be happy.
Keep in mind : it's 2026. Most ISP have their IPv4 implementation done by now.
IPv6 : things are getting into place bit by bit, and many ISPs make a mess out of it. -
Thank you so much for answering,
It can release the prefix(es) as it gets the 'stop' signal, but you can control that behavior.
You check the usage of :This seems to work indeed ! I had to reboot the firewall for it to take effect, but indeed, clients now seem unaffected, that is, the dhcp6 client still gets killed, but there is no loss of ipv6 on lan segments for which the interfaces were not down. This is what I was looking for.
I am though unsure if there are other side effects to this setting I am not forecasting.Regarding your comments around using switches, I totally agree :), but I was trying to see if one could get pfsense to behave in a logical fashion here. As you are mentioning, ipv6 is still sadly rough with ISPs and in many network appliances, and I was here hoping that there could be a software patch (from pfsense folks or myself) to resolve the problem with ipv6 (since it is never a problem for ipv4 as mentioned) ... trying to help ipv6 along :)
I am still interested in comments from the pfsense devs if there might be other ways they think this might be resolved, and there might be software patches that they (or I, per above) might propose, but from my site point of view, the problem seems to be resolved (crossing fingers :)).
Again, my thanks !
-
Still, as soon as your router's interfaces aren't being brought down anymore, everything is stable, right ?
Knowing that a a router isn't a switch : every NIC state change will influence heavily the processes in the router that offer services like DNS, firewall, DHCP, etc. So my (I admit) golden rule is : do everything you can that these interfaces don't change states. Solution : every LAN should have it's own switch, or, if you have just one device attached to it like a NAS : keep it always on, like pfSense.
Nice side effect : no more IPv6 issues.After all : if a IPv6 LAN goes down, the consequence is not like what happened when it was a IPv4 only interface. IPv4 needs a local RF1918 network, and has no need to interact with an upstream router (== your ISP). An IPv6 LAN has to 'free' or re obtain a new prefix, and to do this, dhcp6c has to be triggered.
No patch could resolve this situation.There where I use pfSense, France, IPv6 starts to become the main stream, and IPv4 is in what I would call pre-legacy state. When I get a new device for my network, it has to pass the criteria : can it do DHCPv6 ?
-
@Gertjan
Sorry for not responding earlier. Little time after I received your email, I noticed that in production, we had again some connectivity issues with ipv6 despite the change. Interestingly, as I had previously mentioned, the tests I had done with a VM had made a difference, but production seems to behave differently, or maybe the way I test did not cover all things: I was doing a ping test, which clearly is probably the type of things that are least disrupted by a net up/down, so I will probably do a more realistic test next with some TCP connections, etc.Anyway, I meant to investigate it before responding (I did not want to respond to no data), but did not get to it yet, so I thought I reply now before somebody thinks it works and scratches their head as to why it does not work for them :( Hopefully some time next week, I will be able to carve a few hours to diagnose, or maybe I will wait until we qualify the latest pfSense version that is just being released as we speak).
In regards to your comments, I will agree that in practice, indeed bringing down/up some interfaces might have an effect on many things on the firewall, but I am saying that in a perfect world, what happens on a single interface should not impact other interfaces as the services ought to be fully partitioned, not requiring full state reset for all interfaces if a single interface is misbehaving. But, I agree with your pragmatic sentiment.
In terms of your comments for the adoption of ipv6, I am not sure I am following you. Are you simply saying that ipv6 adoption is still rough and lots of devices do not have a full end to end ipv6 stack ? I mean, yes, this is sadly the state of affairs, though it is simply much better as time has passed : in our networks, the majority of them are now dual stack, and work well (outside this particular problem mentioned in this thread, and the stinginess of isp that decided that a /60 was enough), either SLAAC for client devices, or 'static ips' (where the prefix is given by dhcpv6, and the rest is hard coded).
Funny enough, you mention France as potentially lagging, but it seems to be leading in adoption according to the map you mention, and much better than the USA where I am residing :)Thanks again for the conversation, and encouragements.
-
I reread your comment:
@Gertjan said in Loss of IPv6 upon link up event on any track6 because of dhcp6c kill:
After all : if a IPv6 LAN goes down, the consequence is not like what happened when it was a IPv4 only interface. IPv4 needs a local RF1918 network, and has no need to interact with an upstream router (== your ISP). An IPv6 LAN has to 'free' or re obtain a new prefix, and to do this, dhcp6c has to be triggered.
No patch could resolve this situation.and I am not sure I understand.
Here, we have
- WAN listening to the ISP using dhcp6c and getting a /60, say 1:2:3:4440::/60
- LAN1: configured with prefix 0 of that /60. so 1:2:3:4440::/64
- LAN2: configured with prefix 1 of that /60, so 1:2:3:4441::/64
When LAN1 goes back up, clearly the router needs to restart router advertisements on LAN1 for prefix 0, but it does not need to change router advertisements for prefix 1 on LAN2, nor does it need to communicate back to the ISP that another of 16 prefixes given out with the /60 have been taken. After all, if I understand correctly, this is the whole point of prefix delegation, the ISP gives out a /60, and say to our little router: "you manage this entire range", so there should be no dhcp6c involved at all here at least on the WAN interface, only router advertisements need to be started on LAN1 (but again without any impact on LAN2).
Obviously, I have not read the specs in details of how DHCPv6 PD functions, so I might be missing something really obvious :(
Thanks again for those with the patience to read my characterization of the problem as I understand it.
-
@FrenchToastDev said in Loss of IPv6 upon link up event on any track6 because of dhcp6c kill:
Here, we have ....
not read the specs in details of how DHCPv6 PD functions, so I might be missing something really obvious :(
You summed it up quiet well. I've the same understanding of things. If all goes well, this is what happens or is meant to happen.
A restart on WAN, so a restart of dhcp6c 'for whatever reason' should obtain the same prefix(s). These prefixs changed, or not, probably restarts the DHCPv6 server on all interfaces.
If the prefixes were the same, nothing really changes. If they changed, from now on, LA(s) devices use the wrong GUA == their lease is deprecated.
That's where "router advertisements" comes in handy : the pfSense LAN interface IPv6 also changed, so the royters IPv6 changed, so the LAN device know (I guess ?) it's time to force an immediate DHCPv6 lease renewal.
Again : that's how I see things, not to be mistaken by the reality of things (= RFC)@FrenchToastDev said in Loss of IPv6 upon link up event on any track6 because of dhcp6c kill:
Funny enough, you mention France as potentially lagging
said in Loss of IPv6 upon link up event on any track6 because of dhcp6c kill:
There where I use pfSense, France, IPv6 starts to become the main stream
That's the contrary of lagging .... ^^
Btw : for years, I visit forum.netgate.com only using IPv6, and right now, the US is, imho, accelerating with the IPv6 deployement, and they better be, as they've invented it in the first place.
Privacy Policy · Cookie Policy