I don't want to change policy for last /8, and I aggree with it. Current policy can be read by several ways. We're just playing with words - current policy doesn't force making single /22 allocations from other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to allocate something from 185.0.0.0/8, you can do only do this and this..." in my eyes. Section 5.6 talks just about the last /8 and this is quite clear description. Last /8 is single address block. If some address space is returned, then I don't see any reasonable argument, why not (re)allocate more than /22 to someone else, if someone needs new addresses and meets other criteria. Final decision is still on RIPE NCC - and I think they can better analyse particular case in time of real occurrence - compared to general "what-if" proposals. Maybe we can serve only new LIRs in that case, that's limitation which should be accepted - that's question. This will make startups easier - well, IPv6 is solution, but until will be IPv6 adopted by large networks/content providers having large IPv4 allocations already - these aren't under pressure, if we're talking about IPv6 migration. Even small starting ISPs will need IPv4... why restrict allocations to new networks, if there's space other than from last /8 available? Just because they came too late...? This kind of restriction/regulation will more likely support grey market - people will be trying other ways to "sell" their existing allocations to someone, who needs them (and of course, they'll find policy-conforming way). Reserve in last /8 is quite enough to cover future requirements for very long term and there's no need to block address usage in other /8 managed by RIPE NCC. Your proposal simply creates additional blocked and efectivelly unused address space in other /8 just due to the policy. RIPE NCC is here for address distribution to end users. I'm just using arguments of Remco now - addresses should be used, not reserved for something surreal. Daniel On 05/23/2011 01:34 PM, Remco Van Mook wrote:
Hi Daniel,
The beginning of article 5.6 in the current policy reads as follows (emphasis mine):
"The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space WILL ONLY BE DONE as follows:"
This means the current allocation policy is out of the window at that point, and might as well not even exist. There is no point in time where the two separate pieces of allocation policy are both being executed. So, only a single /22 per LIR, no exceptions. This is the currently accepted final /8 policy. If you feel strongly about changing that, I would suggest you write a policy proposal.
This proposal only means to clarify what happens to address space that is returned to the RIPE NCC after that point, and makes sure we have allocation policy in place for all the address space that the RIPE NCC holds. Having a policy in place that provides the ability to hand out all currently held address space, along with an upper limit that is lower than the most common minimum allocation size, will have an impact on the minimum allocation size for those blocks.
If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author.
Best regards,
Remco
On 23-05-11 12:25, "Daniel Suchy" <danny@danysek.cz> wrote:
On 05/23/2011 12:01 PM, Remco Van Mook wrote:
If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. RIPE NCC can handle returned address space in similar way, as it does today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE NCC can (=has other space than last /8)? Normal allocations with standard policy can be processed, instead of carving last /8. There're still other limitations in place - like 6/3month address plans etc. Reserve in last /8 is - in my oppinion - large enough. There's no reason to apply last /8 policy to other address space - this will really only hold available addresses in RIPE NCC without being really used (as last /8 policy is very restrictive).
I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. Based on current numbers of current/new members of RIPE NCC, this will hapen sometimes after 12-18 years? If this will hapen really. In last /8, there's only one /22 per LIR, so it's quite easy calculation. Also I assume, that some LIRs will not apply for their last /22.
If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. That's not argument for making these these things harder compared to current convetions.
With regards, Daniel
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.