Google Blocking IPv6 Adoption With Cogent, Impacting Transit Customers

Over the past few weeks, complaints related to IPv6 connectivity between Cogent and Google have increased, with the dispute now being made public. While reading through some NANOG emails, and my further dialog with other NANOG list readers, it appears that Google may be selectively blocking IPv6 routes through their transit providers. Initially some thought it was an error, but it now appears to be engineered this way. Here is how Google officially responded to the issue through a NANOG list member:

*From Google (re: Cogent): Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.

Cogent is technically a Tier 1 backbone provider and has (or should have) a full Internet routing table. If they do not have the IPv6 routes from Google, then something, or someone is specifically blocking that connectivity. Google goes on to say:

*Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren’t able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.

Technically since Google uses transit to reach Cogent through one of Cogent’s peers, Google is accountable for this connectivity and appears to have purposely blocked it. So the questions to ask is, why? Possibly to motivate Cogent “to look for alternatives to interconnect”. In other words, Google creates an IPv6 blocking situation to welcome Cogent into giving settlement free peering to Google. Google has always paid for some transit in the past and appears to have created this IPv6 outage in order to change their existing business relationships.

Cogent historically has been the “poster child” around peering disputes and it is important to understand their side of this which is described in this next email that was also forwarded to the NANOG mailing list:

*Dear Cogent Customer, Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach. Google uses transit providers to announce their IPv4 routes to Cogent. At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers. We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.

Regardless of what one may think of Cogent’s peering dispute history (and perhaps the bad boy reputation played into a who’s-to-blame strategy), this actually follows the hypothesis that Google was the original instigator in the IPv6 blocking and appears to have created this problem to order to coerce a financially beneficial solution – for Google. As multiple Cogent customers told me via email, the situation is unfortunate for them because in certain locations, there aren’t any other providers to pick from. Cogent has had the same peering dispute with HE for many years, but HE is a lot less visible in the daily life of the average user than Google.

It’s hard to know for sure who is at fault without all the details. The problem creator (Google) or the network provider with a peering dispute reputation (Cogent). However, as IPv6 traffic grows, this strategy of IP blocking could cause negative impact and outages with customers and slow the adoption of IPv6. And, this Google event should come to the surprise of Google’s Chief Internet Evangelist, Vint Cerf who has been very vocal about promoting the future of the Internet over IPv6.

Given the migration to IPv6, some networks have more IPv6 Google traffic than IPv4. And as IPv6 takes a larger role in the Internet these “peering playbook” tactics could have consumer impact along with IPv6 adoption impact. If not properly managed with DNS, this could cause customer impact if quad-A records are preferred and unreachable. When a non-Tier 1 blocks part of their routing table from their Transit provider, they are not carrying a full Internet routing table and preventing consumers from getting to Google services over IPv6.

Of course, if Comcast, Verizon or one of the ISP was using this IPv6 tactic to their benefit, Internet advocacy groups and the media would be calling for their heads. Yet no one seems to have noticed what Google is doing, and is complaining about it, other than Cogent’s customers being impacted by Google’s tactics. So the question people should now be asking is, “Who is blocking IPv6 routes and why?”

  • cyberdiq

    We’ve definitely noticed. We do daily uploads to Google Cloud storage, with multipath AS balancing of their IPv4 and IPv6 routes. Suddenly, the traffic shifted from equal multipath (50% Cogent, 50% XO) to 100% XO. What does this mean? It means now Cogent gets $0 and XO gets a boatload more. This is definitely going to hurt Cogent’s bottom line. Who’s right and who’s wrong isn’t going to matter to customers. Cogent is going to blink first and give Google whatever they’re asking. They can’t afford not to.

    It’s even busted on the IPv4 side. On IPv6 they’re using Verizon to reach Google Cloud API’s. On IPv4, they’re using Tata. Either way it’s 1 AS longer path than any other transit Tier 1 provider out there. With a default setup multihomed setup, no one will choose the Cogent path for Google Cloud.

    I feel for the single homed Cogent customers, but it’s probably time that they voted with their wallets and went elsewhere.

    • holmessph

      It’s sad that it’s been 9 months and this is still a subject that we’re talking about. We’re a brand new built cloud data center, we have Cogent as one of the few options that are multi-homed. I hope that they figure something out soon, because Google and HE peers are bound to be a significant amount of traffic on our network.