[address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)

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 at 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.