Some very nice broken IPv6 networks at Google and Akamai (Was: Some very nice IPv6 growth as measured by Google)

Jeroen Massar jeroen at
Mon Nov 10 07:35:01 CET 2014

On 2014-11-09 22:10, Tore Anderson wrote:
> * Jeroen Massar
>> Also note that the Akamai problem (which still persists) is a random
>> one. Hence fetching one URL is just a pure luck thing if it works or
>> not. As a generic page has multiple objects though, you'll hit it much
>> quicker.
> Hm. As I've said before - WFM. Any more information you could provide
> to help me try to reproduce it?

Try reading the links provided.

They contain the details that users have provided.

Note again: Google problem has been "fixed" (spoofing MSS is not
"fixing" the problem).

The Akamai things seems to still be in progress.

>> I am not 'insisting' that there is no problem with PMTUD.
> «No, PMTUD is fine in both IPv4 and IPv6», you said...

Fine is not perfect.

Also, taking single sentences out of somebodies comment does make the
whole sentence.

I have stated several times that there ARE issues with PMTUD and that
people need to fix them instead of hide them.

Again, please stop getting hung up on words.

>> I am stating that the problem has to be fixed at the source, not
>> hidden in the network.
> In an ideal world, perhaps. It's like with 6to4; if all relay operators
> did a wonderful job, and no-one filtered proto-41, and nobody did
> NAT44, then 6to4 would just be hunky-dory. But it's just too much
> brokenness out there.
> Same with PMTUD. It's beyond repair, IMHO. The pragmatic thing is to
> accept that and move on.

What you are saying is to just stick to an MTU of 1280 and TCP
everything forgetting about ever being able to move to anything else
than using TCP.

As QUIC is deployed and HTTP/2 is coming, forget about that.

You will need to address these concerns properly.

> Or that the tunnel ingress routers rate-limit ICMPv6 error generation.

sixxsd does not have this problem. There are no rate limits.

Thus at least everybody behind SixXS tunnels will not have that issue.

Contact your vendor to resolve your problems.

>> You are forgetting the little fact that "native" is a really strange
>> word. Quite a few DSL deployments use PPPoE etc.
>> There are also a lot of "native" deployments out there that use 6rd.
> In my experience, these ISPs deploy workarounds to avoid PMTUD. TCP MSS
> clamping, and LAN RA MTUs (for IPv6). That helps.

For TCP, not for anything else.

Chrome speaks QUIC to various Google properties.

>> Instead of just coming with "TUNNELS SUCK!!!!@&$!@#&$%^!*@%!" actually
>> Contact the networks that are broken and try to get them to fix the
>> problem. You might not want to fix those as it is not your problem,
>> but it is a problem for access networks.
> I think PMTUD on the internet is broken beyond salvation

Then please give up on it and let the rest of the world care about it
and notify folks and let them fix the problem properly.


More information about the ipv6-ops mailing list