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.
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.
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.
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.
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.
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. G