[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

Moin,

am 04.02.2019 um 16:02 schrieb Sander Steffann:
> The first comments I got back on this proposal all seemed to miss the point of it. Let me explicitly state what this policy is NOT about:

Thanks for the clarification, but ...

> - it is NOT about conserving IPv4 addresses
> - it is NOT about postponing the runout date
> - it is NOT about extending the lifetime of IPv4

... while this might not be the intention, it's basically the outcome.
 > It's purpose is solely about:
> - dealing with the returned address space the NCC will get over the years
>
> Under the current policy:
> - the waiting list will grow indefinitely

Well, first come, first served. It's not a wise move to start developing Diesel engines these days, nor is it to rely on IPv4. As others already pointed out, even a /22 is tough to start a new ISP business, due to the huge amount of services that still are only available via IPv4 (github.com, pagerduty.com — two random checks, two hits; happily adding the MX for outlook.com to this list of shame).

The waiting list may grow "indefinitely", but only in relation to new LIRs being created. If one will have to bear the costs of an LIR without even roughly knowing when one will receive IPv4 addresses, or if at all, becoming an LIR to farm v4 hopefully will be less appealing. And while being #9999 on the waiting list might sound like a high number, 100k entries should be easy to serve even with sqlite on an Raspberry Pi 1. Read: this can't be a technical issue for the RIPE NCC.

> - the allocations given out will consist of tiny fragments
> - it will therefore not be of any practical use

If the RIPE NCC continues to hand out /24s and /23s up to the equivalent of an /22, i. e. worst cast 4 random /24s, where's the issue?

Ok, I admit that ripe-708 neglects to specify the minimal size of an allocation: "In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request." Thus, *technically* RIPE NCC could fulfill the /22 requirement by allocating 1024 /32s. But to fix _that_, only "not larger than /24" needs to be added after "allocations".

So, yes, ripe-708 needs two updates:

 1. Specify "multiple allocations up to an equivalent of a /22" means multiple /24 or /23 only.
 2. Define that if no /22-equivalent is available at the time of request, the request is appended to an ever-growing FIFO-queue.

But 2019-02 is going too far, it *will* help prolong IPv4 usability, and that must be avoided at all cost. Only if v4-only-services do loose customers because of v6-only, IPv6 adoption may speed up again.

+1 for being *against* 2019-02.

Regards,
-kai

-- 
Kai Siering                        Schalückstraße 107, 33332 Gütersloh
eMail: Kai.Siering at uu.org      Fon: +49 172 863 5608 & +1 781 312 8733
----------------------------------------------------------------------
"Getdate firmly  believes that years after 1999 do not exist;  getdate
 will have to be killed by the year 2000."
             -- From the "Bugs" section of cnews-020592/libc/getdate.3