Policy Statement on Address Space Allocations

But still, sorry that it wasn't as smooth as it could
have been if there hadn't been a flaw in the filtering
that crept in in about April, long before anyone was
even really thinking of allocating from

However, as I think everyone remembers, after a short while,
in an effort to assist in getting aggregation of the
then-announced bits of working OK and giving
people some time to get used to the filtering, I did relax
the filtering on to permit /19s.

As you note, this was to the benefit of other peoples' customers.

the real message is if you have a 206+ address, make sure that your
provider can put it into an aggregation block for you (or go to sprint).

Right, and we have been warning our customer base for
some time that if they announce a 206+ address that is
not aggregatable into something reasonably big (like a /18),
they run the risk of losing connectivity to other providers
if they ever were to impose similar filters for business
or technical reasons.

Lets take a real world example between Sean's and Daniel's arguments.
I am the registry of Last Resort for Israel and I assign CIDR blocks
to ISPs here in Israel. I follow the slow start model of RIPE
and give initially a /22 and then a /21 and then a /20, etc. One new
ISP in Israel wanted more address space and found that Net99 (all ISPs
have to connect to an ISP in the USA due to Israeli gov't regulations)
would give it a /21 from and later Agis gave it a /19

So we have now an ISP that circumvented the allocation policies and
went to the USA to get cheap, large blocks at possibly an expense
of them not being portable and/or not routable even if it is
portable in the future.

The smaller, new ISPs that don't know even what questions to ask will
get stuck more and more by this type of situation. We can't do anything
about that. But we do need a better GLOBAL policy for IP address allocation
that everyone adheres to (perhaps I am asking for utopia).


Hank Nussbacher