Start accepting longer prefixes as IPv4 depletes?

Wed Dec 8 20:01:12 UTC 2010

> 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