Why does Sprint have address filters again?

Roeland M.J. Meyer writes...

>>There is a definite business case for portable /21's. First off, I
>>understand the technical need to limit ASN's to /19's so I don't need
>>lecture #101. However, those limits were set quite some time ago. When can
>>we reduce them? Has technology stood still?
>You understand "the technical need to limit ASN's to /19's"? I don't,
>perhaps you could explain it to me.

I agreed to the stipulation, in advance so I wouldn't get lecture #101, yet
again. The issue here is that ASN's get around prefix filtering, to my
understanding. If everyone had an ASN then we'd be right back to they
problem that started prefix filtering in the first place, ever growing, and
humongous, router tables. Legacy routers have problems with this.

There are two basic problems:

1. The number of available ASNs is finite and usage is growing.

2. The number of route prefixes impacts on router performance and is
    growing rapidly.

The greatest concern seems not to be #1 but instead #2. The idea of limiting
prefixes being honored to /19 and shorter is one approach to limiting the
number of prefixes. However, this tactic has the counterproductive effect
of discouraging smaller (and more numerous) providers and businesses from
being efficient in their usage of IP address space, for networks that need
less space than a /19 allows.

We can suggest that this /19 boundary be changed. Moving it to /18 would
further reduce the number of prefixes, but create more demand on IP space.
Moving it to /20 would decrease the demand on IP space, but increase the
number of prefixes.

What we need is a solution where we don't have to make tradeoffs between
increases in the number of prefixes and increased waste of IP space.

The prefixes glut comes from two different situations. One of them is
the increasing number of autonomous, or multi-homed, networks. The other
is the multitudes of un-aggregated and unaggregateable prefixes being
announced in each AS. IPv6 may make it easier to eventually do all the
aggregation that is needed, but it would NOT decrease the number of
distinct autonomous networks that need to separately announce.

If IPv6 allocates space in differing sizes (for example, UUNET may be
given a /64 with 18446744073709551616 addresses, but MOM-AND-POP.NET
maybe be given "only" a /80 with 281474976710656 addresses) we are still
going to see network size bias and discrimination when it comes to
filtering route prefixes. People will find (very clever) ways to use up
their /80 so they can then ask for maybe a /64.

If IPv6 allocates everyone the same exact network size (for example /64)
no matter how big or small they are, it can end the bias and discrimination.
We'll still have lots of routes, but at least in this case we could have
just one route prefix per entity. Still, very large businesses could ask
for multiple blocks or even large blocks for reasons of doing various
strategies of network partitioning, and the problem of routes comes back
since we'll either have varying sizes of prefixes (and the bias) or we'll
have multiple prefixes (and the glut).

While IPv6 needs to be considered, the immediate problem is still IPv4.

One idea I had that could reduce the number of prefixes would be to make
some limit on the number of prefixes per AS. This could be either a flat
limit on the number of prefixes, or a partitioned limit on the number of
prefixes per each size (same in each size). I like the latter because it
does discourage keeping multitudes of small network pieces (which is
probably why prefix filtering really got started in the first place).
Unfortunately, access lists are not smart enough to count prefixes per AS
to apply a limit, so some new code would have to be added to the BGP logic
in the routers to do this. I would suggest the default limit be set at
2 prefixes per prefix size /17 through /24, with a total limit of 5 prefixes
in this whole range, and no limit (for now) on prefixes of /16 or shorter.
It may be necessary to exclude certain network block ranges from these counts.

The best solution distributes the least information level for each autonomous
network. Unfortunately, ASNs do not alone provide enough information so we
still have prefixes. I wish there was a way out of that. I did develop an
idea along those lines a couple years ago. But it is probably too late to
do something like that in IPv6 now.