Policy Statement on Address Space Allocations
Daniel Karrenberg Daniel.Karrenberg at ripe.net
Thu Jan 25 11:47:36 CET 1996
> Tony Li <tli at 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
[ lir-wg Archives ]