Re: Policy Statement on Address Space Allocations
Hi, I see Daniel hasn't answered this one (weekend for some, I guess ;-)
The point is that we will guarantee that our allocation policy will create no more than 1024 allocations per /8 and therefore not necessitate by itself more routes than that. Currently our allocation sizes are /19 - /16. If you think about it a little you will see that it is easy to achieve.
And just in case: Yes the minimum allocation is /19 irrespective of the number of hosts covered. Note: allocation != assignment.
OK, so just to make it clear, if a customer would come to the RIPE NCC and the customer has just 1 host you would still allocated him /19 block. Correct?
This may be obvious to some familiar to the european networking scene already, but anyway... The RIPE NCC itself does in general not deal directly with end customers, only with local registries. To be allocated address space directly from the RIPE NCC you have to first establish yourself as a local registry, pay the startup fee and contribute to the financing of the running costs of the RIPE NCC. Remember, there is noone else than the organizations running the local registries who are picking up the tab for running the RIPE NCC. The typical local registry is also an ISP. Also note the distinction between allocation and assignment made by Daniel which could be lost on some. In this specific case allocation means "address space allocated for a local registry for subsequent assignment to customers". I've seen people critizising the RIPE NCC for their inflexible policies and the practicing of these policies. One important aspect of the RIPE NCC policies when allocating address space to registries is simplicity and uniformity of policy, because one of the worst things that could happen for the RIPE NCC would be for them to rightfully be accused of giving unfair preferential treatment to some registries (=~ ISPs) over others. The chance of this happening (or the RIPE NCC being accused of it) increases with the fuzziness of policies and the amount of evaluation and judgement the RIPE NCC has to apply to individual cases. I think this is fairly accurate, but since this is not coming from the authoritative source I may have made minor mistakes in formulating the above. Regards, - Havard
Havard.Eidnes@runit.sintef.no writes: Hi,
I see Daniel hasn't answered this one (weekend for some, I guess ;-)
Yeah, I went outside with wife and kids. It *is* cold ( -5 Celsius plus wind chill for those still to depart for here).
... I think this is fairly accurate, but since this is not coming from the authoritative source I may have made minor mistakes in formulating the above.
Thank you Havard, as usual you are right on the money. For those interested, the latest and most tutorial writeup of this can be found at ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{ps,txt} Main points again: - the RIPE NCC as regional registry only deals with local registries - local registries are typically operated by ISPs - all local registries share the cost of the NCC (usually prevents the 1 host case) - anyone who commits to the contribution and operational requirements can become local registry - there curerntly are 300+ local registries - local registries determine NCC activities and charging scheme - RIPE (operators technical forum) guides technical work of NCC - allocation = address space held by local registry for assignment - assignment = to end-user for operating network - assignments happen according to assignment policy, different from allocation policy - end-user can be ISP operating registry themselves, i.e. ISP has to abide by assignment policy when assigning themselves address space for their own use - size of first allocation for new registry fixed (currently /19) - size of further allocations depends on usage rate - while we guarantee nothing, we try to make subsequent assignments such that they can be aggregated with previous ones So the answer to Yakhov's "1 host" question is: We will refer them to their service provider. If they insist we will send them the operational requirements, fee schedule and a service agreement. So far we have not heared back from any of the "1 host" cases. Apparently they consider it not worth the hassle. Also there is a natural growth path for ISPs. We have seen quite a few who initially had address space form their up-stram provider and later decided to start operating their own local registry. I have seen them using different strategies for using the original address space. Usually some thoughtful engineering will give them good mileage. While it is not perfect and far from esthetically pleasing it works at the moment. Yakhov: It is amusing to see you argue about the registry system from a tower made of some off-white substance (not unlike the colour of the *real* Cisco routers made from real sheet metal with real fans). I challenge you to propose a realistic distribution/registration method of IPv4 addresses which can be implemented a.s.a.p and does not involve neutrally run registries. With realistic I mean: - rough community consensus - little entropy - transition plan You would make my day. Let's hear it. Daniel
participants (2)
-
Daniel Karrenberg -
Havard.Eidnes＠runit.sintef.no