Policy Statement on Address Space Allocations

Please excuse me for butting in on a argument the political background of
which I know very little, but this was directed at local-ir so:

<snip>

> If you have some technical means by which you can
> guarantee that no future allocations will result in 
> rafts of unaggregated addresses like the random chunk
> cut and pasted above, then I would like to know about it.

<snip>
 
> I don't disagree that historically RIPE's allocation 
> policy has been *excellent*.  However, there are two
> problems: firstly, it is insufficient in and of itself
> to prevent things like the stuff above, and secondly
> there is a disconnect between allocations and announcements.
> 
> So, let's kill two birds at once: first, an enforcement
> mechanism to push people into announcing only one prefix
> per allocation, and second, increase the size of the
> initial allocation, which will tend to push people away
> from RIPE as the registry of first choice.

Problem 1: Smaller local-ir's with their own AS's cannot get windows
larger than /19 from RIPE. If they need more than a /19 and request them
non-simultaneously the /19s are not likely to be adjacent and hence
aggregatable. If Sprint or anyone else refuse to accept /19 announcements,
there is no way such local-IR's can get their IP numbers routed. For
instance our announcement contains a /19 which is adjacent only to
allocations nothing to do with us.

Problem 2: Historically the breaking up of RIPE windows/allocations
between different AS's has lead to a multitude of tiny announcements.

Problem 3: Some ISPs have been lazy in the aggregation of routes on their
router.

How about: Each window that RIPE dish out (currently never smaller
than /19) must have an AS number associated with it in the RIPE
database before any allocations from that window are 'legal'.
All announcements of address within that window must be made a single
aggregated announcement covering the entire window (or more if there
happens to be an adjacent allocation) which originate in the associated
address. This fixes the PA addresses issue (with the slight complication that
providers could theoretically need one window per AS, but this would help
aggregation anyway). New PI addresses I couldn't really care less if Sprint
etc. don't carry them, but essentially as long as they fall in an entire /19
with associated AS object they culd fall under the same scheme. The only
legitimate reason for new PI addresses as far as I am concerned is to issue
to small-ish organizations who are not local-ir's and are not multihomed, and
will want /19 or thereabouts. Solves problem 1 IMHO.

A time limit could be proposed where the above could be enforced
for the rest of 193.* & 194.*, with RIPE cooperating to help existing
providers renumber. Solves problem 3.

Which just leaves (2) (historical - like most of 192.*). Well at least this
problem won't grow.

Alex Bligh
Xara Networks