Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text

Summary of Proposal

This proposal removes the need-based requirement for IPv4 delegations in the RIPE NCC service area. It also incorporates section 5.6 "Use of last /8 for PA Allocations" into the main policy text, removing all references to the "last /8" itself, and to the reaching of it as a future event.

In short, the proposal does the following changes to the active policy:

• Removes "Conservation" as a stated goal of the policy.
• Removes all active policy text referring to documentation, evaluation of need, and validation of actual usage for both assignments and allocations.
• Removes all text referring to the slow-start principle.
• Removes all text referring to the assignment window mechanism.
• Removes limitations on size and frequency of sub-allocations.

The goal that precipitated the requirement to demonstrate need for delegations is explicitly stated in section 3.0.3 of the policy, which reads:

Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented.

Following the depletion of the IANA free pool on the 3rd of February 2011, and the subsequent depletion of the RIPE NCC free pool on the 14th of September 2012, the "lifetime of the public IPv4 address space" in the RIPE NCC region has reached zero, making the stated goal unattainable and therefore obsolete. This proposal attempts to recognise this fact by removing all policy requirements that was working exclusively towards attaining this "Conservation" goal.

The requirement to document need at the lower levels of the distribution hierarchy (LIR and below) made perfect sense when there still was remaining space in the public pools at the higher levels (RIPE NCC and IANA), because excessive delegations at the lower levels would in turn create a higher consumption rate at the higher levels, something would impact all members of the Internet community by reducing the remaining lifetime of, and preventing equal access to, the public free-for-all resource that was the remaining unallocated IPv4 address pool.

Today, however, excessive consumption of the private IPv4 address pools on the LIR levels and below can no longer translate into an increased consumption and reduced lifetime of the remaining public IPv4 address space, since there is nothing left. Simply put: An LIR that uses more address space than it needs to, only ends up hurting itself, and not the rest of the community.

The requirement that all delegations needed to demonstrate need came with a considerable amount of bureaucracy. End Users had to provide documentation to the LIR (and/or the RIPE NCC) that proved their need for address space, and the LIR need to provide similar documentation to the RIPE NCC. In all cases, the documentation had to be thoroughly vetted and archived for later auditing. The need for address space was also artificially limited in time, making it impossible to obtain address space to support long-term business plans. This created extra work for everyone involved. While these negative effects were previously accepted by the community as necessary to attain the "conservation" goal, they serve no real purpose today.

By removing the requirement to document need, each individual LIR will be allowed to decide on and implement its own conservationalist policies according to what makes the most sense for them, for example based on the size of their own remaining IPv4 pool, their typical End User profile, or any other factors. They would also be able to acquire (through transfers) address blocks sized according to their own perception of current and future need.

The other part of the proposal incorporates the separate section describing the use of the "last /8" into the main policy text. This is prudent, as after the "last /8" policy was implemented, all address space handled by the RIPE NCC is subject to the "last /8" policy, even blocks which fall outside of the actual last /8 (185.0.0.0/8), something which led to significant confusion. The proposal does not change the effective "last /8" policy - the intention is only to clean up and reorganise the policy to make it more easily understandable.

It also adds a "self destruct" clause to the "Unforeseen Circumstances" section that will ensure the prompt removal of the section if the reserved address space returns to the free pool - an event which would make the section defunct. This prevents the community from having to to through a new PDP to clean it up.

Furthermore, it proposal removes text suggesting that the RIPE NCC will assign PI address space to End Users in section 8.0 "PA vs. PI Address Space", also renaming it to "Types of Address Space".

Finally, it incorporates a number of editorial improvements suggested by the RIPE NCC's Policy Development Officer.

Policy Text

In order to improve the clarity of the changes in this proposal, please note that the changes are presented in a different format than usual, due to the extensive number of changes involved.

a. Comparison of original and new policy text (with modifications highlighted)

b. New policy text (if the proposal reaches consensus)

Rationale

a. Arguments supporting the proposal

1. Reduced bureaucracy.

   Under the proposed policy, End Users, sub-allocation holders, and LIRs will no longer be required to document their need for IPv4 addresses in order to receive PA assignments, sub-allocations, or (transferred) PA allocations. Consequently, LIRs will not be required to vet such requests, nor to maintain an archive of such requests. This greatly reduces the bureaucracy required to operate an LIR or sub-allocation holder, and may allow for things like fully automated provisioning of IPv4 addresses to End Users or LIR infrastructure.

   LIRs and sub-allocation holders will of course be free to continue to demand need-based justification from their End Users before making assignments. It is expected that most (if not all) LIRs and sub-allocation holders will do so, considering the scarcity of IPv4 addresses and their value, it would be very unwise to throw them all out the window. However, the LIR or sub-allocation holder's local conservation policies and procedures may now be adapted to suit the exact business needs of the organisation in question, instead of being limited by the RIPE community policies.

2. Allows for long-term business planning.

   Under the proposed policy, the need-based time period will be raised from the current one/two years (allocation/assignments) to essentially infinity. This allow organisations to plan their use of IPv4 addresses for as long as they themselves deem sensible, without being artificially constrained by RIPE policies.

3. Makes the policy easier to read and understand.

   The proposal will remove large amounts of policy text, which in itself makes the policy neater and more approachable. In particular, the removal of the Assignment Window concept is likely to help out in this regard, and also by ceasing to refer to "the last /8", which in actuality is all space held by the RIPE NCC, not only 185.0.0.0/8.

   As noted by the RIPE NCC in the Impact Analysis of proposal 2012-06, "Revert Run Out Fairly", diverging assignment and allocation times periods caused confusion. These are currently one and two years, respectively. By removing the need period concept completely, the assignment and allocation time periods will be perfectly harmonised.

   The proposal also removes a number passages made obsolete by depletion and subsequent implementation of the "last /8" policy, such as: "The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of for a period of up to 12 months".

4. Removes conflict between "conservation" and "aggregation".

   Current policy states:

   Conservation and aggregation are often conflicting goals.

   By removing conservation as a goal, this dilemma is no more.

5. LIR Audits becomes less time-consuming.

   It is the proposer's understanding that a major part of being subjected to an LIR Audit is related to ensuring adequate documentation exists for each PA assignment having been made by the LIR being audited, and making sure that they do correctly justify the amount of assigned space. Under the proposed policy, however, LIRs will no longer be required to maintain such a documentation archive, and therefore there would be no need to validate its existence or quality as part of an LIR Audit.

6. Reduction of RIPE NCC workload.

   Currently, the RIPE NCC IP Resource Analysts need to vet any assignment requests that exceed an LIRs Assignment Window, as well as to (pre-) approve any requests for allocation transfers, to make sure that the need for address space is adequately documented in each case. In addition, they need to re-examine past assignments as part of LIR Audits. Under the proposed policy, none of these tasks will be necessary, which would lead to a reduction in workload for the NCC. This in turn may lead to reduced membership fees and/or an increased focus on developing member services.

7. Elimination of incentive to "game the system".

   It has been suggested on several times on public mailing lists that some LIRs fall for the temptation to "game" the needs-based system, by requesting more space than they need within the time periods determined by the policy. This could be anywhere from being excessively optimistic with regards to their own business growth, to outright fraud. Doing so will put those dishonest LIRs at an advantage, compared to those that to things strictly by the book. Even if an LIR accused of cheating in this manner is completely innocent, the mere suspicion of it is creating a hostile and unfriendly environment.

   By removing the need-based requirements, the playing field becomes level and fair for everyone involved, and will become impossible to get ahead by cheating.

8. Makes IPv4 and IPv6 policies more similar in practice

   IPv6 address policy states that LIRs may receive PA allocations up to and including a /29. Additional documentation to justify need is necessary only for larger allocations. Similarly, End Users may receive PA/PI assignments up to and including a /48. They have to justify or document actual need only for larger assignments. In both cases, these limits are so generous that they are more than sufficient for all but the very largest ISPs and End Users. In practice, this means that the vast majority of IPv6 allocations and assignments are made without having their size be justified based on actual need. At the time of writing, this was the case for 99.3% of all IPv6 PA allocations, and 95.3% of all IPv6 PI assignments.

   This stands in stark contrast with the current IPv4 address policy, which mandates that all allocations and assignments must be sized according to documented need.

   By removing the need principle from the IPv4 policy, it will become more similar to the IPv6 policy in practice, in the sense that need justification will not be mandated for the vast majority of delegations.

b. Arguments opposing the proposal

1. Conflicts with RFC 2050
   RFC 2050 section 1, goal 1, states:

   1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space.

   Removing the needs-based principle from the IPv4 policy would be a violation of this principle.

   Counter-argument:

   This goal is no longer applicable today. Following the depletion of the IANA and RIPE NCC unallocated pools, there is nothing left to conserve.

   Furthermore, there is already precedence in the RIPE Community for not following RFC 2050's guidelines strictly, such as:

   • The passing of proposal 2010-02 "Allocations from the last /8" was a radical departure from the needs-based distribution guidelines set forth in RFC 2050 (e.g., "Initial allocation will not be based on any current or future routing restrictions but on demonstrated requirements").
   • RFC 2050 section 2.1 demands that in order to qualify for an allocation, an ISP must be either connected to an IXP or be multihomed. However, neither of these requirements are present in the current IPv4 policy document.

2. Conflict with ARIN's Inter-RIR transfer policy
   https://www.arin.net/resources/request/transfers_8_4.html states:

   Inter-RIR transfers may be completed between ARIN and another RIR as long as that RIR has: [...]

   * Needs-based general number resource policies

   The proposed policy would conflict with the above requirement, making transfers beween the RIPE NCC and ARIN service areas impossible.

   Counter-argument:

   The ARIN policy goes on to say:

   Currently, APNIC is the only RIR with a reciprocal, compatible inter-RIR transfer policy.

   In other words, transfers between the RIPE NCC and ARIN service areas are impossible to begin with. The proposed policy will not change this one way or the other.

   Furthermore, it is worth noting that ARIN still have remaining addresses in their free pool. It is therefore prudent of them to insist that all downstream delegation paths uphold the needs based principle, even including out-of-region transfers. When ARIN depletes, it could well be that their priorities in this regard will change.

3. A (wealthy) LIR may hoard all space available on the market.

   In the words of Michiel Klaver (https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html):

   Removing the needs-based requirement would break open the entire IPv4 market, letting big corporations to buy everything available and then decide who they are willing to sell it for the highest price.

   IP addresses will become a tool to obstruct competitors, wipe-out all smaller players and locking the market for newcomers. An authority validating each request with the current policies could somewhat prevent that from happening.

   Counter-argument:

   This argument would apply equally well to any freely traded commodity, especially ones that are in limited supply (for example real estate). However, these markets function well and in a competitive manner, and there is no reason why the trade of IPv4 addresses will be any different. Even if that turns out not to be the case, most (if not all) juridstictions in the RIPE NCC service area have laws against anti-competitive practices, monopolies, cartels, price fixing, et cetera. There is no reason to duplicate these in the RIPE policies, as the law will in any case always take precedence.

   Furthermore, there is a 24 months cooling-off period during which a recently transferred resource cannot be transferred further. This prevents LIRs from using IPv4 address space as a short-term investment or speculation object. This particular restriction is not lifted by this policy proposal.

4. Conflicts with proposal 2012-03

   This proposal aim to add policy text that describes need-based policies. Therefore, if proposal 2012-03 pass in addition to this one, the policy text will be left in an self-contradictory state.

   Suggested resolution:

   Interpret this proposal to also remove any text relating to need-based policies that was earlier added or modified by the passing of 2012-03.

   The phrase that would be removed if present in the active policy when this proposal is implemented, is specifically:

   - «Other than for an additional allocation, for the purpose of determining need, a period of 24 months is used in evaluating a transferred allocation.» (if added to current policy by 2012-03)»