<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 16, 2015 at 11:24 PM, Lorenzo Colitti <span dir="ltr"><<a href="mailto:lorenzo@google.com" target="_blank">lorenzo@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">And in the meantime, accept that the users of that operator's network cannot reliably reach our services?<div><br></div><div>If you were a user of that operator, I suspect you wouldn't like that. I suspect you especially wouldn't like it if you called the operator and they told you there were no problems, and most websites work fine. Unfortunately, in our experience, both happen routinely. Often operators will contact us and claim there is no problem in the network, and most of the time it turns out that there was a problem they didn't know about. Once the claim was made that "this is an IPv6-only network, so IPv6 must be working". Unfortunately that wasn't true either.</div><div><br></div><div>If an operator is monitoring IPv6 traffic levels, it will be pretty clear if Google stops serving AAAA records to their resolvers. If they're not monitoring IPv6 traffic levels, then chances are they're not monitoring reliability, because it's much easier to monitor traffic than to monitor reliability.<br><div><br></div><div>There's also the question of how whether it's reasonable to expect websites to to reduce the reliability of their services in order to fix problems in other networks that they have no control over. Remember, IPv6 brokenness was one of the main reasons it took so long for popular websites to enable IPv6.</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div><br></div><div>I agree with Google's approach for now.</div><div><br>But eventually it will have to be re-visited since Google represents a huge amount of traffic, pulling back AAAA and sending that huge amount of traffic to a CGN that is not dimension for it.... you are going to have a bad time.</div><div><br></div><div>And, AFAIK, these measurements and adjustments are not real-time... so they blow up a CGN ... they wont automagically roll back for a while. So, Google AAAA magic becomes a DDoS of sorts.</div><div><br></div><div><br></div><div>Maybe i am wrong.</div><div><br></div><div>CB</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 17, 2015 at 12:28 PM, Brian E Carpenter <span dir="ltr"><<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 17/04/2015 15:17, Erik Kline wrote:<br>
> On Thu, Apr 16, 2015 at 7:41 PM, Phil Mayers <<a href="mailto:p.mayers@imperial.ac.uk" target="_blank">p.mayers@imperial.ac.uk</a>> wrote:<br>
>> On 16/04/15 01:57, Lorenzo Colitti wrote:<br>
>><br>
>>> For the avoidance of mystery: Google performs measurements of IPv6<br>
>>> connectivity and latency on an ongoing basis. The Google DNS servers do<br>
>>> not return AAAA records to DNS resolvers if our measurements indicate<br>
>>> that for users of those resolvers, HTTP/HTTPS access to dual-stack<br>
>>> Google services is substantially worse than to equivalent IPv4-only<br>
>>> services. "Worse" covers both reliability (e.g., failure to load a URL)<br>
>>> and latency (e.g., IPv6 is 100ms worse than IPv4 because it goes over an<br>
>>> ocean). The resolvers must also have a minimum query volume, which is<br>
>>> fairly low.<br>
>><br>
>><br>
>> Lorenzo,<br>
>><br>
>> Thanks for the response.<br>
>><br>
>> Do you know if Google have given any thought as to how long they might find<br>
>> it necessary to take these measures? Years, indefinitely?<br>
>><br>
>> Just curious.<br>
><br>
> It seems to keep on finding things, so...<br>
<br>
</div></div>But the incentive is wrong. Forcing users to drop back to IPv4 offers<br>
no incentive to fix the IPv6 problem. The correct incentive would be to<br>
tell an operator that they will be blacklisted unless they fix {X and Y}.<br>
<span><font color="#888888"><br>
Brian<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>