
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 ---------------------------------------- From: "Mike Tancsa" <mike@sentex.net> Sent: Thursday, November 18, 2010 5:45 PM To: "Lee Riemer" <lriemer@bestline.net> Subject: Re: IPv6 On 11/18/2010 5:14 PM, Lee Riemer wrote:
Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 2001:470:0:76::2 (www.he.net) via Cogent.
Interesting. I noticed a similar issue with ipv6.cnn.com today. I dont see it via TATA, but see it via Cogent. So whats the story behind it and ARIN not being seen through cogent ? Is it due to no v6 relation bewtween he.net and Cogent ? 2620:0:2200:8:8888:8888:8888:8901 (whats with the crazy 8s?) see http://lg.as6453.net/lg/ Router: gin-mtt-mcore3 Site: CA, Montreal - MTT, TATA COMM. INT. CENTER Command: traceroute ipv6 2620:0:2200:8:8888:8888:8888:8901 Tracing the route to 2620:0:2200:8:8888:8888:8888:8901 1 * * * 2 * * * 3 * * * 4 * * * ---Mike

On 11/18/10 3:00 PM, Nick Olsen wrote:
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
Nick Olsen Network Operations (855) FLSPEED x106
----------------------------------------
From: "Mike Tancsa" <mike@sentex.net> Sent: Thursday, November 18, 2010 5:45 PM To: "Lee Riemer" <lriemer@bestline.net> Subject: Re: IPv6
On 11/18/2010 5:14 PM, Lee Riemer wrote:
Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 2001:470:0:76::2 (www.he.net) via Cogent.
Interesting. I noticed a similar issue with ipv6.cnn.com today. I dont see it via TATA, but see it via Cogent. So whats the story behind it and ARIN not being seen through cogent ? Is it due to no v6 relation bewtween he.net and Cogent ?
2620:0:2200:8:8888:8888:8888:8901 (whats with the crazy 8s?)
Router: gin-mtt-mcore3 Site: CA, Montreal - MTT, TATA COMM. INT. CENTER Command: traceroute ipv6 2620:0:2200:8:8888:8888:8888:8901
Tracing the route to 2620:0:2200:8:8888:8888:8888:8901
1 * * * 2 * * * 3 * * * 4 * * *
---Mike

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 On Nov 18, 2010, at 3:00 PM, Nick Olsen wrote:
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
----------------------------------------
From: "Mike Tancsa" <mike@sentex.net> Sent: Thursday, November 18, 2010 5:45 PM To: "Lee Riemer" <lriemer@bestline.net> Subject: Re: IPv6
On 11/18/2010 5:14 PM, Lee Riemer wrote:
Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 2001:470:0:76::2 (www.he.net) via Cogent.
Interesting. I noticed a similar issue with ipv6.cnn.com today. I dont see it via TATA, but see it via Cogent. So whats the story behind it and ARIN not being seen through cogent ? Is it due to no v6 relation bewtween he.net and Cogent ?
2620:0:2200:8:8888:8888:8888:8901 (whats with the crazy 8s?)
Router: gin-mtt-mcore3 Site: CA, Montreal - MTT, TATA COMM. INT. CENTER Command: traceroute ipv6 2620:0:2200:8:8888:8888:8888:8901
Tracing the route to 2620:0:2200:8:8888:8888:8888:8901
1 * * * 2 * * * 3 * * * 4 * * *
---Mike

Hello, On 19 nov 2010, at 00:00, Nick Olsen wrote:
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. Kind regards, Job Snijders

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. On 11/19/10 12:35 PM, Job W. J. Snijders wrote:
Hello,
On 19 nov 2010, at 00:00, Nick Olsen wrote:
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.
Kind regards,
Job Snijders
-- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl

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: http://labs.ripe.net/Members/Paul_P_/ripe-registry-global-resource-service Please use this facility, kthx! Greets, Jeroen

On Fri, 19 Nov 2010, Jeroen Massar wrote:
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,
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

On 2010-11-19 16:35, Antonio Querubin wrote:
On Fri, 19 Nov 2010, Jeroen Massar wrote:
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,
In whois they're really a /29 but nothing prevents them from advertising individual /32 at different points around the 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 ;) Greets, Jeroen
participants (8)
-
Antonio Querubin
-
Jeroen Massar
-
Jeroen Wunnink
-
Job W. J. Snijders
-
Joel Jaeggli
-
Nick Olsen
-
Owen DeLong
-
sthaug@nethelp.no