Start accepting longer prefixes as IPv4 depletes?

George Bonser gbonser at seven.com
Wed Dec 8 19:01:43 UTC 2010


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

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.  

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.

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.





More information about the NANOG mailing list