Hi Marco,
Thank you for the detailed information of the dispersion about the current and past of the waitinglist.
To the WG:
The current workings of the IPv4 Waitinglist is specified in the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region
https://www.ripe.net/publications/docs/ripe-733#5
Currently there is a First Come First Serve procedure for the waitinglist .. and there are no limitation to allocating v4 space to members that have been already allocated v4 space since the waitinglist started.
I think that I speak for the WG, that the intent for the final /8 policy and the waitinglist policy, is to provide IPv4 (at least a small bit) to newcomers .. meaning that how it currently works and how it was intended .. that this might not align with what the WG initially wanted.
If a change would be desired by the WG, it should go through the PDP, meaning that a policy change would be required.
As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.
Regards,
Erik Bais
On behalf of the AP-WG Co-Chair collective.
On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces@ripe.net on behalf of mschmidt@ripe.net> wrote:
Dear colleagues,
In the Address Policy Working Group sessions at RIPE 83, I shared our
observations regarding the IPv4 waiting list policy. [1]
The intent of this policy was to provide newcomers with a minimal amount
of IPv4 space for as long as possible. However, about half of these
allocations went to members that received several /24 allocations via
multiple LIR accounts.
As there was interest in reviewing the policy at the RIPE Meeting, I
would like to provide more detail on the provision of IPv4 allocations
over the last two years and the current situation with the waiting list.
In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
- 2,019 allocations (48%) went to members with a single LIR account
- 452 allocations (11%) went to members with 2-4 LIR accounts
- 298 allocations (7%) went to members with 5-9 LIR accounts and
- 1,409 allocations (34%) went to members with 10 or more LIR
accounts (up to 33 /24 allocations to a single member)
This trend towards allocations to multiple LIR accounts has accelerated
in the past six months. Between June and November 2021, only 24% of
allocations went to members with a single LIR account, while 54% went to
members with 10 or more accounts.
We see the same trend with the current waiting list. At the time of
writing, we can see 327 requests for a /24 allocation:
- 83 (25%) are from members with a single LIR account
- 42 (13%) are from members with 2-4 LIRs accounts
- 45 (14%) are from members with 5-9 LIR accounts
- 157 (48%) are from members with 10 or more LIR accounts
Consequently, there is a significantly longer wait time for members with
a single LIR account.
Looking at the current market prices for IPv4 in comparison to our
membership fees, even a wait time of several months is acceptable for
organisations that plan to transfer their allocation after the end of
the holding period. Conversely, the long wait time will create
uncertainty for real newcomers, especially if they can’t rely on
IPv6-only networks.
I hope the WG finds this information useful for further discussion. If
there is consensus to change the current situation, there are several
approaches available – including a review of the waiting list policy and
changing ‘per LIR’ to something else. Other approaches, such as a
different charging scheme or changing the concept of multiple LIRs would
need to be approved by the RIPE NCC membership.
Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC
[1] https://ripe83.ripe.net/archives/video/642/
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg