[c0nsumer]

I've been trying on and off to get IPv6 working at home, but the problem I keep running into is poor performance from tunnels. I have service via Wide Open West which is great for IPv4, but they have no plans to support IPv6. So, I try using a tunnel...

Both HE.net and SixXS are so incredibly slow that I get >1 second pings to something which is 30ms away via IPv4. The tunnel end point is only ~50ms away, so I can only see the latency as being within the tunnel provider...

I really, really wish that I had a native IPv6 connection at home, but I don't want to switch to Comcast, which is the only IPv6 option for me.

[IgorPartola]

Shoot an email to HE. Their support for this free service is better than most commercial support teams I've interacted with.

Also, don't discount that it's possible that the other end of the equation, the server you are trying to reach, has poor IPv6 connectivity. Fire up a Digital Ocean instance for an hour (it'll cost you $0.10) and see if the site is slow from everywhere.

I've been using HE.net's tunnels for a good long while now and they've been great for me.

[c0nsumer]

Unfortunately, it's anything that's slow... When I've got a tunnel live, Google properties and Facebook are pretty much unusable. Weirdly, sometimes it'll work fine... Other times it won't. (The server I'm testing against with is my personal site, https://nuxx.net, which has great IPv6 connectivity already. I just don't want to tunnel my home connection through it because that'll seriously push up the bandwidth use of the hosted server.)

There's two things that I haven't taken the time to rule out yet: my router potentially being problematic (it's an Apple Airport that otherwise works well) and the ISP slowing down tunneled traffic. The former would require setting up a new router, and the latter... I'm not sure how I'd do that yet. IPv6 connectivity had been working fine until a month or two ago when things just went weird.

Good thought on sending HE a message... I'll do that later today. Maybe there's something they've run into before with this combo. When their tunnel was up and working great it was surprisingly nice.

[ay]

This description might also match a partly-working path MTU discovery (a possibly too-high rate of ICMP egress from HE end to content sites, blocked by rate-limiter on the HE device).

In IPv4 you do not notice it (it almost never triggers) because there is less tunnels and also because generally everyone does MSS clamping. In IPv6, you have the tunnel and not necessarily MSS clamping.

Two ways to tackle it:

- configure on the home router interface facing your LAN, IPv6 MTU less than you have on the tunnel (I have 1400 just because I like round numbers :-) Cleaner because works for (mostly) all protocols.

- configure the first hop router to do MSS clamping for TCP on IPv6 to 20 bytes less than what it currently does (if at all). This will work for only TCP, but that'll be the vast percentage of the traffic you are having problems with.

[c0nsumer]

So... Changing the MTU didn't help. Even at the minimum of 1200 I still had issues. Sometimes pings (even small 60 byte ones) would be fast, other times they'd be upwards of one second. Not sure what's going on yet, as I've put working on this aside for now.

[ay]

Okay, if there is a jitter on individual pings, it is certainly not the PMTUD-related - and if there is no packet loss, then it is shaping - either intentional, or some middlebox can't cope with the load.

When using AICCU (sixxs) - were you using protocol 41 or the UDP-based encap ? if protocol 41, then experimenting with switching to UDP might be interesting.

[c0nsumer]

This is a very good thought, and something I hadn't tried yet... Mostly due to the sporadic functionality of the issue. I'll give this a go tonight; thank you.

[tw04]

You could try glasnost: http://broadband.mpi-sws.org/transparency/glasnost.php

It probably won't help you with your specific tunnel, but you can check other traffic to see if there's any filtering occurring. It seems unlikely they'd ONLY throttle ipv6 tunnel traffic.

Also, the other thing I ran into with he.net tunnel was a problem with pmtu discovery. I had to manually set the mtu/mss on my router (pfsense). I have no idea if the airport will even let you.

https://forums.he.net/index.php?topic=3028.0

[Zancarius]

> I've been using HE.net's tunnels for a good long while now and they've been great for me.

Same here. As of about a year or two ago, my pings over the HE tunnel are only very slightly worse than those over my IPv4 interface, and I can't notice much difference in throughput. I've encountered minor issues with their tunnel servers from time to time, but usually by the time I notice the problem is resolved.

I also have to second that their support is absolutely fantastic. Plus there's always their forums, in case someone else has run into something similar. Many of tunnelbroker.net's users are equally friendly and helpful.

[justincormack]

They do rate limit you to around 4Mb I believe so you might want to not ship your netflix over them, which it will unless you are careful.

[IgorPartola]

Reference? I couldn't find anything about it, and have been watching Netflix through them for at least three years now.

[justincormack]

Thats what a friend claimed, although HE seem to deny it. I had to disable it for Netflix as it got geolocation wrong, so probably never really tested it.

[jandrese]

Weird. I use HE.net as well and often the latency on V6 is better than it is on V4:

My results at the moment:

ping6 google.com PING6(56=40+8+8 bytes) [Redacted] --> 2607:f8b0:4009:807::1000

16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=0 hlim=58 time=22.727 ms

16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=1 hlim=58 time=21.862 ms

16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=2 hlim=58 time=25.147 ms

vs.

ping google.com

PING google.com (216.58.216.224): 56 data bytes

64 bytes from 216.58.216.224: icmp_seq=0 ttl=251 time=37.229 ms

64 bytes from 216.58.216.224: icmp_seq=1 ttl=251 time=36.672 ms

64 bytes from 216.58.216.224: icmp_seq=2 ttl=251 time=38.319 ms

I think this is due to my provider (Verizon) being a dick with their peering agreements and the HE.net traffic goes over a less congested pipe than my ordinary v4 traffic.

[speleding]

I had no trouble getting an HE tunnel working, but it does mess up some sites that depend on IP geolocation. Netflix in particular becomes very confused about my whereabouts and refuses to play a lot of content.