Run Out Fairly

Summary of Proposal:

This is a proposal to gradually reduce the allocation and assignment periods in step with the expected life time of the IPv4 unallocated pool in order to address the perception of unfairness once the pool has run out.

The proposal is not intended to stretch the lifetime of the unallocated pool.

The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently of these.

In order to avoid possible oversight or confusion, we point out this proposal makes the time periods governing allocations and assignments identical immediately upon adoption. Both periods will then be reduced according to a fixed time scheme.
The assignment utilisation rate requires 50% utilisation not, as formerly, after one year, but rather at the halfway point of that period and there is no longer a specific target for the immediate utilisation. See below for the rationale behind this.

a. Arguments Supporting the Proposal

As the RIPE NCC IPv4 unallocated pool runs out, the current policy will allow for the very last allocations to be made for the purpose of deployment up to 12 months afterwards. Once the unallocated pool has run out, there will be some users that just received up to 24 months worth of address space and some who will receive nothing. This will very likely cause concerns because a quite valid perception of this event is that one user will be able to grow their business for another 12 months, while the next one in the queue will be stuck. There is also a real potential for a very large address space user to receive a huge allocation under this policy which pre-empts a lot of requests from smaller users; this will greatly increase the perception of unfairness.

RIPE and our self-governance could very well come under serious adverse criticism if this happened. We would appear to be have been quite careless and short-sighted in the eyes of those who perceive this unfairness. There are some scenarios where a large number of RIPE NCC members would feel this way, as would governments and regulators.

During RIPE 57, one of the proposal authors presented this rationale during the Address Policy Working Group.

The feedback in that session suggested that this concrete proposal be developed.

The principle of distributing address space according to demonstrated need is sound and should not be changed. In order to address the unfairness, we propose reducing the period over which the need is recognised roughly in correlation with the expected lifetime of the unallocated pool. This addresses the unfairness without abandoning the principle.

The same principle should apply to assignments for both Provider Independent (PI) and Provider Aggregatable (PA) address space for End Users that can be made directly by the RIPE NCC or the LIRs.

The exact date of the exhaustion of the RIPE NCC's IPv4 unallocated pool is hard to predict. It will also be influenced by other policy changes that are currently being discussed. A widely-accepted projection of unallocated pool exhaustion dates is published by Geoff Huston, Chief Scientist of APNIC.

His projection for the exhaustion of the RIPE NCC pool can be found at:
http://www.potaroo.net/tools/ipv4/fig29b.png

The timeline proposed here aims to set a schedule that roughly follows these projections and is simple and predictable at the same time. No one can predict the actual point in time when the RIPE NCC pool will be exhausted. We propose not
to base policy on changing predictions, but rather to decide on a reasonable schedule today that is fixed now and thus predictable.

We stress that this proposal aims to address only the perceived unfairness we outline above. The proposal explicitly does not aim to increase the lifetime of the unallocated pool nor to address any other issue.

The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently of these. In particular, there is no inter-dependency with “Use of final /8” (2008-6). The time schedule of this proposal need only be updated if further policy changes drastically change the expected date of exhaustion of the unallocated pool.

Note well that the proposal sets higher allocation rate targets consistent with allocation and assignment sizes immediately on adoption. There no longer is a requirement for 'immediate' utilisation of 25%. The rationale for this change is twofold: firstly, it aligns both periods, which makes application of this policy significantly more straightforward than it would otherwise be; secondly, it sets a goal for assignment utilisation halfway through the period rather than at the beginning and after the fixed period of one year. This is based on feedback from the RIPE NCC Registration Services staff.

b. Arguments Opposing the Proposal

Some may argue that reduced allocation and assignment periods will be too short to sustain efficiency in routing and ISP, provider and LIR operations. However, we believe that towards the end of the available IPv4 pool, it is the responsibility of all to make sure the allocation and assignment of the resources remain perceived as “fair”.

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy may have if the proposal is accepted and implemented.

A. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

If adopted, the proposed policy will have no lasting effects on the average rate of IPv4 address consumption. As long as the RIPE NCC has a large enough pool to accommodate all requests, LIRs will receive the number of addresses they need. However, as the planning horizon is gradually shortened to three months, the allocation rate will need to be smoothed over time. A single request for a /16 to be used over a period of 12 months will be replaced by four requests for a /18, each to be used in a period of three months.

Reducing the default allocation and assignment period (in three steps) to three months also means that, in the RIPE NCC service region, the industry as a whole will run out of unassigned IP addresses shortly after the RIPE NCC registry runs out. In principle, no LIR will have an excess amount of free addresses left from previous allocations to grow their business for more than three months.

Fragmentation/Aggregation:

When adopted, the proposed policy will create more fragmentation in the routing tables. IP addresses will be assigned and allocated in smaller blocks which, separated in time, are unlikely to be adjacent to each other. Compared to current policy, the same amount of address space will have less potential for aggregation.

The exact impact of the proposed policy is difficult to assess because it depends on many dynamically changing factors, including:

• How much address space is left on 1 July 2011 (the date on which the RIPE NCC begins making allocations based on a planning period of three months)
• The number of LIRs returning for an additional allocation or requesting a first allocation larger than the minimum allocation size
• The number of direct PI assignments made by the RIPE NCC

We can, however, make an estimate about the maximum potential impact, based on the following scenario:

During the 12 months following 1 July 2011 (when RIPE NCC will be allocating for a period of three months), the RIPE NCC makes:

• 2000 IPv4 allocations (in 2008 RIPE NCC made 1612 allocations) [*]
• 2500 IPv4 PI assignments (in 2008 RIPE NCC made 2172 assignments) [*]

If we assume that all the holders of these resources would have to receive the same amount of address space in multiple periods of three months after 1 July 2011, they would receive them as 8000 allocations and 10,000 assignments. If all of these blocks were to be routed, 13,500 additional entries would appear in the routing tables over 12 months time. This is less than 5% of the size of the current default free table. [**]

B. Impact of Policy on RIPE NCC Operations/Services

If the proposal is accepted, we expect that there will be an increase in the number of requests received by the RIPE NCC's Registration Services. As the planning horizon is gradually shortened to three months, the same amount of address space will be obtained as several smaller allocations, resulting in more requests to be processed.

Provider Aggregatable (PA) Allocations

If we take the 2009 allocation data and extrapolate a three-month allocation period, we can expect to see an increase of about 65% in allocation requests, assuming all allocations will be half the size and then a quarter of the size of a request that would be for a full 12 months (and keeping /21s as the minimum single request for all periods).

Provider Aggregatable (PA) Assignments

The size of the PA assignment requests will grow smaller as the planning periods are reduced. We expect that this will mean more PA assignment requests will fit within the Assignment Window size of many LIRs. In other words, more assignments will be made using the Assignment Window, reducing the number of assignments requiring prior approval of the RIPE NCC. We therefore expect a decrease in PA assignment requests.

Provider Independent (PI) Assignments

If we take the 2009 allocation data and extrapolate a three-month assignment period, we will see an increase of about 65% in PI requests, assuming all assignments will be half the size and then a quarter of the size of a request that would be for a full 12 months.

Ticket Load

PA Allocations and PI requests comprise about 37% of the Resource Request tickets that the RIPE NCC Registration Services (RS) department receives. A 65% increase in allocation and PI assignment requests would mean around 24% more tickets to process. As these types of requests tend to take more effort to evaluate than other requests, we can expect a significant increase in RS workload if the allocation period shifts to three months.

[*] as published in ftp://ftp.ripe.net/pub/stats/ripencc/2009/delegated-ripencc-20090904.bz2
[**] see e.g. http://www.ripe.net/ripe/maillists/archives/routing-wg/2009/msg00123.html