Start accepting longer prefixes as IPv4 depletes?

Wed Dec 8 18:59:16 UTC 2010

On Wed, Dec 8, 2010 at 10:30 AM, Iljitsch van Beijnum
<iljitsch at muada.com> wrote:
> (My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.)
>
> As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like.
>
> Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.)
>
> 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.

Just because we've been treading water as fast as possible to try to stay
above the drowing point in small prefix ranges does *not* mean we have
extra headroom to waste on even smaller ranges.  I've started contemplating
filtering out blocks smaller than /22, and trusting that somewhere, someone
will be sending out a supernet that covers the smaller bits.

As has been said elsewhere, previously; just because you have been
allocated IP space does *not* in any way, shape, or form guarantee
routability and reachability.  The smaller your chunk of space, the less
likely it is that other people will choose to listen to it as something discrete
from the supernets that may cover it (up to, and including default).

You are free to announce whatever small prefix size you would like
already, today.  However, it is unlikely anyone thinks so poorly of
their routers as to blindly accept any and all such small prefixes
from the internet at large.  It is unlikely you will get much traction
in getting those filters updated, due to the increasing stress todays
routers are under.

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

Just move to v6, already.  v4 is done.  trying to keep it on life support
is going to cost everyone time, money, and reduced life span due to
increased stress.

If you have not informed your senior executives that the IPv4 space
you have today is likely to be all that you will ever have, as a techie,
your are doing your company a disservice.  If you have not informed
them that in order to expand their business at all in the future, they
will need to be prepared to do so using IPv6, and not IPv4, you are
doing them a disservice.

For new entrants into the market, who want to dip their toe into content
hosting, but do not have IPv4 addresses of their own--work with an upstream
provider, and get a rent-a-block of v4 from them.  Get your primary
infrastructure on IPv6, and use a rent-a-block of v4 space from an
upstream to host a 4-to-6 proxy box to allow legacy v4 users to reach
your content.  I'm partial to http://trafficserver.apache.org/ myself as
a v4/v6 proxy platform, but you can pick any platform you like.  Configure
your DNS to return quad-As that point to your real v6-based infrastructure,
and configured the A record to point to your v4/v6 proxy box.  All done.
No need for anyone else to have to accept little tiny chunks of v4 space.

>
> I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.
>

Sorry...can't help you on that front.  :(

Matt