* Marco Schmidt > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges.
I support this proposal. Some random thoughts about it: - It is good to have the policy explicitly say there is a waiting list. Current policy says nothing about this. If the NCC would simply close allocation tickets with «sorry, fresh out, try later», that could encourage LIRs to spam repeated allocation requests in the hope that theirs was the first request to be received after an IPv4 fragment was returned to the allocation pool. - I don't quite believe that the waiting list would grow indefinitely (regardless of the allocation size being /22 or /24). Keep in mind that only new and IPv4-less LIRs would be able to join the waiting list. Once it is known that simply joining the NCC won't guarantee a /22, but that you'd have to wait for one with no certainty as to how long, I expect that the sign-up rate of new LIRs will drop dramatically (and by extension the amount of LIRs queuing up in the waiting list). - It seems reasonable to lower the allocation unit to the de facto smallest usable on the public Internet at a point in time when we can no longer allocate /22s (which are already pretty small). Otherwise recovered /23 and /24 fragments (e.g., PI assignments) will just end up rotting away in the NCC inventory, which serves no good purpose at all. - It seems reasonable to trigger this policy at precisely at a watershed moment like the policy aims to do (unlike 2017-03, which would have changed the rules in the middle of the game). - The authors should clarify how this new policy interacts with the /16 set aside in «5.2 Unforeseen circumstances». In which order does the 5.2 and 5.1bis policies get triggered? Tore
