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

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