Start accepting longer prefixes as IPv4 depletes?

Mailman List Mirror (Read Only)
1

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

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?

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

2

(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. :frowning:

Matt

3

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.

4

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.

Exactly. People need to adopt the "v4 is done" mindset and work going
forward on that premise.

5

Dear Iljitsh,

   Do you plan to put /28 into the DFZ routing table? You thought about routing table capacity of the today's routers.., I think prefix length around /22 is accepted, but blindly accepting any /24 prefix is not a reality today. What about the stability of the routing table without aggregation? Do you consider BGP churning?
   Do you think adopting LISP or similar architectures to reduce the problems mentioned above?

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882

6

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

This was discussed at length during the policy discussions at the recent AfriNIC conference. The soft landing policy was passed with a provision to allocate blocks as small /27. Warning labels were pasted all over this but were ultimately overlooked in favour of getting the policy adopted ASAP.

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.

For one think the /24 limit places a barrier to entry on de-aggregation. I don't think that there will be a shortage of prefixes post exhaustion. /24s will be easy to carve out of larger allocations for trading/redistribution.

On the operational side I have come across people who carry partial tables on their networks to avoid spending money on upgrades. One way that they seem to be pruning their tables is to drop long prefixes (just dropping /24 makes a big difference) I suspect that this will happen more as people focus their effort and CPU cycles on making IPv6 work.

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.

Its too late to really be thinking along the lines this kind of structured address allocation IMO. If we ever were to get to /28 allocations they would most likely be from many recovered fragments of address space.

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

I suspect that the operational community would not stand behind this :slight_smile:

7

In a message written on Wed, Dec 08, 2010 at 07:30:52PM +0100, Iljitsch van Beijnum wrote:

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

There is no RIR policy here.

There is no authority which can tell you what length are prefixes
are accepted. Each backbone network makes their own decision on
how to filter their customers and peers.

If backbones find it commercially worth while to accept /28's from
customers and route them, they will do just that. Some will do
it relatively quickly, others will hold out and filter them for
years.

This is not something RIR's, IETF, NANOG, or anyone else can fix,
and in fact they should not try to fix. It will sort itself out,
in due time.

8

+1

Good luck with that /27 of 1.0.0.0/8 space

At the edge, with the down economy, i bet there are plenty of folks
that are only accept /21s and shorter from their upstream ISP so they
can get some more mileage out of their older gear.

Cameron

9

Except that when you have legacy resources (such as /24 end user allocations), there is no supernet announcement since these blocks could technically be anywhere in their respective regions.

10

You're better off taking the mindset that it's time to stick a fork in IPv4,
it's done. Focus your attention on getting LISP or similar adopted for IPv6
before *that* routing table explodes.

11

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

12

Yes.

13

Minimum PI allocation size.

Regards,
-drc

14

Hopefully they have a default route; ARIN now has PI /24 assignments,
and none of those would have a large aggregate announcement.

~Seth

15

No. I still fail to see the value of LISP in a mature and sane IPv6 world.

LISP may have value in a immature and insane IPv4 and IPv6 world.

Cameron

16

Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for futureproofing; there are lots of other benefits as well, for mobility, CDNs, and so forth.

17

At the edge, with the down economy, i bet there are plenty of folks
that are only accept /21s and shorter from their upstream ISP so they
can get some more mileage out of their older gear.

Hopefully they have a default route; ARIN now has PI /24 assignments,
and none of those would have a large aggregate announcement.

Sorry, getting a default route from the provider was assumed in my
mind and not in the email. It goes back to routers that can take only
256k routes ... they cant take full tables these days, so they just
ditch the smaller blocks. The default route still work for
reachability .... but not route optimization at the edge.

Cameron

18

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

19

I still fail to see the value of LISP in a mature and sane IPv6 world.

Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for futureproofing; there are lots of other benefits as well, for mobility, CDNs, and so forth.

I believe a lot of folks think the routing paths should be tightly
coupled with the physical topology. If not, there is MPLS.

If underlying transport is IPv6, i don't see the incremental value
(hence mature IPv6 world comment, most major ISPs are pretty well
along the way). IP Mobility as in Mobile IP already exists .... not
terribly popular.

There is already abstraction within most ISPs with MPLS. Yet another
layer of abstraction is just not something i would consider lightly
with Internet scale. Just my humble opinion.

Today, IPv6 provides real value with larger address space. MPLS
provides real value with FRR and network virtualization (MPLS L3
VPNs). In a mature IPv6 world, that is sane, i am not sure what the
real value of LISP is.

But, IMHO, i do think there is something to the long term value of
ILNP. I am just very biased again additional tunnels,
encapsulation/overhead, complexity, and that is what LISP is, edge to
edge tunnels. Then there is the question of who benefits from LISP
and who pays. The edge pays and the DFZ guys benefit (they deffer
router upgrades).... i already pay the DFZ guys enough today.

Cameron

20

How many networks already leak numerous unnecessary /24s to their
transit providers, who accept them (not having been asked to do
anything else), and contribute to table bloat? Quite a lot of
networks do this.

Imagine if there are many possible inter-domain routes that are being
filtered by transit networks, because their customers accidentally
announce some number of /25-/32 networks to them. These do not affect
us today; but I would hate to see all those accidental announcements
suddenly appear in my routing table; or for my transit providers to
have the bear the expense of dealing with them.