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

Hi Daniel,

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.

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.

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.

Best,

Remco

On 23-05-11 11:41, "Daniel Suchy" <danny at danysek.cz> wrote:

>Hello,
>one thing should be considered here - this proposal in section 3b
>states, that minimum allocation sizes for the relevant /8 blocks will be
>updated if necessary.
>
>There're a lot of ranges with /21 longest prefix now. Some people have
>filters in accordance to (currently) RIPE-510 document. This may be
>source of some operational troubles, if longest prefixes will be changed
>frequently - as filters will have to be updated in some networks.
>There's no such requirement these days (only new prefixes need to be
>added).
>
>I'll rather see no changes in terms of "allowing" longer prefixes in
>other subnets. Changes here will more likely help some people
>deaggregate their prefixes in global table and only few prefixes will be
>announced rightly. Aggregation should be one of major goals, and even
>RIPE cannot enforce it, it at least should help here (and RIPE-510 is
>helpfull). This proposal goes against this goal sometimes, I think.
>
>Last /8 provides quite huge number of /22 to cover future requests
>long-term. I think, that returned space should be reserved/used for
>covering potential request for more than 1024 IP addresses in one block
>- as we cannot imagine future these days, and someone can have good
>reasons to obtain larger address space... and if will be some addresses
>available, I don't see any reason to reject the request.
>
>Due similar reasons - I don't support section 4 of new proposal
>(multiple allocations up to an equivalent of a /22). This will also
>cause changes in RIPE-510 and this will simplify address space
>deaggregation for many "bad guys".
>
>So, instead of applying "last /8 policy" to returned space, reserving
>returned space as we have reserved /16 from last /8 seems to be better
>option for me (and potentially serve assignments like /21). Current
>policies used for reusing returned space are sufficient and these can be
>applied anytime.
>
>Last /8 should be applied ONLY to last /8. And aggregation should be
>always keeped in mind, when some change in address policy is proposed.
>
>I don't support this proposal and I suggest changes in it mentioned above.
>
>With regards,
>Daniel
>
>
>On 05/20/2011 12:11 PM, Emilio Madaio wrote:
>> Dear Colleagues,
>> 
>> A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation
>> and Assignment Policy for the RIPE NCC Service Region", is now
>> available for discussion.
>> 
>> 
>> You can find the full proposal at:
>> 
>>     http://www.ripe.net/ripe/policies/proposals/2011-03/
>> 
>> We encourage you to review this proposal and send your comments to
>> <address-policy-wg at ripe.net> before 17 June 2011.
>> 
>> Regards
>> 
>> Emilio Madaio
>> Policy Development Officer
>> RIPE NCC
>> 
>



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.