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

Does somebody have a more definitive list? I got complains about Netflix complaining about VPN. However, I don't serve DNS - that is up to some other entity in my setup - and I can't intercept it. Being in Europe, so far blocking 2a01:578:3::/48 used to suffice. But apparently not so anymore. What other IP range would I need to block?

EDIT: I have also heard reports that Netflix stopped blocking HE tunnels altogether? Can anyone confirm this?
EDIT2: I am continuing to hearing those reports. Is the Netflix-block over?
EDIT3: Tried it myself now. Seems to depend on the series. Some work, some don't.

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.

dnsadmin at he.net was able to help me through the issue, and the root cause was indeed the / in the zone name.

Thank you for helping!

Hi,

I have been trying - but failing - to set up a slave reverse dns zone on my dns.he.net account.

I have been going through the "add a new slave" function, but this returns an error message "Zone failed validation test. Zone is not valid."

I think it is quite likely that the issue may be caused by my zone name, which follows the original rfc2317 format including the use of a / as part of the zone name. But, I don't know that for sure, as the message doesn't make it clear if the issue is with the zone name or with anything else. For the record, I did not pick the name, my internet provider (AT&T) did when they delegated the reverse dns for my IP block to me.

has anyone here dealt with this issue before ?

Thanks,

From submitted tickets and internal tests, MTR/ping/traces show that packets are delivered to Yahoo nodes without loss. Native IPv6 is connecting without issue to service ports at the destination. Over tunneled connections, MTR works, however Yahoo is not responding at the service level regardless of MTU tuning. I've sent them an email detailing this, but since packets are clearly being delivered to their network, they've likely got some issues to sort out on their side.

If their users haven't already, I recommend also contacting them directly since this appears to be an issue with their service and not us delivering packets over the network.

I have been seeing this same issue as well for about 2 months.  Adding Yahoo's IP range to my outbound blocklist fixed it.  Connected via Ashburn server.

I added Yahoo's IPv6 block to my firewall's IPv6 block list (used to block Netflix's networks so I can watch videos on Netflix) and it's working now.  There's an issue between HE and Yahoo that still needs to be resolved but this works in the meantime.

Yahoo's IPv6 network is 2001:4998::/32.

As of yesterday, I’m seeing this also, but only from my Windows 10 laptop.  My iPad gets there fine.  Strange.  Maybe a record caching issue?

Since the first tunnel is still there, check your routing table to see which tunnel the outbound ping is using. (Probably the first).  That would mean the second tunnel is being ignored.  Kill the first one.

Same here.  Is there a way to open a trouble ticket with HE?  They might be in a position to help get the routing or whatever corrected.