[118118] in North American Network Operators' Group
Re: IPv6 internet broken, Verizon route prefix length policy
daemon@ATHENA.MIT.EDU (David Conrad)
Mon Oct 12 20:41:32 2009
From: David Conrad <drc@virtualized.org>
In-Reply-To: <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com>
Date: Mon, 12 Oct 2009 17:40:36 -0700
To: Owen DeLong <owen@delong.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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. =20
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
