IPv6 internet broken, cogent/telia/hurricane not peering
Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia. However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane. This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable. I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'. I'm currious about you point of view. regards, Igor Ybema Senior network Administrator Oxilion
On Oct 12, 2009, at 7:41 AM, Igor Ybema wrote:
I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia.
However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane.
This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable.
I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'.
It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status. I never thought HE would be one of those networks. -- TTFN, patrick
On Oct 12, 2009, at 6:09 PM, Patrick W. Gilmore wrote:
It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status.
I never thought HE would be one of those networks.
Do we have any proof it's HE rejecting peering or is it that Cogent en Telia alike that are to proud to ask and think they can have a piece of the pie as they did with v4 ? MarcoH
On Oct 12, 2009, at 12:52 PM, Randy Bush wrote:
sure would be nice if there was a diagnosis before the lynching
If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that. -- TTFN, patrick
Patrick W. Gilmore wrote:
On Oct 12, 2009, at 12:52 PM, Randy Bush wrote:
sure would be nice if there was a diagnosis before the lynching
If this happened in v4, would customers care 'why' it happened? Obviously not.
I suspect more NAT will become a better solution than migrating to IPv6 if/when runout becomes a problem because there's just not enough visibility or providers that take it seriously enough for IPv6 to be a viable solution. I try to do my part but it's a horrible pain.
Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that.
As far as HE goes, they're so pro-IPv6 I would be surprised if anything intentionally bad was going on. I wish more providers had their attitude towards IPv6. ~Seth
On Mon, 2009-10-12 at 10:47 -0700, Seth Mattinen wrote:
Patrick W. Gilmore wrote:
On Oct 12, 2009, at 12:52 PM, Randy Bush wrote:
sure would be nice if there was a diagnosis before the lynching
If this happened in v4, would customers care 'why' it happened? Obviously not.
I suspect more NAT will become a better solution than migrating to IPv6 if/when runout becomes a problem because there's just not enough visibility or providers that take it seriously enough for IPv6 to be a viable solution. I try to do my part but it's a horrible pain.
And then you have the hoards of DSLreports people screaming about how they do not have a routeable IP address anymore, which is bad for business, and then IPv6 comes about because the people *demand* it. (although they do not necessarily know they are demanding that -- what they are demanding is the ability to continue having publically routeable IP addresses for their broadband connection.) William
sure would be nice if there was a diagnosis before the lynching If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that.
many of us are interested in diagnosis. few in your lynch rope. randy
Randy Bush wrote:
sure would be nice if there was a diagnosis before the lynching If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that.
many of us are interested in diagnosis. few in your lynch rope.
What Randy has been *hinting* at is largely relevant... I'm a /32 holder, with clients that have /48. I would appreciate some of the diagnostic paperwork that has been written... Steve ps. I'm not choosing sides in any way, nor do I want to start a flame, but HE has been exceptionally helpful v6-wise since I got into the game.
On Oct 12, 2009, at 5:23 PM, Randy Bush wrote:
sure would be nice if there was a diagnosis before the lynching If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that.
many of us are interested in diagnosis. few in your lynch rope.
I think you are stretching things to make a pithy post. More importantly, you are missing the point. For the v6 'Net to be used, customers - you know the people who pay for those router things and that fiber stuff and all our salaries and such - need to feel some comfort around it actually working. This did not help that comfort level. And I believe it is valid to ask about it. Diagnosis is good. Fortunately, anyone who cares knows exactly what happened on a technical level - HE has no v6 transit and does not peer with Telia; Telia had C&W transit, then they didn't, now they do. Took less time to 'diagnose' than your one-liners took to write. Were you actually interested in diagnostics, you would have spent some time looking as opposed to trying to be pithy to 10K of your not-so-closest buddies. Unfortunately, and you damned well know this, we are not going to get a /real/ diagnosis out of a busted peering relationship. Especially when one party is an incumbent telco. HE typically - and properly - will not discuss such relationships (modulo Mike's Cogent post, which even he says is unusual). And Telia won't discuss squat, full stop. So why it happened is a mystery, and will be for, well, ever. Diagnosis ends. However, the question still stands about the stability, and therefor, utility of the v6 'Net. Is it still some bastard child, some beta test, some side project? Or is it ready to have _revenue_producing_ traffic put on it? When a network as solid and customer-oriented as HE can have a long outage to such a large network as Telia, I submit it is not. I know, everyone is shocked. But operationally speaking, this matters. We can either say "but it was just v6", or we can think about how to not have this happen again. The former leads no where. Perhaps we should choose the latter instead of making pithy posts? If that is a "lynch rope", I will not bother arguing with you. Pigs & mud & all that. But that doesn't make it wrong, or irrelevant. In summary, we have the standard Chicken & Egg problem. No one cares about v6, so no one puts anything important on v6, so no one cares about v6. HE was trying harder to break that vicious cycle than anyone else, yet even they do not come close to supporting v6 as much as they support v4. Sad times for the future of the Internet if we all need to use v6 Real Soon Now. I asked for HE's view on that. Would you mind explaining why you don't want to hear it? -- TTFN, patrick P.S. Being a curmudgeon is useful from time to time. But only if you are, well, being useful.
Patrick W. Gilmore wrote:
For the v6 'Net to be used, customers - you know the people who pay for those router things and that fiber stuff and all our salaries and such - need to feel some comfort around it actually working. This did not help that comfort level. And I believe it is valid to ask about it.
That is entirely correct and I'm glad you asked that question! ;) Let me explain: (Lots of truisms here, bear with me!) IPv6 is newer than IPv4. As IPv6 is newer than IPv4, the equipment to support IPv6 natively is newer than legacy equipment already deployed that only supports IPv4. As the equipment that supports native IPv6 is newer, there are fewer core networks that run native IPv6. As these new IPv6 networks are deployed they are growing and developing. (Like neurons forming connections, the IPv6 network is.) Deployment of IPv6 in the core has been growing year to year, with that growth accelerating. In fact, I'd tell trend watchers of business econometrics the accelerating growth curve both represents something important happening right now and something that is likely to have real world implications for Internet infrastructure companies in the future: http://bgp.potaroo.net/cgi-bin/plot?file=%2fvar%2fdata%2fbgp%2fv6%2fas6447%2fbgp%2dactive%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step (Short url: http://tiny.cc/An6fl ) If you are in the connectivity business, you can add a caption to this graph of your choosing: "Ignore at your own peril." Or (I like this one): "I see opportunity."
However, the question still stands about the stability, and therefor, utility of the v6 'Net. Is it still some bastard child, some beta test, some side project?
As you know, the IPv4 Internet of today is a product of the hard work of people of yore (ok well, more seriously, a large number of the people on this list and at networks around the world). The nature of things is that the coherent shared illusion of a single Internet routing table is the result of a rough consensus produced by years and years and years of accumulated business relationships and network engineer routing policy configurations. IPv6 is going through that phase right now, at accelerated pace. Perhaps geometric growth is not good enough for you as a business person. Perhaps where we are on the curve is not good enough for you yet. Perhaps you'd like to retire before working with another protocol. I hereby apologize to you on behalf of IPv6 that it has not had the same three decades of deployment and experimentation as IPv4. ;) IPv6 is not going to spring into existence as a fully complete global network to replace IPv4 on a specific flag day (December 21st 2012?). IPv6 will grow in deployment at the same time the Internet continues to work, at what appears to be on a geometric growth curve, due to some reasons a business economist can write a paper about. Network effect? Risk avoidance due to IPv4 run out? Risk avoidance due to technology shift? Yukon gold rush? The after the fact result of careful planning by thoughtful people started years earlier? Or perhaps, the projected functional economic value of IP addresses?
Or is it ready to have _revenue_producing_ traffic put on it?
IPv6 is production for some value of the word production. We see traffic around 1.5 Gbps, peaks at 2 Gbps and growing... Perhaps this says something about the amount of traffic that will be seen when it gets used widely. 1000 times as much? (Our guess) What's your guess? Warning! If you pick a low number you are saying that IPv6 is in widespread production use right now. :-P
In summary, we have the standard Chicken & Egg problem. No one cares about v6,
speak for yourself (introduce into evidence exhibit 1: the graph linked to above, exhibit 2: we note how part of the original poster's problem got fixed that day).
so no one puts anything important on v6,
speak for yourself (reference real traffic above). Once upon a time, something called IPv4 was invented, and some people created hardware for it, wrote software for it, tried it out, wrote some papers, wrote some RFCs (after writing working code, the way it should be done LOL), and then experimented some more. There were lots of problems that got solved, things that worked in real life in spite of theoretical problems, and bugs that got fixed. Some companies got created... blah blah blah.
Sad times for the future of the Internet if we all need to use v6 Real Soon Now.
Or, expect real freaking huge opportunity and dislocation ahead. Of course, this dislocation may only affect some specific players and companies and industries. For the regular user it could just happen transparently that by the time they get their next computer with Microsoft Windows 9 or Ubuntu Quick Quagga... it just works. Imagine, what would it be like if all the core network operators had to figure out who get Internet connectivity from again. Imagine, if they had to setup all their peering and transit sessions again because of their existing telecommunications vendors only some of them decided to try out this new Internet thing. (Deja vu yet?) Well you don't have to imagine! That is what is happening right now! We are talking about a major sea change here. How long might the central wave of this sea change take to pass? 5 years? To come up with a wildy guestimated date, you might average the time to: * Replace 60 percent of home computers (count existing Windows Vista and Macintosh OS X computers towards this total, since they already just magically work with IPv6 if you have IPv6 on your LAN). * Replace 60 percent of residential CPE. (Base it on customer churn, CPE failure, and technology upgrades.) * Replace 60 percent of core routers. Why use 60 percent as a milestone? Because it represents more than half. Why does more than half matter? Because we could use it to make a nice graph to project cross over for the prevalence of IPv6 connectivity vs IPv4. In most companies I've been at, this sort of graph is used to predict when to stop spending additional money on the item that will not be relevant to the company's future sources of revenue. In otherwords, 60 percent is the point of no return because at that point capital allocation budgets are co-opted. BTW, if you plan on getting started after that ship has sailed, well...
I asked for HE's view on that.
My pleasure! :) Mike.
I think you are stretching things to make a pithy post. More importantly, you are missing the point.
and hundreds of words do not cover that you accused HE of something for which you had no basis in fact. type less, analyse and think more. randy
On Oct 14, 2009, at 9:32 AM, Randy Bush wrote:
I think you are stretching things to make a pithy post. More importantly, you are missing the point.
and hundreds of words do not cover that you accused HE of something for which you had no basis in fact. type less, analyse and think more.
I expanded to try and get you to see the point. I obviously failed. I shall not bother to try again as I'm worried the failure was at least partially because you would rather be pithy than see the point not matter how fully explained. As for facts, there is lots of basis. HE has run a network for decades and has never let a v4 bifurcation happen so long. Ever. They've run v6 for a few years yet it happened. Asking the network in question's view on this perfectly reasonable - in fact the opposite would be unreasonable. As for accusations, I challenge you to show where I accused them of anything. Typing less does not mean you are actually thinking. You should try the latter before your next pithy post. Or at least read the post to which you are replying. -- TTFN, patrick
As for accusations, I challenge you to show where I accused them of anything.
From: patrick@ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 12:09:58 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com> References: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com> Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net>
...
It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status.
I never thought HE would be one of those networks.
You really can't read, can you? And I spoke to Martin about it personally. If he's OK with it, perhaps you should clam down? -- TTFN, patrick On Oct 14, 2009, at 11:47 AM, Randy Bush wrote:
As for accusations, I challenge you to show where I accused them of anything.
From: patrick@ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 12:09:58 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com
References: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com
Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net>
...
It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status.
I never thought HE would be one of those networks.
From: "Patrick W. Gilmore" <patrick@ianai.net> Date: October 12, 2009 12:49:02 PM EDT To: NANOG list <nanog@nanog.org> Cc: "Patrick W. Gilmore" <patrick@ianai.net> Subject: Re: IPv6 internet broken, cogent/telia/hurricane not peering
To be clear, I was not trying to imply that HE has a closed policy. But I can see how people might think that given my Cogent example. My apologies to HE.
And to be fair, I'm pounding on HE because they've always cared about their customers. I expect Telia to care more about their own ego than their customers' connectivity. So banging on them is nonproductive.
In summary: HE has worked tirelessly and mostly thanklessly to promote v6. They have done more to bring v6 to the forefront than any other network. But at the end of day, despite HE's valiant effort on v6, v6 has all the problems of v4 on the backbone, PLUS growing pains. Which means it is difficult to rely on it, as v4 has enough dangers on its own.
Anyway, I have confidence HE is trying to fix this. But I still think the fact that it happened - whatever the reason - is a black eye for the v6 "Internet", whatever the hell that is.
Patrick W. Gilmore (patrick) writes:
You really can't read, can you?
And I spoke to Martin about it personally. If he's OK with it, perhaps you should clam down?
I know Randy to be a bit taciturn and hard to get through to sometimes, but never of being a shellfish. P.
You really can't read, can you? And I spoke to Martin about it personally. If he's OK with it, perhaps you should clam down? I know Randy to be a bit taciturn and hard to get through to sometimes, but never of being a shellfish.
i am from the pacific northwest. so shellfish is good. it's endless aggressive/defensive bs that is harder to let go by without calling it. randy
Randy Bush wrote:
As for accusations, I challenge you to show where I accused them of anything.
From: patrick@ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 12:09:58 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com> References: <a05493650910120441i27550f17qaa7d3377824afdda@mail.gmail.com> Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net>
...
It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status.
I never thought HE would be one of those networks.
The only thing Patrick is guilty of is not providing enough context. The party at fault here is Cogent. If you re-read the entire thread and speak with Mike Leber, you'll find that HE offered peering and/or transit, for free, to Cogent - like they do to everyone else, and Cogent didn't take it, providing for the segmentation we saw. -Dave
Patrick W. Gilmore wrote:
As for facts, there is lots of basis. HE has run a network for decades and has never let a v4 bifurcation happen so long. Ever. They've run v6 for a few years yet it happened.
News flash, IPv6 is new. News flash, every single IPv6 network that gets configured that previously did not exist is new. News flash, when an IPv6 newbie configures IPv6 for the first time they have zero IPv6 BGP peers and transits until they configure them. News flash, some of these IPv6 newbies will even commit the error of not bothering to establish much IPv6 peering or decent IPv6 transit, before adding a AAAA record for their main website, ensuring that it is broken for the majority of the existing IPv6 Internet. News flash, newbies make mistakes, insist up is down, blue is green etc. This is called learning if they fix it, and stupidity otherwise. News flash, Hurricane will do everything possible to reach these newbie networks where ever they are in the world, some of them rather large, and try to help them (sometimes in spite of themselves), however some of them will insist on breaking themselves anyway! It's just going to happen and there is nothing you can do to stop them. Customers will vote with dollars (or whatever currency), problem solved. Mike.
On 10/14/09 8:11 AM, Patrick W. Gilmore wrote:
Typing less does not mean you are actually thinking. You should try the latter before your next pithy post. Or at least read the post to which you are replying.
Now now boys and girls. Settle down and be civil. :)
Igor Ybema wrote:
Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia.
However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane.
This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable.
I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'.
I'm currious about you point of view.
Don't get me started on IPv6 crap... ;) If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/ ~Seth
Seth Mattinen wrote:
If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/
At the risk of sounding like I'm piling on, I'm in the same basically the same boat that Seth is, except that I do know who my account rep is and have been in touch with him. Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. I've been told that Verizon is discussing this policy and whether it should be updated, but until they update their policy to be in line with the IPv6 Internet allocation/assignment policies from at least September of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your announcements are only longer than /32, you should be aware that Verizon is completely unreachable for you - even if you are a Verizon customer directly. -- Jeff McAdams
In message <4AD382E4.9010901@iglou.com>, Jeff McAdams writes:
Seth Mattinen wrote:
If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/
At the risk of sounding like I'm piling on, I'm in the same basically the same boat that Seth is, except that I do know who my account rep is and have been in touch with him.
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
I've been told that Verizon is discussing this policy and whether it should be updated, but until they update their policy to be in line with the IPv6 Internet allocation/assignment policies from at least September of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your announcements are only longer than /32, you should be aware that Verizon is completely unreachable for you - even if you are a Verizon customer directly.
-- Jeff McAdams
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
Unfortunately, not everyone always has that choice.
In message <1255388942.12984.1.camel@acer-laptop>, Bret Clark writes:
On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
Unfortunately, not everyone always has that choice.
If there isn't as choice then regulation is required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
In message <4AD382E4.9010901@iglou.com>, Jeff McAdams writes:
Seth Mattinen wrote:
If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/ At the risk of sounding like I'm piling on, I'm in the same basically the same boat that Seth is, except that I do know who my account rep is and have been in touch with him.
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
I am, sort of; I'm a new customer so they installed, but I haven't accepted it yet. Unfortunately I won't be able to get back to dealing with it until late next week at the earliest as I'm in the middle of moving to a new facility. ~Seth
Mark, On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s. And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes. In other words, get used to it. Regards, -drc
On Oct 12, 2009, at 4:37 PM, David Conrad wrote:
Mark,
On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s.
I disagree. With IPv4 the bigger issue is that everyone and their mom has 9 different announcements behind their single ASN. With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer. Even if the average drops to 1/2, you're talking about a 70,000 route table today, and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that. The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be retired.
And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes.
There is that problem, too. Personally, I think the market was a horrible idea, but, it had way too much momentum for me to be able to stop it.
In other words, get used to it.
Pretty much. I think eventually, we're going to have to look at moving to an ID/Locator split method in the IDR realm. Owen
Owen, On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote:
With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer.
I wasn't aware people would be doing traffic engineering differently in IPv6 than in IPv4.
Even if the average drops to 1/2, you're talking about a 70,000 route table today,
How big are IPv6 objects in CAMs again?
and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that.
I've heard differing opinions on this (e.g., router ASICs being both some of the most complicated ASICs ever made and being non-commodity parts hence not necessarily following Moore's Law, pin density in those ASICs reaching a point where you start running into crosstalk problems, cats and dogs living together, mass hysteria, etc). I'm not a hardware guy so I'll just stare blankly.
The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be retired.
Right. And when are we planning on retiring IPv4 again? Interestingly, if you're an ISP and you don't want to redeploy your insanely expensive high end routers with the huge CAMs, you might look to see which prefixes you could drop that would cause the least impact to the majority of your customers. In this light, filtering the crap out of IPv6 would appear to make business sense.
I think eventually, we're going to have to look at moving to an ID/Locator split method in the IDR realm.
The big challenge with this is backwards compatibility... Regards, -drc
On Mon, Oct 12, 2009 at 8:40 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote:
and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that.
I've heard differing opinions on this (e.g., router ASICs being both some of the most complicated ASICs ever made and being non-commodity parts hence not necessarily following Moore's Law, pin density in those ASICs reaching a point where you start running into crosstalk problems, cats and dogs living together, mass hysteria, etc). I'm not a hardware guy so I'll just stare blankly.
I thought Tony's preso from RAWS was available or part of the report, no? (which seemed pretty clear to me about cam sizes and asic capabilities not going to meet the needs within the next 5-7 years) -chris
On Mon, 12 Oct 2009 17:40:36 PDT, David Conrad said:
On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote:
With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer.
I wasn't aware people would be doing traffic engineering differently in IPv6 than in IPv4.
You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48. And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses.
On Tue, Oct 13, 2009, Valdis.Kletnieks@vt.edu wrote:
You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48.
And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses.
I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE. 2c, Adrian
Adrian Chadd wrote:
On Tue, Oct 13, 2009, Valdis.Kletnieks@vt.edu wrote:
You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48.
And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses.
I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE.
I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes. Speaking of TE, it's going to be interesting to see how we deal with that. We can't expect everyone to accept any /48 that gets announced. I'm still waiting for the first time someone blows up the Internet by announcing all 65536 /48's in their /32. I'm amazed it hasn't happened yet. Stricter use of the IRR might help if there wasn't rampant auto proxy registering going on. RPKI may be the answer since that can't be proxy-registered. That would at least mitigate router bugs and carelessness. The issue of what intentional TE routes are seen as "acceptable" is another issue. - Kevin
Kevin Loch wrote:
Adrian Chadd wrote:
On Tue, Oct 13, 2009, Valdis.Kletnieks@vt.edu wrote:
You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48.
And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses.
I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE.
I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes.
Speaking of TE, it's going to be interesting to see how we deal with that. We can't expect everyone to accept any /48 that gets announced. I'm still waiting for the first time someone blows up the Internet by announcing all 65536 /48's in their /32. I'm amazed it hasn't happened yet.
Stricter use of the IRR might help if there wasn't rampant auto proxy registering going on. RPKI may be the answer since that can't be proxy-registered. That would at least mitigate router bugs and carelessness. The issue of what intentional TE routes are seen as "acceptable" is another issue.
I would love to see TE die a painful death. Maybe someone announcing 65536 routes will bring it to a swift end. ~Seth
On Tue, 13 Oct 2009 00:46:00 EDT, Kevin Loch said:
Adrian Chadd wrote:
On Tue, Oct 13, 2009, Valdis.Kletnieks@vt.edu wrote:
You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48.
And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses.
I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE.
I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes.
Exactly. We have 4 prefixes only because we got slow-started and similar hysterical raisins, we don't use those for TE at all. If we wanted to do any globally visible TE that actually made a difference, we'd have to announce a more-specific out of one of the /16s anyhow, since that's where all our traffic generators/sinks are (and probably a matching more-specific out of our v6 /48). So we're always going to have 4+N on the IPv4 and 1+N on the IPv6 side. (And if we'd gotten more address space for that wireless net, we'd be at 5+N rather than 4+N).
On 13/10/2009, at 5:46 PM, Kevin Loch wrote:
I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes.
You can pretty easily figure out how many advertised prefixes are intentional de-aggregates, and you can get a fairly good idea as to how many of them are for TE as well I expect, by looking for different AS paths. Someone mentioned some slides earlier in this thread by Vince Fuller at APRICOT early '07 that from memory have pretty good data on this. -- Nathan Ward
In a message written on Mon, Oct 12, 2009 at 05:09:41PM -0700, Owen DeLong wrote:
With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer. Even if the average drops to 1/2, you're talking about a 70,000 route table today, and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that.
Here's a presentation from 2007. http://www.vaf.net/~vaf/apricot-plenary.pdf On page 13, you'll find a table. It starts with numbers in November of 2006, and makes projections. The 5 year projections (Nov 2011) have already been exceeded, in both IPv4 Internet Routes and Active ASN's. The problem isn't that we have 300,000 "global routes" on the Internet (http://www.cidr-report.org/as2.0/#General_Status), but that there are other things that compete for TCAM space. It's that TCAM must hold not only the global routes, but also: - Internal routes. Your IGP routes, no-exported customer deagregations, blackhole routes, etc. - MPLS Labels, including: - MPLS Traffic Engineering - MPLS VPN Identifiers - Virtual Routing Instances for Layer 3 VPN's. - ARP Entries - Multicast Routes Unfortunately details are hard to come by as most of the folks who see this in any significant way (e.g. global "tier 1" full service ISP's) tend not to release too many specific numbers for competitive reasons. That said, even using some basic assumptions (some of which are in the preso) those 300,000 global routes might have added to them: 300,000 global routes 150,000 internal routes 20,000 MPLS labels 200,000 VPN/VRF Routes 5,000 ARP Entries 20,000 Multicast Routes -------- 695,000 TCAM Entries Consumed That's today, right now, in major ISP's routers. All the sudden those "1 million route" core routers don't seem so large. Keep in mind we've passed the 2006 projection in this report in 3 years, not 5. So we're growing faster than we expected. Add in your 70,000 route IPv6 table, plus growth, and the 1 million route routers are probably failing sometime in 2011. Someone will likely pipe up, but Cisco has a 3 million route processor now! (I believe that is the spec of the just announced PRP3, but can't find a reference on Cisco's web site). Yes, that's a route processor that can do the job, but in these high end boxes the TCAM is distributed on the linecards. So upgrading from the 1 million route TCAM core routers to the 3 Million route TCAM means upgrading every linecard in each router you upgrade. Ouch. The picture I painted above is actually the rosy part of the picture. Many of these backbones have older equipment in the core which can't even do 1M routes. They use careful design and other techniques to limit the number of entries particular boxes have to see.
The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be retired.
While I think Verizon's move is somewhat premature, I can see why they might be afraid of routing table growth. I think there is an extremely high probability that given the growth of the table due to primarily to IPv6 and the growth of MPLS VPN offerings, combined with the current economic climate which has reduced the capital available for upgrades that we will see several providers "hit the wall" of various popular bits of equipment. I think some of the engineering staff at various major providers has already realized this as well. We don't seem to have a technological solution. LISP has scaling issues of its own, and would require swapping out a huge amount of equipment. TCAM scaling is at best cost prohibitive, at worst not possible due to the physical ram speed, and both are being improved at a modest rate (the preso suggests 10% per year). Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate. The next 5 years may bring internet instability problems and route filtering on a scale we haven't seen since the early 90's. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate.
It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people. Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI. ~Seth
On Mon, Oct 12, 2009, Seth Mattinen wrote:
It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people.
IPv6 -policy- wasn't initially designed for any workable site multihoming. The addressing and BGP stuff works fine for it. Its just not "different" to the issues faced with IPv4. adrian
On Mon, Oct 12, 2009 at 10:13 PM, Seth Mattinen <sethm@rollernet.us> wrote:
Leo Bicknell wrote:
Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate.
It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an
here's where a pointer to this dicussion of ~4yrs ago should be (on this list no less)... that said: "Hey, this is afu, if you as operators want this to work properly, please, please, please get your butts on v6ops@ietf and make some noise." I believe that'd have been from me, but marla azinger also sent out some similar emails and presented 2-3 times at past nanog meetings about multihoming options wrt ipv6. This ain't gonna get fixed by nanog-kvetching.
"ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people.
v6 was designed in an era quite different than today's network. there were a large number of assumptions made, practically none of which hold water today. this can't get fixed here, please see v6man/v6ops@ietf. Alternately please see rrg@ietf or lisp@ietf, rrg's looking to make a decision on their research 'soon', lisp is looking for active folks to provide comment/direction...
Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a
there are no (save lisp) network based 'hacks' for this... shim6/hip/mip all basically do host-level multihoming, which is cool, and may be useful to some folks, but they are not useful for folks trying to do TE in the network. (which also was hashed out quite a bit on this list)
debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI.
100% agreement... wanna join in the discussion and offer some options/fixes/commentary? -chris
In a message written on Mon, Oct 12, 2009 at 07:13:04PM -0700, Seth Mattinen wrote:
Leo Bicknell wrote:
Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate.
It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people.
I may have editorialized in a way that was not completely clear. I agree that due to lack of an alternative "PI IPv6" is necessary and effectively the only option we have right now. Were IPv6 policy to only allow those who could get IPv4 PI to get IPv6 PI I would say the problem was "the same". However, the reason I say it is being made worse is that there is a subset of the RIR community who sees the lack of scarcity of addres space as a reason to provide IPv6 PI to people who cannot qualify for IPv4 PI. My impression of the current RIR policy trends are resulting in a situation that more folks will be able to get IPv6 PI than can currently get IPv4 PI. Hence why I put that in the list of things making it worse.
Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI.
The only idea I have seen that holds any promise is LISP. There is working code, and the idea is sound. However, like squeezing a balloon while it makes some issues better it then puts pressure in other directions. It trades off TCAM lookups for LOC/ID lookups and caching. It's not clear to me on an Internet scale system this is better; but I do hope the folks doing that work continue on the chance that it is... -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Seth Mattinen wrote:
Leo Bicknell wrote:
Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate.
It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming.
Lest anyone forget it has the same non-workable site-multihoming that has allowed the internet to grow to the size it is today. by non-working we mean not-better than ipv4. We actually know how to run that network pain and all.
The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people.
Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI.
~Seth
David Conrad wrote:
On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet.
Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s.
And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes.
And I look at the other side of it. For us "mere" end-user organization (ie, not big backbone ISPs who have dominated the discussion for so long), IPv6 without PI is an utter and complete non-starter. Despite how huge of a proponent of IPv6 deployment that I am, until PI space was available, I didn't start the work, because without PI space, its utter foolishness for a company that depends on their Internet access to move forward. I don't think its a coincidence that we've seen a big uptick in deployment of IPv6 since PI space became available. Telling end-user organizations to get a block from each upstream and multihome by putting an address from each upstream on every system is now and always has been a bad joke.
In other words, get used to it.
In other words, figure it out. Either we'll have PI space in IPv6, or IPv4 is going to get *crazy* fragmented as continually smaller blocks are bought and sold. If you want to keep your cam tables from blowing up, I truly think the way forward is to get people to IPv6 as quickly as possible, where they can get blocks big enough to put all of their address space in 1 or 2 blocks, rather than the 4, 7 or more, blocks that they're currently using for IPv4. And, no, not everyone deaggregates for TE purposes. No network that I've ever been in charge of has ever advertised anything but the most aggregated blocks that we could given the allocations/assignments we had. We'll have savings from that, and if you want to filter to limit deaggregating for TE purposes, I'm quite OK with that. But if you cut out PI space, you're dead in the water, we just can't have that. -- Jeff McAdams
On 13/10/2009, at 8:26, Jeff McAdams <jeffm@iglou.com> wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have / 48 PI space from ARIN that are direct customers of Verizon.
What about the small matter of all of the current AAAAs for the the IPv6 enabled root DNS servers? -- Nathan Ward
From where I sit, it looks like: a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48 f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48 h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48 j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48 k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32 l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48 m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32 b.root-servers.net has no AAAA record c.root-servers.net has no AAAA record d.root-servers.net has no AAAA record e.root-servers.net has no AAAA record g.root-servers.net has no AAAA record i.root-servers.net has no AAAA record So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others. The fact that b, c, d, e, g, and i do not have AAAA records actually concerns me more than the fact that Verizon customers can only reach two. Owen On Oct 12, 2009, at 4:39 PM, Nathan Ward wrote:
On 13/10/2009, at 8:26, Jeff McAdams <jeffm@iglou.com> wrote:
Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon.
What about the small matter of all of the current AAAAs for the the IPv6 enabled root DNS servers?
-- Nathan Ward
On Mon, Oct 12, 2009 at 8:16 PM, Owen DeLong <owen@delong.com> wrote:
From where I sit, it looks like: ..snip.. So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others.
or.. vzb (is now dead, it's all vz) has holes in filters to permit prefixes of certain lengths or certain prefixes exactly. I believe since I can reach k-root from my uu-connected + uu-v6'd device that'd be the case. -chris
Owen DeLong wrote:
From where I sit, it looks like:
a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48
f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48
h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48
j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48
k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32
l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48
m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32
b.root-servers.net has no AAAA record c.root-servers.net has no AAAA record d.root-servers.net has no AAAA record e.root-servers.net has no AAAA record g.root-servers.net has no AAAA record i.root-servers.net has no AAAA record
So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others.
I can see the /48's out of 2001 in Verizon's table. ~Seth
Owen DeLong wrote:
From where I sit, it looks like:
a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48
f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48
h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48
j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48
k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32
l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48
m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32
So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others.
I can see all of those through Verizon, so I'm not sure of how their policy applies, or if they're making an exception for these, but they are visible through Verizon. -- Jeff McAdams jeffm@iglou.com
I get asked often enough about what's in 701's IPv6 routes so I just dumped it to a plain text file for anyone interested: http://www.rollernet.us/wordpress/as701-ipv6/ ~Seth
Just saw that telia <-> HE AND telia <-> Cogent got fixed. They are now connected through C&W. Maybe someone got woken up by these messages :) Cogent and HE is still broken but then again, ipv6@cogent is still beta. regards, Igor
On Mon, Oct 12, 2009 at 07:06:37PM +0200, Igor Ybema wrote:
Just saw that telia <-> HE AND telia <-> Cogent got fixed. They are now connected through C&W. Maybe someone got woken up by these messages :)
Cogent and HE is still broken but then again, ipv6@cogent is still beta.
Cogent has never carried a full IPv6 table, and probably never will (or at least, not for a REALLY long time). They aren't using any IPv6 transit, and will only turn up peering with a handful of large networks as measured by their IPv4 peering stats. This isn't even close to representative of the IPv6 routing table, so they're probably going to continue to miss huge chunks of IPv6 for many years to come. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Igor Ybema wrote:
I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia.
However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane.
I'll spell it out for your entertainment. Hurricane aggressively tries to solve connectivity problems, IPv4 or IPv6. In the case of Cogent, they hilariously are trying to reduce peering with Hurricane over time. Hurricane has IPv4 peering with Cogent. Years ago this was at four locations in the world, then this was at three locations in the world, then two locations in the world. Why? Because over time when a BGP session would go down for longer than 30 seconds, Cogent permanently shut the session. Both Cogent and Hurricane have progressively lowered the local preference and otherwise filtered the routes we receive from each other to prevent the connections from saturating due to the size of our networks and the number of prefixes we each announce. These connections were a combination of OC12s in the US and public peering in Europe. Hurricane repeatedly over the years has pushed to replace the OC12s with atleast giges (if not 10GE), on the principle it would be cheaper, conform to more of the hardware each of us uses, allow us to remove legacy OC12 cards from the network, etc. Cogent hasn't. Why? Because even though they are content heavy and due to the routing tables one might infer they don't have settlement free peering with all networks, they don't want to help Hurricane in any way. Ok, fine. Not everybody choses to operate their network this way, usually most are more concerned about their customers, however hey who am I to say whatever they view as their core mission isn't being met. If you've been around long enough, you'd know that normally nobody talks about peering publicly like this. Most of the core network operators here could just infer what I told you above. Then why would I write this post? Because I want to set the record straight regarding Hurricane Electric's IPv6 peering goals, and nothing in Cogent's case seems to get through to them. Oh, BTW, let me describe the special case of irony. If Cogent wanted to ensure they weren't in a subservient role in IPv6 as they are for IPv4 (and I'm not talking about Hurricane, I'm talking about all the networks they've ever had to pay or fight in one way or another), then they would be working to have a complete IPv6 table by working with a player like Hurricane which reduces their dependency on networks that will be difficult with them, that is: be cooperative with them rather than give them a huge amount of crap and try to torture them at each turn (i.e. in order to get "peering" you need to buy these local loops, etc etc etc). BTW, regarding the comments about 6to4, with Hurricane Electric you will reach more of the IPv6 Internet, with lower latency than anybody else.
I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'.
We don't ignore comments about connectivity, in fact quite the opposite. We study each AS and which ASes are behind them. We work on getting peering with the specific AS, in the case that they are unresponsive, getting the ASes behind them. Among the things we do to discuss peering: send email to any relevant contacts, call them, contact them on IRC, send people to the relevant conferences to seek them out specifically, send people to their offices, etc. So far we stop short of baking cakes, but hey... Our goal is to provide as much connectivity to as many people as possible. That might be our goal, however, not everybody's goal on the Internet is to provide as much connectivity as possible for their customers. Mike.
No need for me to repeat what Mike has posted. I agree 100% with him on all fronts. Mike and his team have gone out of their way to promote and support IPv6 from the very beginning and I think everyone knows this. In the past, I had some differences with Mike over legacy policies that Hurricane adopted initially, but after spending time with him and explaining those issues, he did everything in his power to correct them. I'd even say he went above and beyond everyone's expectations. I hope this issue gets resolved quickly. I've seen first hand the political issues in v4 and I really hope we don't have a repeat of this in v6. There are a handful of providers that have turned to a restrictive IPv6 policy (or "must be existing peer in v4 to peer in v6 with us") and I find it outrageous at this point in time. Cogent, get with the program. Regards, Randy
Randy Epstein wrote:
No need for me to repeat what Mike has posted. I agree 100% with him on all fronts. Mike and his team have gone out of their way to promote and support IPv6 from the very beginning and I think everyone knows this. In the past, I had some differences with Mike over legacy policies that Hurricane adopted initially, but after spending time with him and explaining those issues, he did everything in his power to correct them. I'd even say he went above and beyond everyone's expectations.
I hope this issue gets resolved quickly. I've seen first hand the political issues in v4 and I really hope we don't have a repeat of this in v6. There are a handful of providers that have turned to a restrictive IPv6 policy (or "must be existing peer in v4 to peer in v6 with us") and I find it outrageous at this point in time.
Cogent, get with the program.
Regards,
Randy
Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole. You are publishing AAAA records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy. -Dave
Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole.
You are publishing AAAA records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy.
May I suggest to vote with your feet and take your business somewhere else. They obviously are not interested in you, your traffic or your money. MarcoH
Marco Hogewoning wrote:
Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole.
You are publishing AAAA records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy.
May I suggest to vote with your feet and take your business somewhere else. They obviously are not interested in you, your traffic or your money.
MarcoH
Already done. All they are doing is continuing to provide fodder for engineers to tell their bosses why to NOT consider 174 transit when it's brought up. -Dave
Funny enough, we've been looking at moving from 174 to HE for a large amount of traffic, and this discussion is making the decision *a lot* easier. On 10/12/09, Dave Temkin <davet1@gmail.com> wrote:
Marco Hogewoning wrote:
Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole.
You are publishing AAAA records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy.
May I suggest to vote with your feet and take your business somewhere else. They obviously are not interested in you, your traffic or your money.
MarcoH
Already done. All they are doing is continuing to provide fodder for engineers to tell their bosses why to NOT consider 174 transit when it's brought up.
-Dave
-- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
On Mon, Oct 12, 2009 at 1:56 PM, Randy Epstein <repstein@chello.at> wrote:
No need for me to repeat what Mike has posted. I agree 100% with him on all fronts. Mike and his team have gone out of their way to promote and support IPv6 from the very beginning and I think everyone knows this. In the past, I had some differences with Mike over legacy policies that Hurricane adopted initially, but after spending time with him and explaining those issues, he did everything in his power to correct them. I'd even say he went above and beyond everyone's expectations.
I hope this issue gets resolved quickly. I've seen first hand the political issues in v4 and I really hope we don't have a repeat of this in v6. There are a handful of providers that have turned to a restrictive IPv6 policy (or "must be existing peer in v4 to peer in v6 with us") and I find it outrageous at this point in time.
Cogent, get with the program.
*shrug* If Cogent wants to isolate itself from the rest of the Internet, it's kinda their problem, right? I mean, it's their network, if they don't want to play with the rest of us, they don't have to. They just won't have much to offer their customers if they decide not to play along. There's no mandate about universal connectivity; when you buy service from a provider, you select which provider to buy from based on the breadth and scope of services you desire. There may be a huge customer base for Cogent that fears the rest of the IPv6 Internet, and doesn't want to connect to it. If there's enough of a revenue stream from them to keep Cogent afloat, more power to them, I applaud them for discovering an alternative business model. I, for one, don't particularly believe in the utility of such a service, and wouldn't pay for it, but that doesn't mean there aren't a lot of frightened, paranoid people who really do want to play in a sheltered walled garden, kept apart from everyone else--and if Cogent can make a business out of servicing them, more power to them. I just wouldn't put my salary on the line banking on that business model panning out.*
Regards,
Randy
Matt *note, however, that I also opted to stay in college in 1991, rather than join Cisco because I felt they did not have a workable business model; in 1995, I rejected Mosaic Communications, because the idea of trying to compete with a freely downloadable browser seemed like business suicide; and I rejected Google's offer letter in early 2000, because it was clear that trying to compete with altavista by trying to support a company off revenues from search advertising was completely ludicrous. Given that track record, some may take my scathing indictment of Cogent's walled garden approach to IPv6 as a clear indicator of future earnings potential. :/
Matt
*note, however, that I also opted to stay in college in 1991, rather than join Cisco because I felt they did not have a workable business model; in 1995, I rejected Mosaic Communications, because the idea of trying to compete with a freely downloadable browser seemed like business suicide; and I rejected Google's offer letter in early 2000, because it was clear that trying to compete with altavista by trying to support a company off revenues from search advertising was completely ludicrous. Given that track record, some may take my scathing indictment of Cogent's walled garden approach to IPv6 as a clear indicator of future earnings potential. :/
*rofl* *cries* That was good!
On Mon, Oct 12, 2009 at 12:41 PM, Mike Leber <mleber@he.net> wrote: ...
We don't ignore comments about connectivity, in fact quite the opposite. We study each AS and which ASes are behind them. We work on getting peering with the specific AS, in the case that they are unresponsive, getting the ASes behind them.
Among the things we do to discuss peering: send email to any relevant contacts, call them, contact them on IRC, send people to the relevant conferences to seek them out specifically, send people to their offices, etc.
So far we stop short of baking cakes, but hey...
And tonight we saw in public that even that path is being attempted: http://www.flickr.com/photos/77519640@N00/4031434206/ (and yes, it was yummy and enjoyed by all at the peering BoF!) So Cogent...won't you please make nice with HE.net and get back together again? ^_^ Matt (speaking for neither party, but very happy to eat cake nonetheless)
On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being attempted:
http://www.flickr.com/photos/77519640@N00/4031434206/
(and yes, it was yummy and enjoyed by all at the peering BoF!)
So Cogent...won't you please make nice with HE.net and get back together again? ^_^
Matt (speaking for neither party, but very happy to eat cake nonetheless)
"Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen <ras@e-gerbil.net>wrote:
On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being attempted:
http://www.flickr.com/photos/77519640@N00/4031434206/
(and yes, it was yummy and enjoyed by all at the peering BoF!)
So Cogent...won't you please make nice with HE.net and get back together again? ^_^
Matt (speaking for neither party, but very happy to eat cake nonetheless)
"Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :)
And now even better shots of the cake have been forthcoming from people. :) http://www.flickr.com/photos/77519640@N00/4031195041/ (I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory). Fortunately, I did get to partake in the eating of it. ^_^ Matt (This cake is great, it's so delicious and moist...* ;) *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
please full support huricane ! De-peer your ipv6 peering cogent/telia or max prepend it. ! Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen <ras@e-gerbil.net>wrote:
On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being attempted:
http://www.flickr.com/photos/77519640@N00/4031434206/
(and yes, it was yummy and enjoyed by all at the peering BoF!)
So Cogent...won't you please make nice with HE.net and get back together again? ^_^
Matt (speaking for neither party, but very happy to eat cake nonetheless)
"Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :)
And now even better shots of the cake have been forthcoming from people. :)
http://www.flickr.com/photos/77519640@N00/4031195041/
(I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory).
Fortunately, I did get to partake in the eating of it. ^_^
Matt (This cake is great, it's so delicious and moist...* ;)
*http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
Please don't break existing connectivity in an effort to show support for Hurricane. That's going in the wrong direction and it doesn't help the users of the internet, your customers, or ours. Please do continue to, or start peering with Hurricane. The internet works best when people peer. Breaking or damaging that in any way is not helping any of our customers and it is contrary to Hurricane's desire. We appreciate the intended message of support, but, it's most important to preserve functionality for all of our customers. Thanks, Owen DeLong IPv6 Evangelist Hurricane Electric On Oct 22, 2009, at 5:08 AM, Frédéric wrote:
please full support huricane !
De-peer your ipv6 peering cogent/telia or max prepend it.
!
Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen <ras@e-gerbil.net
wrote:
On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being attempted:
http://www.flickr.com/photos/77519640@N00/4031434206/
(and yes, it was yummy and enjoyed by all at the peering BoF!)
So Cogent...won't you please make nice with HE.net and get back together again? ^_^
Matt (speaking for neither party, but very happy to eat cake nonetheless)
"Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :)
And now even better shots of the cake have been forthcoming from people. :)
http://www.flickr.com/photos/77519640@N00/4031195041/
(I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory).
Fortunately, I did get to partake in the eating of it. ^_^
Matt (This cake is great, it's so delicious and moist...* ;)
*http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
yes of course, sorry my wrong use of english. Le jeudi 22 octobre 2009 à 05:19 -0700, Owen DeLong a écrit :
Please don't break existing connectivity in an effort to show support for Hurricane.
That's going in the wrong direction and it doesn't help the users of the internet, your customers, or ours.
Please do continue to, or start peering with Hurricane.
The internet works best when people peer. Breaking or damaging that in any way is not helping any of our customers and it is contrary to Hurricane's desire.
We appreciate the intended message of support, but, it's most important to preserve functionality for all of our customers.
Thanks,
Owen DeLong IPv6 Evangelist Hurricane Electric
On Oct 22, 2009, at 5:08 AM, Frédéric wrote:
please full support huricane !
De-peer your ipv6 peering cogent/telia or max prepend it.
!
Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen <ras@e-gerbil.net
wrote:
On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being attempted:
http://www.flickr.com/photos/77519640@N00/4031434206/
(and yes, it was yummy and enjoyed by all at the peering BoF!)
So Cogent...won't you please make nice with HE.net and get back together again? ^_^
Matt (speaking for neither party, but very happy to eat cake nonetheless)
"Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :)
And now even better shots of the cake have been forthcoming from people. :)
http://www.flickr.com/photos/77519640@N00/4031195041/
(I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory).
Fortunately, I did get to partake in the eating of it. ^_^
Matt (This cake is great, it's so delicious and moist...* ;)
*http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
participants (28)
-
Adrian Chadd -
Brandon Galbraith -
Bret Clark -
Charles Wyble -
Christopher Morrow -
Dave Temkin -
David Conrad -
Frédéric -
Igor Ybema -
Jeff McAdams -
Joel Jaeggli -
Kevin Loch -
Leo Bicknell -
Marco Hogewoning -
Mark Andrews -
Matthew Petach -
Mike Leber -
Nathan Ward -
Owen DeLong -
Patrick W. Gilmore -
Phil Regnauld -
Randy Bush -
Randy Epstein -
Richard A Steenbergen -
Seth Mattinen -
Steve Bertrand -
Valdis.Kletnieks＠vt.edu -
William Pitcock