I have the sixxs-aiccu port running that creates a IPv6 tunnel to get IPv6 access. This is working fine but sometimes the gifX interface stucks so it does not work anymore. It doesn't even answer to a ping6 to its local adress. Restarting the sixxs-aiccu daemon (that recreate the gifX interface for me), destroying and recreating the gifX interface afterwards and even using an other gifX interface (i.e. gif1 instead of gif0) do not resolve the problem. Rebooting the whole system however restore the IPv6 connectivity. The routing table is also OK and no special ipfw filters are configured. # ifconfig gif1 gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 192.168.1.250 --> 212.224.0.189 inet6 fe80::230:5ff:fe69:c309%gif1 prefixlen 64 scopeid 0x5 inet6 2001:6f8:1c00:1b8::2 --> 2001:6f8:1c00:1b8::1 prefixlen 128 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> options=1<ACCEPT_REV_ETHIP_VER> # ping6 -c5 2001:6f8:1c00:1b8::2 PING6(56=40+8+8 bytes) 2001:6f8:1c00:1b8::2 --> 2001:6f8:1c00:1b8::2 --- 2001:6f8:1c00:1b8::2 ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss # netstat -nr [...] Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2001:6f8:1c00:1b8::1 UGS gif1 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:6f8:1c00:1b8::1 2001:6f8:1c00:1b8::2 UH gif1 [...] Fix: Reboot the whole system How-To-Repeat: Don't know how to repeat the problem reproducible
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
To submitter: I have a report from IRC user <ekhramtsov> saying "I don't experience this issue with 6in4 tunnels and gif(4) on FreeBSD 12 and 13", and, also, that the sixxs-aiccu port was later deleted. I'm sorry that this PR was neglected when it came in. Can it be closed?
I think the bug can be closed as it is not relevant for me and maybe most of the user and/or has resolved by itself.
FWIW, I spun up a FreeBSD 12.2-RELEASE-p1 GENERIC droplet on Digital Ocean, and I'm seeing the same symptom. IPv6 works totally fine for maybe a half hour after a boot and then suddenly stops working altogether. In this case the interface is vtnet0. IPv4 is unaffected.
In my case, FreeBSD 12.2-RELEASE-p1 GENERIC droplet on Digital Ocean, the problem seems to be associated with IPFW. Just having IPFW enabled -- even if all packets are "pass" -- will eventually cause IPv6 to completely stop working, even being unable to ping6 anymore the IPv6 address assigned to the interface. Since Digital Ocean droplets can make use of an externally configured firewall on individual droplets or across droplets, I have decided to keep the FreeBSD firewall disabled and depend on the Digital Ocean firewall. That has solved my IPv6 problem. However, I think someone should investigate this as an IPFW problem. It's pretty easy to spin up a Digital Ocean droplet and recreate the problem. There is an apparent IPv6 bug buried deep in IPFW that seems to have a long history without being addressed!
^Triage: apparently this issue is still relevant, and specific to ipfw.
It may not be specific to IPFW, after all, although IPFW does seem to exacerbate the problem. Recently, I've noticed that the FreeBSD 12.2-RELEASE-p1 GENERIC (and64) droplet has had issues with both ICMP and ssh over IPv6. The following occurs even with IPFW disabled: ICMPv6 and ssh -6 setup are working fine, and then suddenly they stop working. When this happens, a ping6 will never succeed no longer how long it runs, and an ssh -6 will ultimately fail. If I interrupt (Ctrl-C) the process and try again it MAY immediately start working and continue to work indefinitely. Curiously, I can have two ping6 processes running simultaneously and one will indefinitely fail and the other will indefinitely succeed. When ssh -6 setup succeeds the session will remain responsive indefinitely without any failure even if another ssh -6 setup fails simultaneously. Note that IPv4 experienced none of these issues. Further, this isn't a DNS failure since the name is properly resolved, and using an IP address instead of a name produces the same results. CentOS linux systems in the same data center location experience none of these problems and IPv6 is 100% reliable there. The FreeBSD droplets all experience the problem, however. Given that a non-FreeBSD OS in the same data center has none of these problems and that other people -- witnessed by this PR and quite a few google search results -- have had similar IPv6 issues on FreeBSD over various network adapters, it's extremely likely this is a FreeBSD or FreeBSD subsystem defect. I was hoping to move all my systems from CentOS to FreeBSD but these IPv6 issues will, sadly, prevent me from making that transition. If there is anything I can do to help bring about a resolution quickly, please let me know. Unfortunately, as this problem has a long history, on the order of years, I'm not hopeful it will get solved soon.
Sigh. For a completely different reason than networking I found it necessary to create a FreeBSD droplet in a different Digital Ocean data center. To my chagrin I have not experienced a single IPv6 issue there. Moreover, pkg installs are now blazingly fast, whereas in the other data center they were often interminably slow, presumably due to network timeouts and retries. I have no explanation for why, in the other data center, CentOS had no IPv6 issues, while FreeBSD did, or why in the new data center IPv6 on FreeBSD is flawless. Perhaps this is due to different hardware that is not well supported in FreeBSD. In any case, I am going to report my experiences to Digital Ocean. If I learn anything from them I'll report back here. Sigh.
So I opened an issue with Digital Ocean, but they were not able to duplicate the problem. So, I spun up multiple FreeBSD droplets in the same problem region as before and I was also unable to duplicate the problem. Whatever was causing this issue has since disappeared. I'm somewhat embarrassed by this, but honestly it was a real problem and it lasted for days on end. I can only say that it must have been some environmental networking condition at the Digital Ocean data region that has since been resolved. Although the behavior it exhibited in FreeBSD was quite odd and quite unexplained. In any case, I'm moving forward with replacing my CentOS droplets with FreeBSD. The good old days have returned! Yay! My apologies for dredging this issue up again, needlessly. Time for me to donate $$$ again.