Some very nice broken IPv6 networks at Google and Akamai
sander at steffann.nl
Mon Nov 10 19:36:22 CET 2014
Op 9 nov. 2014, om 22:10 heeft Lorenzo Colitti <lorenzo at google.com> het volgende geschreven:
> On Sat, Nov 8, 2014 at 11:48 PM, Jeroen Massar <jeroen at massar.ch> wrote:
>> The issue with IPv6 access to Google should now be resolved. Please let
>> us know if you're still having problems.
>> The fun question of course is: what/why/how the heck happened?
> Another fun question is why folks are relying on PMTUD instead of adjusting their MTU settings (e.g., via RAs). But relying on PMTUD still imposes a 1-RTT penalty on every TCP connection to an IPv6 address you haven't talked to in the last few minutes. Why would you do that to your connection?
I guess most users wouldn't really notice a 1-RTT delay. But I agree that it is less than optimal that every outbound connection from a network behind a non-1500-MTU link has to suffer this penalty. Unfortunately the current choices seem to be to either limit the link MTU (and making traffic to e.g. the local NAS suffer as well) or suffer the 1-RTT penalty.
> As to what happened: what happened here is that some Google servers temporarily stopped doing MSS clamping. That was an outage, and AIUI it has since been fixed. (Some parts of) Google infrastructure do not do PMTUD for the latency reasons above and for reasons similar to those listed in https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-00 .
Thank you for the information. Great to have real data instead of guesses and speculation :)
More information about the ipv6-ops