Start accepting longer prefixes as IPv4 depletes?

Wed Dec 8 22:23:17 UTC 2010

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