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.
