Hi Everyone, May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot. Is there any official channel from Google which we could work with them for resolution? Thanks much! Best, Edy
On Tue, May 20, 2014 at 10:35:56AM -0400, Harald Koch wrote:
Might help if all your hosts have their own IPv6 addresses
That was meant to be implied... But... On Tue, May 20, 2014 at 09:10:56AM -0600, Derek Andrew wrote:
They take out our campus, both IPv4 and IPv6.
That's interesting, I haven't seen this happen with IPv6. Some of the networks I work with do the "everything behind NAT" thing and get bitten by this. Using a pool of addresses helps but... This is only going to get more painful with more people doing "Carrier Grade" NAT... -w
Some of the networks I work with do the "everything behind NAT" thing and get bitten by this. Using a pool of addresses helps but... This is only going to get more painful with more people doing >"Carrier Grade" NAT...
I Run CGN with tens of thousands of broadband users being translated behind /24 pools and experience no issues with Google whatsoever. (APNIC ran out of IP's some time ago) Occasionally there are issues with things like banks and universities firewall rules who get confused when hundreds of users are accessing them from one or two IP addresses, but this is not often. The biggest issue is the DDOS attacks have a much bigger effect if the upstream's block our destination IP before we can take the target out of the NAT pool. But that is an education thing primarily. Blocking ddestination IP's for DDOS mitigation is going to have to be phased out, its really just laziness and it rewards the attacker.
Deploy IPv6. This is the solution to this problem. Google supports IPv6 on all their services AFAIK. Mark In message <537B64F7.5020504@edylie.net>, Pui Edylie writes:
Hi Everyone,
May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot.
Is there any official channel from Google which we could work with them for resolution?
Thanks much!
Best, Edy
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On May 20, 2014, at 7:21 AM, Pui Edylie <email@edylie.net> wrote:
Hi Everyone,
May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot.
Is there any official channel from Google which we could work with them for resolution?
Thanks much!
Best, Edy
The absolute best solution is to deploy IPv6 and deprecate NAT. If you’re looking for an IPv4-only solution, I don’t have a good answer for you. Owen
On May 20, 2014, at 7:21 AM, Pui Edylie <email@edylie.net> wrote:
The absolute best solution is to deploy IPv6 and deprecate NAT. If you're
looking for an IPv4-only solution, I don't have a good answer for you. Deploy v6... yes its very easy to replace every CPE device that every home user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today.
On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said:
Deploy v6... yes its very easy to replace every CPE device that every home user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today.
And if 5 years ago you had *started* distributing CPE that did v6, and by now you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN to fix your Google problem..
On May 21, 2014 4:04 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said:
Deploy v6... yes its very easy to replace every CPE device that every
home
user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today.
And if 5 years ago you had *started* distributing CPE that did v6, and by now you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN to fix your Google problem..
Verizon Wireless is at 50% ipv6 penetration, T-Mobile US and Comcast are closing in on 30% It's a non-trivial number of eyeballs. And, FB, Google / Youtube , and Netflix are all native ipv6 ...its a lot of cotent too. CB
On May 21, 2014 4:17 PM, "Ca By" <cb.list6@gmail.com> wrote:
On May 21, 2014 4:04 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 22 May 2014 09:21:12 +1200, "Tony Wicks" said:
Deploy v6... yes its very easy to replace every CPE device that every
home
user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today.
And if 5 years ago you had *started* distributing CPE that did v6, and by now you had 40% of your customer with CPE that did it, you'd need a 40% smaller CGN to fix your Google problem..
Verizon Wireless is at 50% ipv6 penetration, T-Mobile US and Comcast are closing in on 30%
It's a non-trivial number of eyeballs. And, FB, Google / Youtube , and Netflix are all native ipv6 ...its a lot of cotent too.
CB
Citation http://www.worldipv6launch.org/verizon-wireless-breaks-through-50-ipv6-and-s...
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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. Other folks like bit.ly have briefly toyed with IPv6, and with the helpdesk.test-ipv6.com site, I think things will continue to get better. IPv6 via LTE and handset are the way most of the worlds population will access the internet, not via a computer the way I have been getting "online" for the past few decades. - jared
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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. :-) JL
On May 22, 2014, at 8:04 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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)".
Don't even joke about that, I can't handle another decade of NAT. -- Josh On 5/22/14, 8:55 AM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Thu, May 22, 2014 at 8:41 AM, Jared Mauch <jared@puck.nether.net> wrote:
I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)".
Coke Classic managed to outlast NewCoke... pattern repeating?
On 22May2014Thursday, at 5:55, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, May 22, 2014 at 8:41 AM, Jared Mauch <jared@puck.nether.net> wrote:
I remind vendors when I talk to them, "IPv6 first, then IP classic(tm)".
Coke Classic managed to outlast NewCoke... pattern repeating?
its classic for a reason…. /bill
On 14-05-22 08:55 AM, Christopher Morrow wrote:
Coke Classic managed to outlast NewCoke... pattern repeating? Coke Classic changed as well.
NAT44: the high-fructose corn syrup of IPv4. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael@supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian
On Thursday, May 22, 2014, Jared Mauch <jared@puck.nether.net> wrote:
On May 22, 2014, at 8:04 AM, Livingood, Jason < Jason_Livingood@cable.comcast.com <javascript:;>> wrote:
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net <javascript:;>> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com <javascript:;>> wrote:
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. Isn't your network still offering both as customer choices? :-) Best, -M<
On May 22, 2014, at 9:14 PM, Martin Hannigan <hannigan@gmail.com> wrote:
On Thursday, May 22, 2014, Jared Mauch <jared@puck.nether.net> wrote:
On May 22, 2014, at 8:04 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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
On 23/05/14 11:21, Jared Mauch wrote:
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) I just wish Cisco wouldn't document it as a great IP address to use for your captive portal
On Fri, May 23, 2014 at 1:24 AM, Julien Goodwin <nanog@studio442.com.au> wrote:
On 23/05/14 11:21, Jared Mauch wrote:
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?
On 23 May 2014, at 3:29 pm, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 23, 2014 at 1:24 AM, Julien Goodwin <nanog@studio442.com.au> wrote:
On 23/05/14 11:21, Jared Mauch wrote:
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.
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
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
On Thursday, May 22, 2014, Rubens Kuhl <rubensk@gmail.com> wrote:
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<
On Thursday, May 22, 2014, Martin Hannigan <hannigan@gmail.com> wrote:
On Thursday, May 22, 2014, Rubens Kuhl <rubensk@gmail.com<javascript:_e(%7B%7D,'cvml','rubensk@gmail.com');>> wrote:
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.
And correcting typo. Apologies, slippery thumbs Best, -M<
On 5/22/14 9:41 PM, "Martin Hannigan" <hannigan@gmail.com> wrote:
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'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
On 5/22/14 8:04 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote:
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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. :-)
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
On Thu, May 22, 2014 at 8:49 AM, Lee Howard <Lee@asgard.org> wrote:
On 5/22/14 8:04 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote:
On 5/21/14, 9:38 PM, "Jared Mauch" <jared@puck.nether.net> wrote:
On May 21, 2014, at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
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. :-)
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 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
On May 22, 2014, at 9:18 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Thu, May 22, 2014 at 8:49 AM, Lee Howard <Lee@asgard.org> wrote:
On 5/22/14 8:04 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote: [snip] 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 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
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:~$
On Wed, May 28, 2014 at 3:29 PM, Ryan Rawdon <ryan@u13.net> wrote:
On May 22, 2014, at 9:18 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Thu, May 22, 2014 at 8:49 AM, Lee Howard <Lee@asgard.org> wrote:
On 5/22/14 8:04 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote: [snip]
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 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
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
In message <005701cf753a$97d6e670$c784b350$@wicks.co.nz>, "Tony Wicks" writes:
On May 20, 2014, at 7:21 AM, Pui Edylie <email@edylie.net> wrote:
The absolute best solution is to deploy IPv6 and deprecate NAT. If you're looking for an IPv4-only solution, I don't have a good answer for you.
Deploy v6... yes its very easy to replace every CPE device that every home user has... really ? come on, back in the real world that is just not going to happen until by default every CPE device has the capability as default. Dual stack with CGNAT is the only real solution that works today.
It you have ONE IP, which was what was described by the OP, then upgrade is the solution. Even when you have customer CPE devices deploying IPv6 is still the solution. If you supply the CPE device stop purchasing IPv4 only devices. Only ship IPv6 capable devices. If the customers supply the CPE device tell them you are turning on IPv6 and that they need to purchase a IPv6 capable CPE device to use it with this minimum set of IPv6 features. Give them a list of CPE devices that you have tested. A little communication goes a long way. Every IPv6 CPE deployed reduces the probability that the NAT will be used for a connection. I wish I could get the CPE feature list need for IPv6 from my home ISP. It would save me money buying devices that I will just have to throw out before they die when they finally get around to deploying IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, May 20, 2014 at 7:21 AM, Pui Edylie <email@edylie.net> wrote:
May I know what is the best approach so that Google would not ban our Natted IP from time to time as it suspect it as a bot.
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. While we do everything we can to limit the collateral damage, if your organization has an infected user spewing abuse, you need to take responsibility for your network. IPv6 is the best long-term solution, as this will allow Google's abuse systems to distinguish between your users and block only those violating the ToS. Please give each user a distinct /64 (this seems obvious, but I've seen someone put all their users in the same /96). If you can't deploy IPv6 yet, some other suggestions: - Put your users behind a proxy that adds the X-Forwarded-For header with the user's internal IP. Google's abuse systems use that header to limit blocking when possible. - Review your machines for signs of infection -- many blocks are triggered by botnets that are sending abuse. Another common cause is a browser extension that automatically sends requests. Finally, don't set up monitoring to test whether you're being blocked -- those automated monitoring requests are also a violation of the ToS and only increase the chance of being blocked. - If you have a proxy, test it to ensure it's not an "open" proxy. Open proxies are frequently abused, and will get blocked as a result. - Partitioning users across different IPs can help contain the collateral damage when one user's machine goes rogue. If you load-balance all users across all your IPs then it will likely just result in the entire pool being blocked. Is there any official channel from Google which we could work with them for
resolution?
There's no official channel for working to resolve a blocking issue. Years of experience proves the abuse systems are very accurate (and constantly being improved) -- false positives are extremely rare. Despite this certainty, due to privacy concerns no evidence can be shared back to the ISP to point to the source of abuse. Since nothing can be shared except for times abuse was seen (which is rarely helpful due to lack of logging by the ISP), the response is generally just the suggestions listed above. The blocks will expire on their own once the abuse has been stopped. Damian -- Damian Menscher :: Security Reliability Engineer :: Google
participants (22)
-
Ca By -
Christopher Morrow -
Damian Menscher -
Geoff Huston -
Harald Koch -
Jared Mauch -
Julien Goodwin -
Lee Howard -
Livingood, Jason -
manning -
Mark Andrews -
Martin Hannigan -
Matthew Petach -
Michael Brown -
Owen DeLong -
Pui Edylie -
Rubens Kuhl -
Ryan Rawdon -
Sholes, Joshua -
Tony Wicks -
Valdis.Kletnieks＠vt.edu -
William Waites