Some very nice IPv6 growth as measured by Google

Tore Anderson tore at fud.no
Sat Nov 8 18:38:59 CET 2014


* Jeroen Massar

> The only link: they are all using IPv6.
> 
> You are trying to make this OTE link. I have never stated anything
> like that. Though, you likely take that from the fact that the reply
> followed in that thread.

Yannis: «We're enabling IPv6 on our CPEs»
Jeroen: «And then getting broken connectivity to Google»

I'm not a native speaker of English, but I struggle to understand it
any other way than you're saying there's something broken about
Yannis' deployment. I mean, your reply wasn't even a standalone
statement, but a continuation of Yannis' sentence. :-P

Anyway, I'm relieved to hear that there's no reason to supect IPv6
breakage in OTE. As we host a couple of the top-10 Greek sites, one of
which has IPv6, we're dependent on the big Greek eyeball network like
OTE to not screw up their IPv6 deployment - it is *I* who get in trouble
if they do. :-)

> PMTUD is fine.
> 
> What sucks is 'consultants' advising blocking ICMPv6 "because that is
> what we do in IPv4" and that some hardware/software gets broken once
> in a while.

PMTUD is just as broken in IPv4, too. PMTUD has *never* been «fine»,
neither for IPv4 nor for IPv6. That's why everyone who provides links
with MTUs < 1500 resorts to workarounds such as TCP MSS clamping and
reducing MTU values in LAN-side RAs, so that reliance on PMTUD
working is limited as much as possible. If you want to deliver an
acceptable service (either as an ISP or as a content hoster), you just
*can't* depend on PMTUD.

Even when PMTUD actually works as designed it sucks, as it causes
latency before data may be successfully transmitted.

> See the threads I referenced, they are still in the above quoted text.
> 
> Note that the Google case is consistent: (as good as) every IPv6
> connection breaks.
> 
> The Akamai case is random: sometimes it just works as you hit good
> nodes in the cluster, sometimes it breaks.

I see in the threads referenced things statements such as:

«this must be a major issue for everybody using IPv6 tunnels»
«MTU 1480 MSS 1220 = fix»
«the 1480MTU and 1220MSS numbers worked for my pfsense firewall»
«The only thing that worked here is 1280 MTU / 1220 MSS»
«clamping the MSS to 1220 seems to have fixed the problem for me»
«I changed the MSS setting [...] for the moment Google pages are
loading much better»

This is all perfectly consistent with common PMTUD mailfunctioning /
tunnel suckage. I'm therefore very sceptical that this problem would
also be experienced by users with 1500 byte MTU links. (Assuming
there's only a single problem at play here.)

> In both cases, it is hard to say what exactly breaks as only the
> people in those networks/companies have access to their side of the
> view.
> 
> As such... here is for hoping they debug and resolve the problem.

Having some impacted users do a Netalyzr test might be a good start.
Like I said earlier, WFM, but then again I'm not using any tunnels.

Tore


More information about the ipv6-ops mailing list