IPv6

That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
So cogent IPv6 Customers currently can not hit things at HE. And they can't
do anything about it. Besides 6to4 tunneling and BGP peering with HE (or
native, If they can).

Nick Olsen
Network Operations
(855) FLSPEED x106

That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
So cogent IPv6 Customers currently can not hit things at HE. And they can't
do anything about it. Besides 6to4 tunneling and BGP peering with HE (or
native, If they can).

Wait, a settlement free carrier with less than total reachability?

that never happens, er yeah it does...

I'd get two.

joel

Another option is a static BGP tunnel with HE which can be configured
at http://tunnelbroker.net. It's not ideal and only useful for relatively low
bandwidth. If your needs are greater, we would much rather sell
you transit or peer with you as appropriate. As everyone should know
by now, we have an aggressively open peering policy.

Feel free to direct questions to me off list or to peering@he.net
if you have a peering request.

Owen

Hello,

I second that, we're only getting ~2665 IPv6 prefixes from Cogent compared to the ~3650 from our other transits. (been like that for more then a year now)

Cogent's stance on it is 'You're multihomed with other transits, so you're still reachable anyways' which strikes me as very odd for someone who's supposed to be selling global transit.
They once called me asking about how satisfied we were with their IPv6 transit, but quickly ended the conversation once I asked about the incomplete feed and the HE peering refusal.

Personally we don't see Cogent as a serious transit provider for IPv6 and have their v6 prefixes set with a very low priority.

> That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
> So cogent IPv6 Customers currently can not hit things at HE. And they can't
> do anything about it. Besides 6to4 tunneling and BGP peering with HE (or
> native, If they can).

A few weeks ago I compared what cogent sees compared to a tata+highwinds feed.

http://blog.snijders-it.nl/2010/10/cogent-as174-does-not-have-full-ipv6.html

They are missing roughly 1000 prefixes.

As long as we are in public "naming and shaming" mode, it should be noted
that Cogent is not alone. We have an IPv4/IPv6 transit from Level3, and
they don't have the HE prefixes either.

Our two other IPv4/IPv6 transits seem to have no problem supplying us with
a full IPv6 routing table.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Job Snijders wrote:

They are missing roughly 1000 prefixes.

See http://www.sixxs.net/tools/grh/status/

which just now when I peeked stated at the top:
8<-------------------------------------
2704 good/required prefixes
Minimum of 1714 prefixes (-990)
Average of 3513 prefixes (+809)
Maximum of 3861 prefixes (+1157)
186 peers, 67 not connected
------------------------------------->8

As such, a proper transit should be delivering you with 2704 prefixes
for it to make you able to reach every place that should be reachable.

Some organisations send upwards of 1157 *MORE* prefixes than necessary,
note that is almost 30% more, thus junk prefixes which you don't need,
guess where a lot of those junk prefixes come from...

GRH doesn't have data on Cogent unfortunately (maybe check RIS?).

L(3) at the moment misses 632 prefixes that they should have:
http://www.sixxs.net/tools/grh/dfp/all/?missing=3356

For everyone's 'but another "transit" has more prefixes excuse, they
don't get all the prefixes either, they are missing 178 of them:
http://www.sixxs.net/tools/grh/dfp/all/?missing=6939

Though I have to note, for both the latter two cases that quite a few of
those prefixes are marked orange and thus those prefixes are only seen
by a small majority of the folks who send prefixes to GRH anyway.

What now is more disturbing is that there appears to be a couple of
prefixes out there which are not in the ARIN registry anymore which are
still being used (Hexago/Gogo6/Freenet6/nameoftheday's 2001:5c0::/32 is
an exemplary one) but also 2001:1890::/32 for AT&T worldservices,
2001:4800::/32 which once was Rackspace and quite a few others...

It just shows that everybody is just letting IPv6 routing grow as a
swamp till the real transits move in and start filtering nicely to get
the weed sorted out.

Btw RPSL anyone? You do know that nowadays the RIPE IRR allows ARIN
prefixes to be properly authenticated and registered too I hope?

See for more information:

Please use this facility, kthx!

Greets,
Jeroen

In whois they're really a /29 but nothing prevents them from advertising individual /32 at different points around the net.

http://whois.arin.net/rest/net/NET6-2001-1890-1

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net

That explains that one at least, as it seems they upgraded themselves
out of a /32 to a /29 on 2010-10-01, seems they didn't come around
actually announcing that space yet though.

Now how shall I make GRH believe that the /32 was there once, being
announced for 7 years, but the /29 isn't yet, as stating the /29 is
announced since then is not right and tossing that information out would
not be entirely correct either...

Same goes for Rackspace it seems who are now a /30, they are at least
announcing the aggregate. Adobe also did a /48 -> /45 upgrade but are
still just announcing their old /48, same for PCH and Tellme.

The Hexago prefix though is completely missing from whois and I am
really wondering what is up with that as that prefix is quite well used
one would think. Hope somebody sorts that one out.

As for the subject of advertising more specifics... what if eg DTAG or
France Telecom decided to start announcing every separate /32 out of
their /19, that would be 8k extra routes each and the world is larger
than that thus those 300k routes in IPv6 can easily be done.

Of course, as there are a couple of RIRs who are doling out multiple
disjunct prefixes to ISPs already and various ISPs are going to all of
the RIRs for a prefix per country in some cases, not much that can be
done about that kind of swamping I guess..... thus better start coming
up with some good hardware folks that can handle copious amounts of very
long routes :wink:

Greets,
Jeroen