NAT IP and Google

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

IPv6?

Might help if all your hosts have their own IPv6 addresses - doesn't help
if you run an http proxy. Google blacklists my (personal) IPv6 proxy at
least once a month.

Might help if all your hosts have their own IPv6 addresses

That was meant to be implied... But...

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

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

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.

The system is fully automated, and if you carefully follow instructions, life will be wonderful and nothing can possibly go wron<click>and nothing can possibly go wron<click>and nothing can possibly go wron<click>and nothing can possibly go wron<click>and nothing can possibly go wron.....

Sorry. Having a bad day dealing with heinous telephone robots and unspeakably bad web pages.

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..

> 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

>
>
> > 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-still-climbing/

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

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

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

+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. :slight_smile:

JL

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)".

Coke Classic managed to outlast NewCoke... pattern repeating?

Don't even joke about that, I can't handle another decade of NAT.

its classic for a reason….

/bill