On Dec 8, 2010, at 12:01 PM, George Bonser wrote:
Actually, in most implementations, due to optimizations with IPv6 that aren't possible with IPv4, a v6 route only takes about 2x the resources of an IPv4 route.
I considered that before I wrote the 4x but I couldn't be sure that my implementation was typical so I stuck with the worst case. It also depends on where you are talking about, RIB, FIB, or cache.
FIB being the only place where there are meaningful resource constraints, I'm willing to treat it as the bottleneck. Most routers can handle several million paths in the RIB and cache overflows shouldn't be fatal if you have sufficient FIB resources.
Additionally, IPv6 should go from a ~10:1 ratio of prefixes to ASNs to a ratio closer to 1.5-2:1. As such, I only expect the IPv6 table to be about 10-20x it's current size at full deployment. Significant, but, hardly what I would call an explosion.
Maybe. There are currently 36178 ASes announcing routes in v4. There are 2882 ASes announcing v6 routes. Assuming that every AS currently in v4 will eventually appear in v6 and also making an assumption that each AS in v4 will announce at least one route in v6, that would indicate at minimum a 12x growth above today. Once you get into deaggregation of PA space to accommodate multihoming or disconnected PI sites, all bets are off but 20x seems a reasonable start.
Even at 20x (I think 15x is a more reasonable guestimate), I still wouldn't call it an explosion. 20x 3843 = 76,860 total IPv6 routes. even at 4x resources, that's less than the current IPv4 table (~340k routes). At the more realistic 2x, it's dramatically less.
People running routers with less than 1MM IPv4 prefix capability probably can use defaults to cover for discarding some of the longer prefixes.
Yup. And that is where I was going with "their multihoming in PA space might not work as well as it used to" when that sort of thing happens on a broader scale.
Actually, the people with the smaller routers are probably far enough away that it won't matter. This will only have negative impact on remote hosts that are on the same side of the closest common major transit provider.
Generally speaking, those are not major transit backbones where this would be harmful. (Major transit backbones have been out of room in such routers for some time now).
Yeah, I was considering networks like mine where I am trying to talk to a multihomed site that I am not directly peered with and one transit provider has some peering issue and loses a route to that destination. I need to be able to "see" that route via the other transit provider(s) in a hurry so a default probably isn't going to work well for me though I will be tempted to move in that direction once I come under resource pressure.
If both of your transit providers are default-free, then, likely the default will still work fine. It may not be optimal, but, it'll probably be functional in the vast majority of cases.
Compromising in IPv6 won't buy much, so, I suspect the compromises will have to be made in IPv4. (let's face it, there's just not much there in a <60k route table to reduce).
And I don't think anyone is going to *want* to compromise in v6, v4 is where they are going to begin to trim back as that is a dead-end path anyway. Compromising on the v6 side is going to generate an increase in problems going forward. Compromising on the v4 path will produce a decreasing amount of problems over time. The downhill path is the easiest to follow.
Compromising in v6 temporarily to preserve v4 functionality may be necessary in some cases. I'm not wiling to rule anything out at this point.
People are doing this in IPv6? Really? What's the point? There simply aren't enough savings to make it significant.
There was some chatter on this list of Verizon, for example, not taking smaller than a /32 out of PA space (but accepting down to a /48 in PI space). I don't have access to their routes so I can't say with any authority, I am repeating what was posted here by others.
Oh, yeah, that's JUST Verizon, and, I think they've started to get over that religion as well. However, now you're talking about the only provider on the planet with >1MM route capable routers that are actually overflowing due to the utter mess that is their intra-AS routing topology. Owen