[1514] in North American Network Operators' Group
Policy Statement on Address Space Allocations
daemon@ATHENA.MIT.EDU (Daniel Karrenberg)
Thu Jan 25 06:09:20 1996
To: Tony Li <tli@cisco.com>
Cc: forrestc@imach.com, postel@isi.edu, nanog@merit.edu, cidrd@IEPG.ORG,
iepg@IEPG.ORG, iab@isi.edu, iesg@isi.edu, iana@isi.edu,
Local Internet Registries in Europe <local-ir@ripe.net>
In-Reply-To: Your message of Wed, 24 Jan 1996 23:30:19 PST.
<199601250730.XAA13024@greatdane.cisco.com>
From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net>
Date: Thu, 25 Jan 1996 11:47:36 +0100
> Tony Li <tli@cisco.com> writes:
>
> To be more specific, the RIPE NCC has been using a policy such that it will
> (at most) grant a prefix one bit shorter than the prefix that has been
> used. Under this policy, it would be reasonable to ask for a /17, tho I'm
> not saying that you necessarily can prove the growth to support it.
I wonder where that rumour comes from. It is certainly not the RIPE NCC
allocation policy. this is a good time to set the record straight on this
and related things. This is *not* an attack on Tony who, I am sure, was
quoting some rumour in good faith.
Our basic allocation policy is:
1) The initial allocation for a newly established local registry (ISP)
*always* is a /19. There will be no discussion about this.
This is fixed, cast in stone, immutable, ... you get the idea. In
particular it will not be influenced by marketing predictions, amount of
capital available or the shoe size of the lawyers visiting our offices.
(NB: The value of /19 might change at some point, but the fact that
every newly established registry gets *the same size* initial allocation
will not.) The reason for this policy is to avoid very lengthy,
fruitless and frustrating discussions about the size of initial
allocations which end up in expensive (in time and nerves) but basically
arbitrary decisions.
2) After the initial /19 further allocations will depend *solely* on the
usage rate of the particular registry. These allocations can currently
be *anywhere* from /19 to /16 depending on the usage rate.
Supernational registries may under certain conditions have more than one
/16 allocation. The established usage rate is an objective criterion to
determine the sizeof further allocations and our experience shows that
we have very few discussions about allocation sizes.
Now, as Forrest points out, this makes it desirable for each ISP to have
a high usage rate. So local registries may be tempted to use more than
needed. This is where the assignment policies come in to make sure that
the conservation goal is respected. After all the usage rate is
determined by *valid* assignments only. Our assignment policies and
procedures provide strong incentives for registries to act prudently and
and correctly.
Note that we make /19 allocations even though one particular ISP is
telling the world that /18 is the minimum you ought to have these days.
Our experience suggests that /18 is too much to assign to any newly
established local registry. It is too wasteful. On the other hand we
cannot live without policy #1. So we decided to stick to /19s.
The same ISP has said publicly that they will route /19 prefixes in our
address space: 193/8 and 194/8. The discussion is still going over
future /8s. But read the last paragraph of the policy statement!
It should be noted that additional allocations are very often
aggregatable with previous ones. So the number of /19 prefixes
announced will decrease over time. I personally expect that we can
reach *very* acceptable aggregation levels and current statistics
support that:
Routing Table
router: amsterdam.ripe.net
time: Mon Jan 22 11:06:13 1996
Destinations: 32934 Routes: 32934
/8 block hosts routes hosts
addres- /
sed route
192.0.0.0 4981504 6551 760
193.0.0.0 9264640 2019 4588
194.0.0.0 7665920 1849 4145
195.0.0.0 256 1 256
196.0.0.0 731648 329 2223
197.0.0.0 256 1 256
198.0.0.0 7488000 3705 2021
199.0.0.0 8838144 3338 2647
200.0.0.0 4660736 697 6686
201.0.0.0 256 1 256
202.0.0.0 4258496 1460 2916
203.0.0.0 5831424 780 7476
204.0.0.0 10499072 3660 2868
205.0.0.0 6019584 1793 3357
206.0.0.0 10967808 1649 6651
207.0.0.0 1019136 37 27544
C Space 82226880 27870 2950
It should be noted that we have started allocating hierarchically from
193/8 when the InterNIC was still using 192/8. So we feel that we have
quite a good track record concerning routing aggregation and address
space conservation too. We consider our policy a good compromise
between aggregation and conservation and our community backs this
policy.
Daniel Karrenberg
RIPE NCC Manager
