Stop IPv6 Google traffic
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.. fix the reasons why they're seeing timeouts? :) Have you determined why the timeouts are happening?
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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 <fhr@fhrnet.eu> 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 Google network. I looking for alternatives (other than stop providing IPv6 to customers at all).
On 10.04.16 16:50, Valdis.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
-- Sincerely yours, Pavel Odintsov
He works for cogent :p ? Regards, Dovid -----Original Message----- From: Pavel Odintsov <pavel.odintsov@gmail.com> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Sun, 10 Apr 2016 09:18:56 To: Filip Hruska<fhr@fhrnet.eu> Cc: nanog@nanog.org<nanog@nanog.org> Subject: Re: Stop IPv6 Google traffic 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 <fhr@fhrnet.eu> 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 Google network. I looking for alternatives (other than stop providing IPv6 to customers at all).
On 10.04.16 16:50, Valdis.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
-- Sincerely yours, Pavel Odintsov
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 Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic 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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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 (which I don't want to do). On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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 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 (which I don't want to do).
On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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:
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 (which I don't want to do).
On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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 quickly address the IPv6 issue. Please send me your IP allocation policy (off-list is fine). For example (guessing from the list at http://bgp.he.net/search?search%5Bsearch%5D=netassist&commit=Search): - 2a01:d0::/32 is allocated by /48 - 2a01:d0:8000::/33 is allocated by /56 - 2001:67c:1874::/48 is allocated by /64 - ... etc (IPv4 allocation is appreciated as well, if you also provide customers with large ranges there) I can then give that hint to our automated abuse systems, which will both make it easier for us to catch your abusive customers, and also to avoid over-blocking of your AS. Damian -- Damian Menscher :: Security Reliability Engineer :: Google :: AS15169 On Sun, Apr 10, 2016 at 7:46 AM, Max Tulyev <maxtul@netassist.ua> wrote:
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:
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 (which I don't want to do).
On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
On Sun, 10 Apr 2016, Damian Menscher via NANOG wrote:
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 quickly address the IPv6 issue.
Please send me your IP allocation policy (off-list is fine). For example (guessing from the list at http://bgp.he.net/search?search%5Bsearch%5D=netassist&commit=Search):
- 2a01:d0::/32 is allocated by /48 - 2a01:d0:8000::/33 is allocated by /56 - 2001:67c:1874::/48 is allocated by /64 - ... etc (IPv4 allocation is appreciated as well, if you also provide customers with large ranges there)
I can then give that hint to our automated abuse systems, which will both make it easier for us to catch your abusive customers, and also to avoid over-blocking of your AS.
Hi, just curious. Do you support the RIPE object called "assignment-size" automatically? https://apps.db.ripe.net/search/lookup.html?source=ripe&key=2001%3A980%3A3000%3A%3A/36&type=inet6num for instance, indicates that each customer in this /36 is a /48. Do you pick this up automatically and hint your abuse system about this? Does it send automatically generated abuse reports to the abuse contact as well? -- Mikael Abrahamsson email: swmike@swm.pp.se
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 because if there really is abuse, Google will flag the IPs regardless of IP protocol version. On 04/10/2016 04:27 PM, 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 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 (which I don't want to do).
On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
On 10 April 2016 at 10:36, Filip Hruska <fhr@fhrnet.eu> 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 netblocks, more so for IPv6 it seems.
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 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 because if there really is abuse, Google will flag the IPs regardless of IP protocol version.
On 04/10/2016 04:27 PM, 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 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 (which I don't want to do).
On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
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 Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:27:53 AM Subject: Re: Stop IPv6 Google traffic 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 (which I don't want to do). On 10.04.16 17:17, Mike Hammett wrote:
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
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Max Tulyev" <maxtul@netassist.ua> To: nanog@nanog.org Sent: Sunday, April 10, 2016 9:07:47 AM Subject: Re: Stop IPv6 Google traffic
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.Kletnieks@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 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.. fix the reasons why they're seeing timeouts? :)
Have you determined why the timeouts are happening?
* nanog@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 with them not sharing what exactly other people are doing online when quizzed. -- Niels.
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 AAAA addresses when looking up google addresses...so their clients are trying to use IPv6 to talk to google..... so doing anything to that traffic - blackholing or just denying it, WILL affect the clients. 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 the captchas are the ones violating! ;-) alan
That's the problem. Nobody want to say which customer (IP) violates which policy. On 10.04.16 18:31, A.L.M.Buxey@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 the captchas are the ones violating! ;-)
(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 stuff comes up. Sent from my iPhone
On Apr 10, 2016, at 9:31 AM, A.L.M.Buxey@lboro.ac.uk wrote:
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 AAAA addresses when looking up google addresses...so their clients are trying to use IPv6 to talk to google..... so doing anything to that traffic - blackholing or just denying it, WILL affect the clients.
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 the captchas are the ones violating! ;-)
alan
<RANT level=MINOR> 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 is over-run with meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?! Often in a sort of accusatory tone, only someone dumb would want to (blah)! I think the answer is to disable IPv6 in the web server config or startup (see flags) but hey I just thought I would meta the meta. Sorry but I went through about an hour of looking for some way to trace systemd and all I found on various lists in answer to others asking the same thing was why would you want to trace systemd? Is this a standard package causing problems if not then use the standard package and if there is none then don't use that software (wow what a good answer...not), or a lot of "it must just be something simple you don't need to trace anything" (which was probably true but kind of useless.) </RANT> -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
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, <bzs@theworld.com> wrote:
<RANT level=MINOR>
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 is over-run with meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?!
Often in a sort of accusatory tone, only someone dumb would want to (blah)!
I think the answer is to disable IPv6 in the web server config or startup (see flags) but hey I just thought I would meta the meta.
Sorry but I went through about an hour of looking for some way to trace systemd and all I found on various lists in answer to others asking the same thing was why would you want to trace systemd? Is this a standard package causing problems if not then use the standard package and if there is none then don't use that software (wow what a good answer...not), or a lot of "it must just be something simple you don't need to trace anything" (which was probably true but kind of useless.)
</RANT>
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 10 April 2016 at 21:33, <bzs@theworld.com> wrote:
<RANT level=MINOR>
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 was, he got in touch with the correct guy at Google that will now fix his problem the right way. Your way everyone would have ended up in a worse shape. Also we are not just here to show of our vast knowledge, but to learn. Some of us would want to know why one would want to disable IPv6 for Google. Maybe our own network has the same issues. And I for one would not want the "block Google" solution. We already registered our customer allocation size of /48 in the RIPE database, so I hope Google will pick that up automatically. Regards, Baldur
On Sun, 10 Apr 2016 15:33:43 -0400, bzs@theworld.com said:
<RANT level=MINOR>
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 *real* problem, it usually ends up making other people's phones ring. You've been around long enough to remember the hassles when ECN started showing up in gear. Who got the phone calls, the owner of the firewall that didn't know about ECN, or the provider where the ECN originated? Repeat the discussion for PMTU discovery. And for a *lot* of other instances. And then there's the other elephant in the room - if Google is throwing back captchas because it thinks there's a problem, the original poster's abuse desk may want to deal with the underlying issue. Maybe his network has real abuse problems they should deal with, maybe he's just got a wonky configuration that makes it *look* like he has a problem. I have no clue which - but it's a fair bet that if Google *thinks* there's an issue, the original poster needs to fix the *real* problem, or they will be stuck playing whack-a-mole with other sites that draw the same conclusions as Google did.
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 comes to me and says "I need to do $X in the dev/QA/prod environment", my first question is "What are you trying to accomplish?" A good percentage of the time, it turns out that Group A didn't talk to Group B, and the requirements were misunderstood -- after discussion, we end up NOT implenting their original request, and either implement it in a different way, implement a solution to a completely different problem, or do nothing at all. All of the really good technical people I know have learned to do this through experience, and the habit of asking "What are you REALLY trying to do here?" is ingrained in their response to any question. The only thing worse than a half-baked question is running full tilt into a wall with a half-baked solution to a half-baked question. - Peter On 4/10/2016 3:33 PM, bzs@theworld.com wrote:
<RANT level=MINOR>
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 is over-run with meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?!
Often in a sort of accusatory tone, only someone dumb would want to (blah)!
I think the answer is to disable IPv6 in the web server config or startup (see flags) but hey I just thought I would meta the meta.
Sorry but I went through about an hour of looking for some way to trace systemd and all I found on various lists in answer to others asking the same thing was why would you want to trace systemd? Is this a standard package causing problems if not then use the standard package and if there is none then don't use that software (wow what a good answer...not), or a lot of "it must just be something simple you don't need to trace anything" (which was probably true but kind of useless.)
</RANT>
bzs@theworld.com writes:
It seems like every technical list is over-run with meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?!
It is reasonable to expect anyone asking for help to describe the process leading up to the situation where they are stuck. I'd say it is rare that such an explanation can be given without describing the original problem. If you are worrying about these meta discussions, then I'd suggest killng them off in the first place by simply answering the questions before they are asked. Bjørn
On 10 April 2016 at 12:33, <bzs@theworld.com> wrote:
Who cares what his motivations are unless he asks for help with that underlying problem?
See Also: http://xyproblem.info/ -- Eitan Adler
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 <maxtul@netassist.ua> 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?
* maxtul@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?
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 IPv4 rather than waiting for TCP timeouts. Alternatively, you could ask Google to exempt your nameservers from being responded to with AAAA records - something that may happen automatically if v6 connectivity is bad. -- Niels.
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 IPv4 rather than waiting for TCP timeouts.
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 transit for IPv6. Problem solved. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 10 April 2016 at 14:48, Jon Lewis <jlewis@lewis.org> wrote:
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 transit for IPv6. Problem solved. :)
Unless Cogent is doing something different for Google than HE does for Cogent, using Cogent is unlikely to solve the timeout issues: % telnet -6 www.cogentco.com 80 Trying 2001:550:1::cc01... ^C % As has already been pointed out, the proper half-baked solution is to return a destination unreachable packet in these situations, instead of silently dropping the packets and forcing the clients to go through a timeout. Cheers, Constantine.SU.
On Sun, Apr 10, 2016 at 10:29 AM, Max Tulyev <maxtul@netassist.ua> 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?
If your users are seeing captchas, one or a few or them are likely to be infected to the point of generating too much requests to Google. Flow-based analysis might reveal who those users are. Rubens
On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl <rubensk@gmail.com> wrote:
If your users are seeing captchas, one or a few or them are likely to be infected to the point of generating too much requests to Google.
If that were the case, they'd be seeing the same via IPv4. And apparently, they aren't. This also points out the problems with *ASSUMING* you know the size of someone's netblock. If you think "/64", then you'd be wrong. Just as wrong as assuming all IPv4 is "/24". And on the same side of that coin is the over-reaching "block all of Asia" blacklist. Sure, that'll kill a heap of nonsense, but if you actually have business in Asia... (Yes, *I* banish APNIC. "works for me", not recommended for others.)
On Mon, Apr 11, 2016 at 5:56 PM, Ricky Beam <jfbeam@gmail.com> wrote:
On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl <rubensk@gmail.com> wrote:
If your users are seeing captchas, one or a few or them are likely to be infected to the point of generating too much requests to Google.
If that were the case, they'd be seeing the same via IPv4. And apparently, they aren't.
Nope. If you have both A and AAAA IP addresses in DNS responses and have both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit of latency handicap favoring IPv6 in current Happy Eyeballs implementations. Remember that the symptom is not unresponsive website, but an answer with an inconvenience (the captcha), so the browser and the network stack won't deem it as IPv6 load failure.
This also points out the problems with *ASSUMING* you know the size of someone's netblock. If you think "/64", then you'd be wrong. Just as wrong as assuming all IPv4 is "/24". And on the same side of that coin is the over-reaching "block all of Asia" blacklist. Sure, that'll kill a heap of nonsense, but if you actually have business in Asia...
(Yes, *I* banish APNIC. "works for me", not recommended for others.)
One known issue in both APNIC and LACNIC regions is that some addresses are indeed countries instead of single networks, due to NIRs (National Internet Registries). Rubens
On Mon, 11 Apr 2016 17:03:02 -0400, Rubens Kuhl <rubensk@gmail.com> wrote:
If that were the case, they'd be seeing the same via IPv4. And apparently, they aren't.
Nope. If you have both A and AAAA IP addresses in DNS responses and have both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit
You misunderstood. If they disable IPv6, then their "attacks" would continue via IPv4, thus getting IPv4 similarly blacklisted. This is not happening -- hence the plan of blocking IPv6. While it's possible there's some IPv6 specific "spambot" (adbot, whatever) running, I doubt it.
On Apr 11, 2016, at 14:03 , Rubens Kuhl <rubensk@gmail.com> wrote:
On Mon, Apr 11, 2016 at 5:56 PM, Ricky Beam <jfbeam@gmail.com> wrote:
On Sun, 10 Apr 2016 20:09:04 -0400, Rubens Kuhl <rubensk@gmail.com> wrote:
If your users are seeing captchas, one or a few or them are likely to be infected to the point of generating too much requests to Google.
If that were the case, they'd be seeing the same via IPv4. And apparently, they aren't.
Nope. If you have both A and AAAA IP addresses in DNS responses and have both IPv4 and IPv6 connectivity, IPv6 will be preferred, with even a bit of latency handicap favoring IPv6 in current Happy Eyeballs implementations. Remember that the symptom is not unresponsive website, but an answer with an inconvenience (the captcha), so the browser and the network stack won't deem it as IPv6 load failure.
Also, incorrect or non-existant PTR records are much more common in IPv6 than in IPv4, so that could also account for some difference in behavior. Most res.ISPs, for example, synthesize PTR responses for their IPv4 addresses such as: 240.59.103.76.in-addr.arpa. 7200 IN PTR c-76-103-59-240.hsd1.ca.comcast.net. vs. ; <<>> DiG 9.8.3-P1 <<>> -x 2601:1c1:1234:5678:b834:f36d:2bb9:285 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48639 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.8.2.0.9.b.b.2.d.6.3.f.4.3.8.b.8.7.6.5.4.3.2.1.1.c.1.0.1.0.6.2.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 0.1.0.6.2.ip6.arpa. 3600 IN SOA dns101.comcast.net. dnsmaster.comcastonline.com. 2014093006 7200 300 604800 3600 ;; Query time: 128 msec ;; SERVER: 172.22.186.6#53(172.22.186.6) ;; WHEN: Mon Apr 11 14:43:53 2016 ;; MSG SIZE rcvd: 171 for example. Owen
participants (25)
-
A.L.M.Buxey＠lboro.ac.uk -
Baldur Norddahl -
Bjørn Mork -
Brielle -
bzs＠theworld.com -
Chuck Anderson -
Constantine A. Murenin -
Damian Menscher -
Dovid Bender -
Eitan Adler -
Filip Hruska -
Harald Koch -
Jared Mauch -
Jon Lewis -
Josh Luthman -
Max Tulyev -
Mikael Abrahamsson -
Mike Hammett -
Niels Bakker -
Owen DeLong -
Pavel Odintsov -
Peter Kristolaitis -
Ricky Beam -
Rubens Kuhl -
Valdis.Kletnieks＠vt.edu