Print

[bartgrefte]

Years ago, when I first started using a HE-tunnel, it didn't take long before I disabled IPv6 on my wireless network because Android (v5 on a Galaxy S4 back then) was being a pain in the butt. I don't remember what the problems were exactly, only that when IPv6 became active there were problems.

Not too long ago I switched from a /64 to a /48, giving each VLAN it's own /64, this is when I decided to give IPv6 on my wireless network and current phone (Android 8, Galaxy S7) another try ..... and again problems.

The internet connection on my phone varies from working normally, to longer load times, the occasional timeout and sometimes stuck on loading. A restart of the apps in question usually solves that, temporarily.

But again it's just Android being problematic. Every other IPv6 capable (virtual) device in my network, with Windows 10, various Linux distributions and even an iPad with iOS 5, do not show problems at all. Well, that's not entirely correct, ESET Internet Security was blocking ICMPv6 (which IPv6 test websites showed) but I didn't even notice that until I checked those websites.

Since my phone is not rooted, the options to troubleshoot this are somewhat limited, plus Google doesn't help much.

When Googling "Android IPv6 slow", I kept running into two possible solutions: Disable IPv6, which means disabling it on the entire VLAN because I cannot do that on Android without rooting my phone. The other was adding the RDNSS option in radvd.conf to specify an IPv6 DNS server, which I have, didn't make a difference.
Note that for some reason, I cannot find apps that are capable of displaying the assigned IPv6 DNS server on Android, just IPv4, but the PiHole log does show DNS requests from my phones IPv6 addresses, so it's picked it up.

As for testing, I tried both http://ipv6-test.com and http://test-ipv6.com. The 2nd gives a 10/10 score, though warning it's not a native IPv6 connection. The 1st 16/20, ICMP is reported as filtered, though sometimes it's reported as "not tested". On other devices the score is 18/20, with "Fix your DNS configuration" as the only reported issue.

When trying http://ipv6-test.com/pmtud/ , which reports "no PMTUD problems detected" on non-Android devices, the results vary. Right now it reports "no PMTUD problems detected", but minutes earlier it reported problems with values above 1300, which for some reason I cannot reproduce right now.

So... does anyone have any idea's about how to troubleshoot this? From the limited amount of testing I could do, it looks (to me) it might be an intermittent MTU issue. Normally that indicates firewall issues, but if it was nftables on my router-pc blocking it, all devices would've been affected. Plus, the router-pc's firewall is set to allow all ICMPv6 packets.

[tjeske]

Years ago, when I first started using a HE-tunnel, it didn't take long before I disabled IPv6 on my wireless network because Android (v5 on a Galaxy S4 back then) was being a pain in the butt. I don't remember what the problems were exactly, only that when IPv6 became active there were problems.

The problem was the WiFi driver. Samsung for some reason thought it should block ICMPv6/NDP in standby to safe battery. That means the IPv6 connection would go stale. However, the handset wasn't informed about this and tried to continue using the stale IPv6 connection, until it would eventually timeout and fallback to IPv4.

I had the same handset, and those problems are still prevalent today when I connect it to my IPv6-only WiFi. Even worse: it's almost impossible to update anything because as soon as the screen goes off, the device loses internet connectivity. And for some other reason 464XLAT doesn't work on WiFi connections on the Galaxy S4.

Not too long ago I switched from a /64 to a /48, giving each VLAN it's own /64, this is when I decided to give IPv6 on my wireless network and current phone (Android 8, Galaxy S7) another try ..... and again problems.

The internet connection on my phone varies from working normally, to longer load times, the occasional timeout and sometimes stuck on loading. A restart of the apps in question usually solves that, temporarily.

I now use a NoteFE, which is equivalent to the S7 (except for the SPen and it got upgraded to Android 9). Not problems with IPv6 anymore. However, RAM management has gotten worse with some update, and since then apps are frequently sent to sleep in the background.

There could also be a compatibility issue with your WiFi access point? Which one do you use? It seems that in the past they often didn't send enough "keep alive" (forgot the correct IPv6 terminology). Maybe it's got to do with this?

So... does anyone have any idea's about how to troubleshoot this? From the limited amount of testing I could do, it looks (to me) it might be an intermittent MTU issue. Normally that indicates firewall issues, but if it was nftables on my router-pc blocking it, all devices would've been affected. Plus, the router-pc's firewall is set to allow all ICMPv6 packets.

MTU often causes weird failures. Maybe try this site to determine you max MTU?
http://www.letmecheck.it/mtu-test.php

[bartgrefte]

The problem was the WiFi driver. Samsung for some reason thought it should block ICMPv6/NDP in standby to safe battery. That means the IPv6 connection would go stale. However, the handset wasn't informed about this and tried to continue using the stale IPv6 connection, until it would eventually timeout and fallback to IPv4.

Ah, that explains it for that one

I had the same handset, and those problems are still prevalent today when I connect it to my IPv6-only WiFi. Even worse: it's almost impossible to update anything because as soon as the screen goes off, the device loses internet connectivity. And for some other reason 464XLAT doesn't work on WiFi connections on the Galaxy S4.

That I do remember, the losing connectivity when the screen goes off, very annoying...

I now use a NoteFE, which is equivalent to the S7 (except for the SPen and it got upgraded to Android 9). Not problems with IPv6 anymore. However, RAM management has gotten worse with some update, and since then apps are frequently sent to sleep in the background.

There could also be a compatibility issue with your WiFi access point? Which one do you use? It seems that in the past they often didn't send enough "keep alive" (forgot the correct IPv6 terminology). Maybe it's got to do with this?

For the last couple of years I've been using an Ubiquiti UAP-AC-LR, before that (when I still had the S4) I was using an Atheros AR9380 mini PCIe wifi card as access point that was build into my router-pc.

MTU often causes weird failures. Maybe try this site to determine you max MTU?
http://www.letmecheck.it/mtu-test.php

Hmm, just tried that page on my desktop first (for comparison), the results are not consistent. With one attempt, only 1517 bytes is reported as fragmented, the rest not and it ends with

From the tests we did, we can assume that 1516 bytes is the largest unfragmented packet size. The MTU size would be 1564, made up from 1516 payload and 48 ICMP/IP Headers
and payload information.

The current maximum payload size is not divisible by 8.
The actual size of the payload (data) will be limited to: 1512

The maximum MTU size for desktop-IPv6 is: 1564

The 2nd try results in 750 and 755 bytes fragmented, no results after 754 bytes and

From the tests we did, we can assume that 754 bytes is the largest unfragmented packet size. The MTU size would be 802, made up from 754 payload and 48 ICMP/IP Headers
and payload information.

The current maximum payload size is not divisible by 8.
The actual size of the payload (data) will be limited to: 752

The maximum MTU size for desktop-IPv6 is: 802

and the 3rd try results in 1454 and 1464 fragmented, the rest not and

From the tests we did, we can assume that 1463 bytes is the largest unfragmented packet size. The MTU size would be 1511, made up from 1463 payload and 48 ICMP/IP Headers
and payload information.

The current maximum payload size is not divisible by 8.
The actual size of the payload (data) will be limited to: 1456

The maximum MTU size for desktop-IPv6 is: 1511

That test wont run on my S7, it says either the IP-address is invalid or ICMP is filtered, in both Chrome as well as the Samsung internet browser. There shouldn't be any firewall issues, my wireless network uses the same rules as wired, unless Android 8 has some build in hidden firewall.