Coke Classic changed as well.
NAT44: the high-fructose corn syrup of IPv4.
M.
As others have said, Google's abuse systems are smart enough to understand
NAT and proxies, and won't block on request volume alone. When we
automatically apply a block, we'll generally offer a captcha to give
innocent users a workaround and limit the annoyance until the abuse stops
and the block can expire
This failed at our site. Our entire IPv4 and IPv6 addresse blocks received
captcha after captcha after captcha, forever and ever.
There was a link on the page to get more information, but all that got was
another captcha.
Normally I am 100% behind Google in everything, but sadly, this has now
fallen to 99.8%.
derek
A side project I've been meaning to take on:
In his really useful listing of content providers' IPv6 support,
https://www.vyncke.org/ipv6status/ Eric Vyncke has added "CDN" to sites
using an identifiable CDN.
I've been meaning to write a script to pull those sites and CDNs, to
identify "bang for the buck" in CDN enablement. I know Akamai is
enormous, but if CloudFlare, Limelight, and a couple of hosting companies
were to dual-stack all of their customers, would it matter that Akamai and
Amazon weren't doing so yet? Or another way to look at it would be, who
would be the key players for a major content enablement day?
Lee
I've triggered Google's CAPTCHA multiple times at home, just from
rapidly adding and removing search terms, in a couple of different
tabs, after driving down a hundred results or so.
It's been a few months, but this used to happen to me pretty regularly
if I had drive deep to find something.
Royce
Once upon a time, Royce Williams <royce@techsolvency.com> said:
I've triggered Google's CAPTCHA multiple times at home, just from
rapidly adding and removing search terms, in a couple of different
tabs, after driving down a hundred results or so.
I tend to look up docs and such from a screen session on my VPS using
Lynx (text-mode browser). My VPS provider (Linode) assigns a single
IPv6 address out of a /64 to a VPS, and apparently Google periodically
blocks the /64 I'm in. Lynx can't handle a CAPTCHA (of course), so I
don't get Google anymore for a while when that happens.
I tried logging in and allowing the cookie to see if that helped, but it
doesn't appear it does.
Jared,
Akamai has been v6 enabled for years. Customers have choices and know best.
Isn't your network still offering both as customer choices? 
Best,
-M<
>
>>
>>> Verizon Wireless is at 50% ipv6 penetration
>>
>> I suspect this would go up significantly if Twitter and Instagram would
>> IPv6 enable their services. Same for pintarest.
>
> +1
> We naturally focus a lot on network enablement here, but IMO it is a great
> time to focus on more web-based services embracing IPv6 with another June
> 6 just around the corner.I'm waiting to see Akamai and Cachefly follow the lead of Cloudflare and make everything IPv6 by default. I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)".
Jared,
Akamai has been v6 enabled for years. Customers have choices and know best.
I respectfully disagree with the 'know best', I've seen many customers who don't know the right choice and it takes a bit of time to learn the right way.
Isn't your network still offering both as customer choices?
We still are, and I posted recently on ratio that we see, which is 286:1
https://twitter.com/jaredmauch/status/466150814663581696
With so many people already doing IPv6 on their main sites, I'm hard pressed to believe this won't break people who aren't already broken.
You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken.
- Jared
Jared,
Akamai has been v6 enabled for years. Customers have choices and know best.
Isn't your network still offering both as customer choices?
Making new customers dual-stack by default for the last two years would
have gone far in increasing IPv6, unless Akamai is only losing customers to
other CDNs instead of getting new ones...
Rubens
My job isn't to increase v6. It's to make sure we can serve traffic over
protocols we are asked to. We are dual stacked which means our customers
are.
I ho
Best,
-M<
And correcting typo. Apologies, slippery thumbs
Best,
-M<
I suspect there's a problem with
the data collection on that site;
looking at
https://www.vyncke.org/ipv6status/detailed.php?country=us
I really don't think the top 5 players
don't support IPv6 DNS queries at all.
I'd be curious to know more about how the
data there is collected; I don't see any links
to any description of the data collection
methodology on the site.
Matt
1.1.1.1 is not private IP space.
BGP routing table entry for 1.1.1.0/24
Paths: (2 available, best #1)
15169
AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
Origin IGP, metric 100000, localpref 86, valid, internal, best
Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam
Originator: edge5.Amsterdam1
15169
AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
Origin IGP, metric 100000, localpref 86, valid, internal
Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam
Originator: edge5.Amsterdam1
(Yes ok, it doesn't respond to any packets last I checked)
I just wish Cisco wouldn't document it as a great IP address to use for
your captive portal
You can't cater to everyones broken network. I can't reach 1.1.1.1 from here either, but sometimes when I travel I can, even with TTL=1. At some point folks have to fix what's broken.
1.1.1.1 is not private IP space.
BGP routing table entry for 1.1.1.0/24
Paths: (2 available, best #1)
15169
AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
Origin IGP, metric 100000, localpref 86, valid, internal, best
Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam
Originator: edge5.Amsterdam1
15169
AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
Origin IGP, metric 100000, localpref 86, valid, internal
Community: Europe Lclprf_86 Netherlands Level3_Peer Amsterdam
Originator: edge5.Amsterdam1(Yes ok, it doesn't respond to any packets last I checked)
<cough>some times it does</cough>
(some portion of the space does/service replies to a sample of packets...)
Geoff should have more info on the progress of his experiment though.
I just wish Cisco wouldn't document it as a great IP address to use for
your captive portal
yea.. 'document' ... I think 'hardcode' (or perhaps default-config) is
more like it, right?
Some time back I did try responding to TCP SYNs with SYN ACKs, to see where it went. But
it massively increased load and I gave up. So if 1.1.1.1 responds to you.... its NOT me!
Geoff
I'm not going to tell you what your job is.
I'm curious, though, whether your customers specify the Internet Protocol,
and if so, whether they specify a version number? As we say in rfc6540,
you should be certain you know whether an implementation is inclusive or
exclusive of IPv6.
Lee
The data is correct — The top 5 players on that page do not have AAAA records published for their authoritative name servers (despot all being v6-capable for most or all of their content):
ryan@lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t AAAA
ryan@lion:~$
(no results for the authoritative servers of all 5 domains)
ryan@lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 dig +short -t A
216.239.34.10
216.239.32.10
216.239.38.10
216.239.36.10
69.171.239.12
69.171.255.12
216.239.38.10
216.239.34.10
216.239.36.10
216.239.32.10
68.180.131.16
119.160.247.124
203.84.221.53
68.142.255.16
121.101.144.139
98.138.11.157
91.198.174.239
208.80.152.214
208.80.154.238
ryan@lion:~$
(19 A record total results for the 5 domains in question)
The same query done together with host(1), excluding various MX responses, which would show v6 answers alongside the v4:
ryan@lion:~$ echo google.com facebook.com youtube.com yahoo.com wikipedia.org | xargs -n1 dig +short -t NS | xargs -n1 host | grep -v mail
ns1.google.com has address 216.239.32.10
ns2.google.com has address 216.239.34.10
ns4.google.com has address 216.239.38.10
ns3.google.com has address 216.239.36.10
b.ns.facebook.com has address 69.171.255.12
a.ns.facebook.com has address 69.171.239.12
ns4.google.com has address 216.239.38.10
ns2.google.com has address 216.239.34.10
ns1.google.com has address 216.239.32.10
ns3.google.com has address 216.239.36.10
ns5.yahoo.com has address 119.160.247.124
ns2.yahoo.com has address 68.142.255.16
ns3.yahoo.com has address 203.84.221.53
ns1.yahoo.com has address 68.180.131.16
ns4.yahoo.com has address 98.138.11.157
ns6.yahoo.com has address 121.101.144.139
ns0.wikimedia.org has address 208.80.154.238
ns1.wikimedia.org has address 208.80.152.214
ns2.wikimedia.org has address 91.198.174.239
ryan@lion:~$
Aha! Thank you for the clarification, Ryan; the
page is somewhat confusing, as it seemed like
it was saying there was no quad-A support from
the DNS servers; but what it's actually saying
is that the DNS servers support IPv6 queries,
but only over IPv4 transport.
Thank you for explaining the methodology
behind the report. It would definitely be
useful for the site to have a link explaining
the nature of the tests being done, to avoid
similar confusion on the part of others who
see it.
Thanks!
Matt