Hi All,
I need to stop IPv6 web traffic going from our customers to Google
without touching all other IPv6 and without blackhole IPv6 Google
network (this case my customers are complaining on long timeouts).
What can you advice for that?
On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said:
> I need to stop IPv6 web traffic going from our customers to Google
> without touching all other IPv6 and without blackhole IPv6 Google
> network (this case my customers are complaining on long timeouts).
>
> What can you advice for that?
Umm.
I don't understand the motive here. You want to provide a partial view of the
IPv6 table, but sans Google?
Do you as a network do the same for v4? If not, you really need to consider
having congruent implementations.
- jared
> On Apr 10, 2016, at 9:29 AM, Max Tulyev wrote:
>
> Hi All,
>
>
Customers see timeouts if I blackhole Google network. I looking for
alternatives (other than stop providing IPv6 to customers at all).
On 10.04.16 16:50, valdis.kletni...@vt.edu wrote:
> On Sun, 10 Apr 2016 16:29:39 +0300, Max Tulyev said:
>
>> I need to stop IPv6 web traffic going from our custo
Why do you want to prevent IPv6 access to Google?
What's the point?
On 04/10/2016 04:07 PM, Max Tulyev wrote:
Customers see timeouts if I blackhole Google network. I looking for
alternatives (other than stop providing IPv6 to customers at all).
On 10.04.16 16:50, valdis.kletni...@vt.edu wrote:
On Sun, 10 Apr 2016 17:07:47 +0300, Max Tulyev said:
> Customers see timeouts if I blackhole Google network. I looking for
> alternatives (other than stop providing IPv6 to customers at all).
"Doctor, it hurts when I do this.." "Then don't do that..."
Why are you blackholing Google?
pgpnTylRPm4
I think the group wants to know what problem you're trying to solve. Obviously
if you block something, there will be a timeout in getting to it.
What is broken that you're trying to fix by blackholing them?
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midw
Hello!
Same question from my side. What's original issue with IPv6 and Google?
On Sun, Apr 10, 2016 at 9:11 AM, Filip Hruska wrote:
> Why do you want to prevent IPv6 access to Google?
> What's the point?
>
>
> On 04/10/2016 04:07 PM, Max Tulyev wrote:
>>
>> Customers see timeouts if I blackhole
The problem is IPv6-enabled customers complaints see captcha, and Google
NOC refuses to help solve it saying like find out some of your customer
violating some of our policy. As you can imagine, this is not possible.
So, the working solutions is either correctly cut IPv6 to Google, or cut
all IPv6
He works for cogent :p ?
Regards,
Dovid
-Original Message-
From: Pavel Odintsov
Sender: "NANOG" Date: Sun, 10 Apr 2016 09:18:56
To: Filip Hruska
Cc: nanog@nanog.org
Subject: Re: Stop IPv6 Google traffic
Hello!
Same question from my side. What's original issue with IPv6 and Google?
O
Assign your customers larger v6 prefixes so one customer's bad
behavior doesn't affect the others?
On Sun, Apr 10, 2016 at 05:27:53PM +0300, Max Tulyev wrote:
> The problem is IPv6-enabled customers complaints see captcha, and Google
> NOC refuses to help solve it saying like find out some of your
If I'm not mistaken, when there is some "abuse",
Google typically shows captcha for the single IPs, not for whole
provider, so only the customers who actually do something nefarious
should get flagged.
Also, if you see captcha while using IPv6, switching to IPv4-only won't
solve the problem b
Every have /56 or /48, depending on type of service. All our /32
allocation is affacted.
On 10.04.16 17:35, Chuck Anderson wrote:
> Assign your customers larger v6 prefixes so one customer's bad
> behavior doesn't affect the others?
>
> On Sun, Apr 10, 2016 at 05:27:53PM +0300, Max Tulyev wrote:
* max...@netassist.ua (Max Tulyev) [Sun 10 Apr 2016, 15:30 CEST]:
I need to stop IPv6 web traffic going from our customers to Google
without touching all other IPv6 and without blackhole IPv6 Google
network (this case my customers are complaining on long timeouts).
What can you advice for that?
That is the problem with some of these companies. They've gotten just as cocky
and arrogant as the incumbent telco providers and won't actually tell you what
you're doing wrong, but will punish you for doing wrong.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
On 10 April 2016 at 10:36, Filip Hruska wrote:
> If I'm not mistaken, when there is some "abuse",
> Google typically shows captcha for the single IPs, not for whole provider,
> so only the customers who actually do something nefarious should get
> flagged.
>
You are mistaken. Google flags entire
* na...@ics-il.net (Mike Hammett) [Sun 10 Apr 2016, 16:53 CEST]:
That is the problem with some of these companies. They've gotten
just as cocky and arrogant as the incumbent telco providers and
won't actually tell you what you're doing wrong, but will punish you
for doing wrong.
I'm happy wit
Thank you! I think it is what I need now ;)
On 10.04.16 17:50, Niels Bakker wrote:
> You can add a reject route at your borders rather than nullroute. That
> will cause ICMP Unreachables to be sent by your routers back to your
> customers so their applications will know immediately to retry using
That was another Google reply, but all /32 still affected. IPv4 is not
affected (at least no complaints), so...
On 10.04.16 17:36, Filip Hruska wrote:
> If I'm not mistaken, when there is some "abuse",
> Google typically shows captcha for the single IPs, not for whole
> provider, so only the custo
Hi,
> The problem is IPv6-enabled customers complaints see captcha, and Google
> NOC refuses to help solve it saying like find out some of your customer
> violating some of our policy. As you can imagine, this is not possible.
your customers are getting addresses when looking up google addres
That's the problem. Nobody want to say which customer (IP) violates
which policy.
On 10.04.16 18:31, a.l.m.bu...@lboro.ac.uk wrote:
> give clients their own bigger blocks - or identify the clients violating
> policy (what the policy
> they are violating?) - you'll probably find the ones getting t
(Sorry about formatting - posting on my phone)
Other things might need to make sure of is reverse DNS to differentiate between
customers if at all possible, accurate Whois and separate Whois records for
static assigned blocks, etc.
No guarantees of a fix, but general good practices when this st
Sorry to hear your legitimate users are impacted by captchas when trying to
use Google web search. This can happen when you have significant amounts
of abuse coming from your network. If switching to IPv4 means having more
users share IPs, it could make the problem worse. Instead, let's try to
q
Ya know, this is the problem with this kind of list groupthink.
Who cares what his motivations are unless he asks for help with that
underlying problem?
Do you (plural, whoever is replying) know the answer to his question
or where to find the answer or not?
It seems like every technical list
On the flip side of things instead of putting a bandaid on the burn it is
better to stop putting your hand in the fire. Nothing wrong with some
discussion.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Sun, Apr 10, 2016 at 3:33 PM, wrote:
>
On 10 April 2016 at 21:33, wrote:
>
>
>
> Ya know, this is the problem with this kind of list groupthink.
>
> Who cares what his motivations are unless he asks for help with that
> underlying problem?
>
But you are clearly wrong. Because he got asked and then told us what the
underlying problem
On Sun, 10 Apr 2016 15:33:43 -0400, b...@theworld.com said:
>
>
>
> Ya know, this is the problem with this kind of list groupthink.
>
> Who cares what his motivations are unless he asks for help with that
> underlying problem?
Because when people apply band-aid solutions rather than fixing the *r
I don't think it's "groupthink" so much as it is "the mark of
experienced tech people who are good at their job".
At $DAYJOB, a HUGE part of my time is spent as a "technical firewall" --
stopping the company from blindly implementing something based on
incomplete information. When someone com
On Sun, 10 Apr 2016, Max Tulyev wrote:
Hi All,
I need to stop IPv6 web traffic going from our customers to Google
without touching all other IPv6 and without blackhole IPv6 Google
network (this case my customers are complaining on long timeouts).
What can you advice for that?
Just use Cogent
On Sun, Apr 10, 2016 at 10:29 AM, Max Tulyev wrote:
> Hi All,
>
> I need to stop IPv6 web traffic going from our customers to Google
> without touching all other IPv6 and without blackhole IPv6 Google
> network (this case my customers are complaining on long timeouts).
>
> What can you advice for
30 matches
Mail list logo
