Re: Start accepting longer prefixes as IPv4 depletes?

[Owen DeLong <owen () delong com>]

On Dec 8, 2010, at 11:01 AM, George Bonser wrote:

> > There are two issues:
> >
> > 1. Growth of the routing table. My answer to this is: although a
> > smaller table would be good, we've been living with 16% or so growth
> > for a decade before the IPv4 crunch, if going to < /28 instead of <
> /24
> > allows this growth to continue some more years there is no additional
> > harm. And there is no evidence that /28s will create more growth than
> > unconstrained /24s like we had before the IPv4 crunch.
> >
> > 2. People who think it's neat to deaggregate their /16 into 256 /24
> > will now go for 4096 /28s. To avoid this, the new /28s should come
> from
> > separate ranges to be identified by the RIRs. So /28 would only be
> > allowed for this new space that is given out as /28, not for anything
> > that already exists and was thus given out as much bigger blocks.
> >
> > Thoughts?
>
> Growth of the routing table will be a much larger issue once the
> stampede to v6 occurs.  A v6 route takes 4x the resources of a v4 route.
> Assuming everyone multihomed in v4 space will also be multihomed in v6
> space and assuming that people are going to operate in both v4 and v6
> space at the same time, not only will the v4 table explode in size as it
> fragments, so will the v6 table explode in size at the same time.
> Granted there will be some consolidation through aggregation with v6 and
> entities who have multiple discontiguous v4 nets might consolidate into
> a larger v6 bloc but nevertheless, they are going to have announcements
> in both spaces.
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. 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.

> People dual-stacking that have routers capable of <1 million v4 routes
> are going to have to rethink their strategy if they are currently
> collecting full routes in both v4 and v6.  If compromise must be made,
> where is one to make it?  I believe that will happen with v4 because v6
> will be seen as where the growth is and where the future lies and v4
> seen as "legacy" and if one must compromise, compromise where you see
> future decline, not where there will be future growth.  
People running routers with less than 1MM IPv4 prefix capability
probably can use defaults to cover for discarding some of the
longer prefixes. 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).

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

> So, imagine a multihomed end site announcing a chunk out of one of their
> provider's PA space where they have that provider de-aggregate that
> route because the more specific is also being announced by one or more
> other providers.  I believe the first place where compromises might be
> made in such cases is "I am not going to accept more specifics from PA
> space but I will accept small blocks from PI space".  Some do that today
> in v6 space but I have a hunch that will begin to happen more in v4 as
> it begins to fragment and people become resource constrained.  The
> result will be that some sites might find that their multihoming using
> v4 PA space isn't working as well as it used to, which will provide yet
> greater incentive to move to v6.

People are doing this in IPv6? Really? What's the point? There simply
aren't enough savings to make it significant.

> To summarize:  I believe it is going to be more difficult to get people
> to accept route announcements for smaller v4 blocks as the v6 table
> ramps up if they are dual-stacking v4 and v6 on the same gear.  Put
> another way, I don't believe there is going to be a lot of support in
> bending over backwards to support yet more v4 brokenness or if the
> support is there in theory, there may not be as much support in practice
> once the herd begins to move to v6 and v4 starts to shatter into little
> tiny fragments.
Let's hope that's how it goes. The alternatives are significantly bad.

Owen