Categories
IPv6

Verizon Refuses to Provide Complete IPv6

UPDATE: Verizon Post-Slashdot Followup

The final word on Friday from Verizon is that they refuse to carry 29% of the IPv6 internet that is visible from their competitors. We calculated this percentage by taking the total number of paths Verizon provides and dividing it by the number of visible endpoints through Sprint and Hurricane Electric.

Specifically, they are completely blocking all of ARIN’s 2620:0::/23, so even by following their policies they’re still providing an incomplete view of the internet. It is their position that this is “correct”:

“If you wish your /48 to be visible globally, you’ll need to return your direct /48 allocation to ARIN and obtain a Verizon /48 from our network pool. Since our /48 assignment would be part of a /32 that we are announcing, your network would be globally routable. Otherwise, you are limited to AS701.”

Our response was:

Basically it seems to come down to 701 is a black hole for ARIN’s 2620:0::/23 (/40-/48) assignments. Let’s ignore my initial problem for a minute. Even if I were to switch to a /48 contained in your /32 or get my own /32, the following routes are still not available via 701:

Network          Next Hop
*>i2620:0:30::/48   2620:0:950::242:129
*>i2620:0:70::/48   2620:0:950::242:129
*>i2620:0:80::/48   2620:0:950::242:129
*>i2620:0:90::/48   2620:0:950::242:129
*>i2620:0:B0::/48   2620:0:950::242:129
*>i2620:0:C0::/48   2620:0:950::242:129
*>i2620:0:110::/48  2620:0:950::242:129
*>i2620:0:140::/48  2620:0:950::242:129
*>i2620:0:150::/48  2620:0:950::242:129
*>i2620:0:230::/48  2620:0:950::242:129
*>i2620:0:240::/48  2620:0:950::242:129
*>i2620:0:280::/48  2620:0:950::242:129
*>i2620:0:2D0::/48  2620:0:950::242:129
*>i2620:0:310::/48  2620:0:950::242:129
*>i2620:0:320::/48  2620:0:950::242:129
*>i2620:0:330::/48  2620:0:950::242:129
*>i2620:0:380::/48  2620:0:950::242:129
*>i2620:0:380:2::/64
2620:0:950::242:128
*>i2620:0:3F0::/48  2620:0:950::242:129
*>i2620:0:630::/48  2620:0:950::242:129
*>i2620:0:6B0::/48  2620:0:950::242:129
*>i2620:0:6C0::/48  2620:0:950::242:129
*>i2620:0:6C1::/48  2620:0:950::242:129
*>i2620:0:6C2::/48  2620:0:950::242:129
*>i2620:0:800::/47  2620:0:950::242:129
*>i2620:0:802::/48  2620:0:950::242:129
*>i2620:0:830::/48  2620:0:950::242:129
*>i2620:0:860::/46  2620:0:950::242:129
*>i2620:0:862::/48  2620:0:950::242:129
*>i2620:0:870::/48  2620:0:950::242:129
*>i2620:0:880::/48  2620:0:950::242:129
*>i2620:0:8F0::/48  2620:0:950::242:129
*>i2620:0:930::/48  2620:0:950::242:129
*>i2620:0:950::/48  2620:0:950::242:130
*>i2620:0:960::/48  2620:0:950::242:129
*>i2620:0:9B0::/48  2620:0:950::242:129
*>i2620:0:9C0::/48  2620:0:950::242:129
*>i2620:0:A00::/48  2620:0:950::242:129
*>i2620:0:A00::/43  2620:0:950::242:129
*>i2620:0:A01::/48  2620:0:950::242:129
*>i2620:0:A02::/48  2620:0:950::242:129
*>i2620:0:A03::/48  2620:0:950::242:129
*>i2620:0:A04::/48  2620:0:950::242:129
*>i2620:0:A05::/48  2620:0:950::242:129
*>i2620:0:A06::/48  2620:0:950::242:129
*>i2620:0:A07::/48  2620:0:950::242:129
*>i2620:0:A09::/48  2620:0:950::242:129
*>i2620:0:A0D::/48  2620:0:950::242:129
*>i2620:0:A10::/48  2620:0:950::242:129
*>i2620:0:A16::/48  2620:0:950::242:129
*>i2620:0:A17::/48  2620:0:950::242:129
*>i2620:0:A1A::/48  2620:0:950::242:129
*>i2620:0:A1C::/48  2620:0:950::242:129
*>i2620:0:A1D::/48  2620:0:950::242:129
*>i2620:0:A1E::/48  2620:0:950::242:129
*>i2620:0:A1F::/48  2620:0:950::242:129
*>i2620:0:B10::/46  2620:0:950::242:129
*>i2620:0:B60::/48  2620:0:950::242:129
*>i2620:0:C30::/48  2620:0:950::242:129
*>i2620:0:C80::/48  2620:0:950::242:129
*>i2620:0:CA0::/48  2620:0:950::242:129
*>i2620:0:CC0::/47  2620:0:950::242:129
*>i2620:0:CC0::/44  2620:0:950::242:129
*>i2620:0:CCA::/48  2620:0:950::242:129
*>i2620:0:CCB::/48  2620:0:950::242:129
*>i2620:0:CCC::/48  2620:0:950::242:129
*>i2620:0:CCD::/48  2620:0:950::242:129
*>i2620:0:CCF::/48  2620:0:950::242:129
*>i2620:0:CF0::/48  2620:0:950::242:129
*>i2620:0:D20::/48  2620:0:950::242:129
*>i2620:0:D60::/46  2620:0:950::242:129
*>i2620:0:DA0::/48  2620:0:950::242:129
*>i2620:0:DC0::/48  2620:0:950::242:129
*>i2620:0:DD0::/48  2620:0:950::242:129
*>i2620:0:DF0::/48  2620:0:950::242:129
*>i2620:0:E50::/48  2620:0:950::242:129
*>i2620:0:EF0::/48  2620:0:950::242:129
*>i2620:0:1000::/48 2620:0:950::242:129
*>i2620:0:1002::/48 2620:0:950::242:129
*>i2620:0:101E::/48 2620:0:950::242:129
*>i2620:0:1040::/48 2620:0:950::242:129
*>i2620:0:105D::/48 2620:0:950::242:129
*>i2620:0:105E::/48 2620:0:950::242:129
*>i2620:0:105F::/48 2620:0:950::242:129
*>i2620:0:1080::/48 2620:0:950::242:129
*>i2620:0:10A0::/48 2620:0:950::242:129
*>i2620:0:10A1::/48 2620:0:950::242:129
*>i2620:0:1700::/45 2620:0:950::242:129
*>i2620:0:1A10::/48 2620:0:950::242:129
*>i2620:0:1A50::/48 2620:0:950::242:129
*>i2620:0:1B00::/48 2620:0:950::242:129
*>i2620:0:2220::/48 2620:0:950::242:129
*>i2620:0:22F0::/48 2620:0:950::242:129
*>i2620:0:2830::/48 2620:0:950::242:129
*>i2620:0:2860::/48 2620:0:950::242:129
*>i2620:0:2890::/48 2620:0:950::242:129
*>i2620:0:2B10::/48 2620:0:950::242:129

That’s not exactly something to brush off (ignoring the random /64); that’s a big enough chunk missing to make 701 look undesirable to someone like me who wants to heavily promote IPv6. Compared to my existing IPv6 table, 701 is missing 29% of the IPv6 internet that I can already reach.

And based on their position, they’re probably (although we have not confirmed, but based on the 29% figure we came up with it is extremely likely) missing similar ranges from the other regional registries.

18 replies on “Verizon Refuses to Provide Complete IPv6”

That’s horrible and unacceptable in my opinion for a carrier of this size. Me thinks this has a lot to more do with peering and transit agreements though under the hood.

Anyways, useful information and I thank you for it.

Note that the song/dance about the sales/install crew knowing nothing of IPv6 is not uncommon in 701-land. Additionally, the song/dance of sales-staff ‘no longer at the company’ is not a new problem, turnover in sales (everywhere) is horrendously high.

Good luck with the ipv6 install and ipv6 routing issues, out of curiousity what’s your path to ipv6.google.com look like? (I bet it’s via frankfurt).

BGP routing table entry for 2001:4860::/32, version 37547
Paths: (2 available, best #1, table Default)
Not advertised to any peer
6175 15169, (aggregated by 15169 209.85.255.203), (received & used)
2620:0:950::242:129 (metric 2) from 2620:0:950::242:130 (208.79.242.130)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 208.79.242.129, Cluster list: 208.79.242.130

701 12702 286 15169, (aggregated by 15169 209.85.255.169), (received & used)
2600:80A:60F::1 (FE80::219:E8FF:FEFB:4502) from 2600:80A:60F::1 (137.39.5.20)
Origin IGP, localpref 80, valid, external
Community: 701:333 701:1020

Sprint: direct. Verizon: loooooong.

By Post Author

Verizon’s policy is that they will not advertise nor listen to any prefix advertisements at their peering points below /32. This is the equivalent of back when Sprint and Verio wouldn’t route below /20 back in the 90s, a position they were eventually forced to abandon due to market pressure. History repeats itself.

I have Verizon as one of my upstream carriers; for this reason we won’t be turning up an IPv6 peer with them until they abandon this policy. All our other carriers that support IPv6 are fine with routing below /32.

Why do you care if it is IP v6 in the first place? Just seems odd. Does ipv6 deliver something that v4 doesn’t in you situation?

If you have signed contracts with IPv6 specs, even fine print, that is in your favor in this case, you should really look into changing provider.

Evidently they aren’t doing IPv6 right and if that is something you and your customers require you should shop it from better providers with better clue.

The most clear method to communicate your dissatisfaction with them is simply to not be their customer. This is the best ways to improve the IPv6 global routing state, by rewarding clue, punishing and most importantly not accepting stoopidness.

My remarks are obvious but stating it clearly shouldn’t hurt…

Awesome! I was allocated something out of this /23. Can’t wait for the reachability problems.

Interestingly, since you posted this, one of those entries should now be reachable for you from VBS. We just turned up 2620:0:280::/48 with VBS late last week as well.

I have a ticket open with them about our /48 not being available at *any* of the public IPv6 looking glasses.

So, they are hearing about this problem (and it is very clearly a problem) from multiple customers.

Unfortunately we’re not seeing it on our Verizon border router with the routes we are receiving from them. We’re announcing 2620:0:950::/48 as of last Friday. They must be filtering it internally as well and not just external peers. We’ll send you BGP details via email.

By Post Author

Just got confirmation from Verizon tech support that their policy is to not accept advertisements of prefixes longer than /32 *at all*, even for traffic between two transit customers of Verizon itself.

Now I guess I have to decide whether to turn by BGP peering for IPv6 back down or not. :/

They basically don’t want to provision the ARIN-allocated hole into their network. I agree that if thousands of customers allocated their blocks from ARIN but wanted access to the global IPv6 internet through Verizon’s 701, then that might create a scaling problem for Verizon’s “existing” v6 routing deployment.

That would leave you with 3 options:

1. Go with another carrier that WILL route your ARIN-allocated block
2. Return your block and get a Verizon block (sounds like what Verizon wants you to do)
3. Somehow arrange for a “tier-1” connection to the core IPv6 routers (like Verizon did) and handle
BGP routes yourself.

Randy

Comments are closed.