recent update from ARIN

Tim Wolfe wrote:

> > Subject: Lowering of minimum allocation from /19 to /20
> >
> > .... more should be on the ARIN web site soon...
> The announcement is now on the ARIN website (
> However, this policy change will not go into effect until February 8th.

Anyone from Sprint and/or other providers who filter non-customer routes
based on /20 and longer prefixes care to comment if their filtering policies
will change to reflect the new Arin policy?

Comments won't matter. Actions will. Address space sized /20 simply
cannot be announced as part of a larger block by an upstream provider
for the obvious reason that the adjacent parts of the /20 _MAY_ be
allocated to someone else who uses a different upstream. Should it be
the case that ARIN allocates a /20 by holding the /19 it is within for
a while, then announcing the /19 can indeed get by the filters. But
this is NOT the same policy that ARIN has had for a while which did
allow allocation of a /19 to someone that temporarily only qualified
for a /20. It is fully conceivable that a /20 may be the final space
some providers ever need. I can still give examples where a business
will need multi-homing and less than a /24.

ARIN could help deal with this by putting these /20 allocations within
a range of addresses not used for larger blocks. Then it should be
possible for Sprint and others to _not_ block /20's in that range much
as that (supposedly) do not block some of the classic class C's in and
around 192-193 that still remain. If this is done, then those who do
this kind of filtering won't have as an excuse the "need" to filter out
all those other /20's they get.

It would be great if ARIN could impose some kind of requirement that
providers not filter any allocations ARIN makes (aside from specific
reasons for specific prefixes or ASNs that are technical problems,
such as spam or smurf sources). But I doubt if they can really do it.