When 6to4 ipv6 is enabled, facebook mobile does not fully load all videos and pictures (IOS and Android)

kjstech

I found that a long time issue I've been experiencing with poor performance, stuttering videos, infinitely loading picture via the facebook mobile apps on both android and IOS devices goes away if I disable IPv6 on WAN and LAN on my pfsense 2.4.3 machine.

The only thing I could think of is a possible mtu issue. I'm trying ping 6 and what I found by process of elimination I cannot get a response from anything larger than 1232 packet size, so this works:

ping6 -c 3 -s 1232 ipv6.google.com

But this does not

ping6 -c 3 -1233 ipv6.google.com

Same results with another host, such as tunnelbroker.net.

So I tried setting MSS clamping to 1232 on the WAN side, and I had the same issue. I then decided to also set it on the LAN side and still same issue. I saw that I have ICMP for IPv4+IPv6 allowed from wan so thinking maybe its a bug I separated it out into two pass rules, one for ALL ICMP IPv4 and one for ALL ICMP IPv6. My reasoning for this was to ensure pfsense was getting the packet too big ICMP announcements (if they are being sent at all).

Anyway I have been unable to get this working so for now I have IPv6 disabled as all it really does is break the facebook mobile app. I have to wonder if slow DirecTV video on demand was also a because of this.

I ran a test using the java based utility from netalyzr.icsi.berkeley.edu and I get this warning, even with the MSS clamping set.

IPv6 Path MTU (?): Warning –

Your system can not send or receive fragmented traffic over IPv6. The path between our system and your network has an MTU of 1500 bytes. The path between our system and your network does not appear to handle fragmented IPv6 traffic properly.

There is a free program called mtupath.exe you can download (google it) and it will determine the maximum mtu for either IPv4 or IPv6 against a target. Running it against facebook.com showed ipv6 maximum mtu is 1232 while in ipv4 its 1472.

Any suggestions? The configuration was 6in4 on WAN and for the LAN it was set to track interface WAN, prefix 48. All devices on the LAN received IPv6 addresses and when performing a whois on the address, it correctly identifies my ISP and ipv6-test gives me a 18/20 when its enabled.

mrsunfire

I have nearly the same problem. I get random packetloss on IPv6 site. IPv4 works fine.

dem

I have 6rd and have also seen random packet loss on IPv6. I resolved it by having Router Advertisements specify the MTU as 1280.

I created the following patch which I apply with the System Patches package:

--- /etc/inc/services.inc.orig  2017-10-19 09:51:44.000000000 -0400
+++ /etc/inc/services.inc       2017-10-25 09:23:00.062171000 -0400
@@ -128,6 +128,7 @@
                }
 
                $mtu = get_interface_mtu($realif);
+               $mtu = 1280;
                if (is_numeric($mtu)) {
                        $radvdconf .= "\tAdvLinkMTU {$mtu};\n";
                } else {

kjstech

Does this only apply to ipv6 traffic?

I wouldn't want to lower ipv4 from the 1500 down to 1280.

Right now everything works as intended with just ipv4. The only thing I get with ipv6 is geek cred and an 18/20 score on ipv6-test.com. I'm not sure its worth the extra effort, but I'm willing to try this patch if there is no performance degradation.

I'm curious if that would resolve the issues loading media via the Facebook mobile applications for IOS and Android. I've read some posts also had trouble with google and youtube with ipv6 enabled, but I can't recall ever having an issue with either of those, mobile or desktop.

dem

Router Advertisements are an IPv6 thing. IPv4 won't be affected.

If you decide to try the patch, restart radvd after applying it.

kjstech

@dem
I'll give it a shot. I installed Systems Pataches package. I pasted your code in and applied it.

I went to WAN, changed IPv6 from none to 6to4 Tunnel. Applied.
Went to LAN and changed IPv6 to track, went down and specified WAN and set prefix to 48. Applied.
I'm seeing IPv6 with my ISP's prefix on both WAN and LAN now. I'm not sure if radvd was stopped because IPv6 was set to none. Not seeing where to restart it. Tried command line:

[2.4.3-RELEASE][root@pfSense.local]/root: service radvd stop
Stopping radvd.
Waiting for PIDS: 91703.
[2.4.3-RELEASE][root@pfSense.local]/root: service radvd start
Cannot 'start' radvd. Set radvd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.

I'm remote in via SSH anyway so I can't really test until I get home.

kjstech

Well I went into DHCPv6 Server and RA > Router Advertisements tab and just saved it.

I then tried this and it looks like its already running under a new PID so I think it restarted properly.

Will test as soon as I get home.

service radvd onestart
radvd already running? (pid=89110).

dem

If you want to see if the patch is working, from the shell run cat /var/etc/radvd.conf and look for AdvLinkMTU 1280;.

mrsunfire

I tried your patch and it works that the MTU now is 1280! But I still get random packetloss on IPv6:

Ping wird ausgeführt für heise.de [2a02:2e0:3fe:1001:302::] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=11ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=7ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms

Ping-Statistik für 2a02:2e0:3fe:1001:302:::
    Pakete: Gesendet = 36, Empfangen = 13, Verloren = 23
    (63% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 7ms, Maximum = 11ms, Mittelwert = 8ms```

dem

Sorry it doesn't work for you. Your problem doesn't look MTU related since default ping packets are pretty small, much less than 1280.

mrsunfire

Hm any idea? Don't know where to look at. Ping from WAN interface is ok, Ping from LAN interface gets the packetloss.

kjstech

Ok I’m home now. On my WiFi connected iPhone I have an ipv6 address. I pass online ipv6 tests just like before. So far the Facebook mobile app is responsive and everything is loading (videos and pictures when clicking on them to make them full size).

I’ve only browsed for a few minutes and I didn’t break out the android yet, but so far so good! We may be onto something that lets me have my ipv6 and Facebook mobile at the same time!

Thanks for your contribution. I would be curious as to the technical reason why, and if Netgate plans to make this fix permanent without a patch. If I update pfsense do I need to reapply? There is a 2.4.3-1 update available that I did not do yet.

kjstech

Spoke too soon, not fixed. Maybe a little better but I just found a bunch of videos in the Facebook mobile app that will not play. I got one to play 10 seconds than it froze indefinitely. Now I’m encountering many videos where I see the first frame and it just spins and spins. If I turn off WiFi and go out AT&T it works fine, so it’s not the phone.

Is the 1280 we put in counting overhead, or should I try entering 1232?

dem

Without the patch the advertised MTU is that of the underlying interface, usually 1500. IPv6 is supposed to then figure out the true MTU on its own, but in reality this doesn't seem to work in all cases, especially if the IPv6 is tunneled like it is with 6to4 and 6rd. I don't know where the problem really lies.

So the patch tells the clients just to use the smallest allowable IPv6 MTU of 1280, which I believe is the default MTU of 6rd, and based your ping tests of 6to4 too.

If you select Auto Apply your patch will survive updates, unless the file in question changes too much for the patch to be applied cleanly.

It would be convenient if we could set the MTU ourselves in the Router Advertisements settings.

As I was writing this I see you wrote that your problem might not be fixed, which is too bad. 1280 is the smallest allowable MTU for IPv6, and I think is correct for you since a ping payload of 1232 + 8 bytes of ping packet overhead + 40 bytes of IPv6 addressing overhead is 1280.

dem

Having written that, I find MTU and MSS confusing and am not an expert, so I could be completely wrong.

kjstech

@dem

Ok I changed it to 1232 in your patch and applied it. In the RA tab under DHCPv6 area I set it to disabled, applied then back to assisted. Still have the problem. I then tried stateless dhcp as the RA mode, everything else is default on that screen.

Turned off WiFi and turned it back on. Tried same video that was stuck and now it’s playing. So I think I need to do more testing and play with the various settings. I have two ipv6 addresses on my phone, a link local and the public one that my ISP assigns.

kjstech

I spoke too soon. That video plays now but I scrolled down and the next one was stalled. I disabled ipv6 on wan and lan, went back to Facebook mobile app and the video began playing instantly.

I’m at a loss. If I get time later maybe I will log a putty session running tcpdump on ipv6 traffic when trying to replicate the problem.

dem

I think the RA mode you probably want is Unmanaged.

mrsunfire

@kjstech I think we've the same issues. Try a IPv6 ping. After heavy using IPv6 (Google maps, Youtube, Facebook) my IPv6 connection gets worse and worse. Reboot pfSense oder restart the WAN interface helps and the connection is fine for some moments again.

kjstech

Hi Just an update. Updated pfSense to 2.4.4 and I'm trying ipv6 again. I'm hoping that in this new version that ipv6 issues have been resolved.

So far so good, but time will tell.