[address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi,

you still pay only *membership* fee. It's not a per-IP cost, even if it
can look like that. Old resource holders pays similar fee independently
from number of IP addresses they hold.

One of goals is *conservation*, and initial assignment of /24 helps with
that - and not each new LIR really needs /22. There're lot of
organisationss having single /24 (old PI allocations) from the past and
they're still happy with that. These were allocated to end users, are
routed and also nobody concerned about routing table size. Since
posibility of  PI alocations was ceased, new organisations have to
become "full LIR" - and then you receive /22, automatically - even you
don't need it. We're simply wasting limited addres space here - just
because something "simplified" and "automated".

Alocating /24 to new LIRs with keeping possibility to earn up to /22 (in
case of documented need) is solution in my eyes. Old policies worked
perfectly with such system for years - without problems, RIPE NCC has
deep experience with that. Administrative overhead will be minimal, as
RIPE NCC is also running assisted registry checks even for quite new
LIRs (so first iteration of ARC can be done during new request).

With regards,
Daniel

On 09/24/2017 04:38 AM, Kai 'wusel' Siering wrote:
> 2017-03 would change this to "you get a /24" per new LIR, effectively raising the cost of an /24 from ~85 EUR/month to ~173 EUR/month (assuming 36 months to "earn back" the signup fee), but not enforcing IPv6 deployment in any way.
> 
> If we, as the RIPE Community, really want to preserve the scarse IPv4 ressources for "new entrants" to be able to deploy v6, more is needed than just shrinking the assignment: IPv4 *is* done.
> The only use case RIPE NCC should assign new IPv4 address space for is for documented and needed v6 transitions services — and it has to prohibit transfers on this space, as any transfer would nullify the initial use case anyway, therefore opening the path to reclaim the assignment. And to make this setup last even longer, only a /28 should be assigned, as you don't need 256 IPs for a 6-to-4-gateway service anyway (do you, if so, why?). Get this aligned with ARIN and the other RIRs, it should be quite possible to get a bunch of /somethings routed at /28 level.
> 
> But 2017-03 simply raises the cost per /24, without enforcing v6 deployment in any way. It therefore shouldn't pass.