Why don't LAN side links recover their IPV6 addresses?



  • Whenever a LAN side link goes down and comes back up, it fails to recover its IPV6 address!!! A pfSense reboot is required to recover them.



  • Yes, there are various threads and a red mine ticket on this. It's somehow related to the fact that your cable modem will hand out a temporary private DHCP lease when its uplink is down, but not a temporary DHCP6 lease. This causes radvd to exit, and it never gets restarted, even after the uplink recovers. Somebody suggested that the mysterious "request IPv6 prefix via IPv4 link" should avoid this, but in my experience it doesn't make a difference.



  • @razzfazz:

    Somebody suggested that the mysterious "request IPv6 prefix via IPv4 link" should avoid this, but in my experience it doesn't make a difference.

    Having that checked actually made it worse for me.  After the DOCSIS side of the cable modem dropped and CM rebooted (normal recovery process), I lost the LAN IPv6 addressing.  Multiple reboots of the CM and pfSense would not bring it back.  I unchecked this option, rebooted, and only then was I able to get the LAN IPv6 prefix again.

    Other platforms I've used, including m0n0wall and Mikrotik, do not have this problem.  So, it's not inherent to the way cable modems and IPv6 DHCP-PD work.



  • So… now that we're all on a RELEASE version are we expected to live with these deficiencies??? Seems severely broken in so many ways!





  • That was a yes/no question. If no, then through what mechanism will these deficiency be corrected? It's a little early in the cycle to jump on the next release nightly builds.



  • If the old ones worked better for you, go back.  If corrections have been made, you can synch to those.  If neither of those are good its a waiting game.  If you need something done really really fast, they allow you to post bounties for functions  ;)



  • "Whenever a LAN side link goes down and comes back up, it fails to recover its IPV6 address!!! A pfSense reboot is required to recover them."

    Just thinking…  Could you write a script to reboot the unit automatically in the event of a dropped link?  Perhaps someone already has.



  • IPV4 works fine and stays up, and most clients depend on it. At this stage IPV6 is more of an experiment and wanting it to work well is only a matter of principle.



  • There are some people here who are IPV6 gurus that I bet could help you if you ask nicely.  Be careful not to slam pfsense in the opening of the help request because in the end, it could easily be something that you are doing wrong.  Don't wanna make them defensive before you ask "please help me".  Lots of people are running IPV6 so my guess is yours can work if set up correctly.



  • I don't believe this particular issue is a setup problem. It's fairly well understood why it happens (modem hands out temporary leases for v4 on disconnect, but not for v6 –> pfSense gives up on v6 and never tries again); just not clear what can be done about it.



  • It's not clear to me why dhcp6c should give up? It retries a couple of times, why not indefinitely? Besides, I though that in V6 dhcp was only used to get the DNS server address and that the rest was done using router advertisements. I suppose the unregistered modem would need to fake those out too.

    Is it indeed the case that m0n0wall doesn't have this problem? How do they deal with it?

    I don't think there's a way to restart the dhcp6 client against a link that's already up?



  • Prefix delegation happens through DHCP6, not RAs. I believe m0n0wall uses a different DHCP6 client.



  • Ah, ok… makes sense then.


Log in to reply