This policy proposal has been accepted
The new RIPE Document is: ripe-604
You're looking at an older version: 2
The current (published) version is 4This 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:
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.
a. Current policy text
b. New policy text
a. Arguments supporting the proposal
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.
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.
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".
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.
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.
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.
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.
Makes IPv4 and IPv6 policies more similar in practise
The current IPv6 address policy states that LIRs may receive PA allocations up to and including a /29 without providing any documentation or justification for their need. Similarly, end users may receive PA/PI assignments up to and including a /48 without providing any documentation or justification for their need. These limits so generous that they are sufficient for all but the very largest ISPs and end users. In practise, 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 practise, in the sense that need justification will not be mandated for the vast majority of delegations.
b. Arguments opposing the proposal
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:
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 RIRf 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.
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.
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 proposal might have if it is accepted and implemented.
The RIPE NCC’s understanding of the proposed policy is presented with emphasis on the following matters:
Final IPv4 /22 Allocations
It is the RIPE NCC’s understanding that final IPv4 /22 allocations issued from the last /8 would not require a demonstration of need. This would be true for both new LIRs receiving their first (and final) /22 allocation, and existing LIRs receiving their final /22.
Validity of an Assignment
It is stated in section 6.3:
"All assignments are valid as long as the original criteria on which the assignment was based are still valid…"
Assignments made prior to the proposed policy were based on the evaluation of demonstrated need, and for a specific purpose. The RIPE NCC understands that these criteria must still be in place for these assignments to be considered valid.
Contractual Requirements for Independent Internet Number Resources
The policy proposal removes references to ripe-452, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.
Despite this reference being removed, the RIPE NCC understands that a contractual relationship with a sponsoring LIR or the RIPE NCC would remain a policy requirement for provider independent number resources. This requirement would cover independent resources that have already been assigned, as well as those that will be assigned in future (e.g. IXP assignments).
Internet Exchange Point Assignments
It is stated in section 6.1:
"New Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment."
It is the RIPE NCC’s understanding that Internet Exchange Point assignments would be made based on some form of utilisation requirement. It is not clear, however, whether the RIPE NCC would evaluate this requirement. If so, there is no specified timeframe to base the utilisation upon, nor what utilisation percentage should be used. More guidance from the community is required.
Inter-RIR Transfers
It is the RIPE NCC’s understanding that the proposed policy would conflict with the requirements for inter-RIR transfers from regions where a needs-based requirement is still in place. This lack of compatibility between the policies may lead to organisations being unable to transfer Internet number resources to/from other RIR service regions.
Removing the needs-based requirement would facilitate intra-RIR transfers. This may have a positive effect on the quality of the Registry data, as organisations will have greater incentive to inform the RIPE NCC when a transfer takes place.
As mentioned above, it is important to highlight that the proposed policy would not be compatible with the inter-RIR transfer policies in other RIR service regions as they currently stand. This could be considered an impediment to organisations that want to transfer Internet number resources between regions. This may create an incentive not to inform the RIR about inter-RIR transfers, which could lead to a reduction of data accuracy in the Registry.
Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Fragmentation/Aggregation:
The RIPE NCC is not aware of related historical datasets to analyse, or applicable projections to apply to this situation. The amount of fragmentation/aggregation will mostly depend on the number of blocks being transferred and the size and alignment of these blocks. In the majority of cases, the RIPE NCC expects that a transfer would result in the original block becoming fragmented. Most likely, the degree of extra fragmentation will be correlated with the number of transfers made.
Registration Services:
It is expected that the proposed policy would lead to a reduction in the workload of the RIPE NCC, as there would be no more need to evaluate assignments. The related Provider Aggregatable (PA) assignment tickets represent between 10-11% of the overall tickets handled by Registration Services since reaching the last /8.
As defined in section 3.0.3 of the policy proposal:
“Registration: The provision of a public registry documenting address space allocations and assignments…”
Registration remains a goal of the Registry system. Currently, LIRs need to register a RIPE Database object for each assignment made, in order to demonstrate utilisation of the address space. Furthermore, the RIPE Database object for an assignment is often created automatically when the assignment request has been approved (through the LIR Portal “PA Assignment Wizard”). With the abolishment of the needs-based requirement, these two incentives for registering the assignment in the RIPE Database will no longer exist.
For this reason, there is an expectation that the RIPE NCC’s activities will shift from evaluating assignment requests to ensuring that assignments made by LIRs are properly registered in the RIPE Database (via auditing activity). It is expected that new LIRs will need more education on assignment registrations, as well as increased assistance to help them develop their internal assignment guidelines.
Billing/Finance Department:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
RIPE Database:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
The RIPE NCC Executive Board would like to emphasise the following considerations relating to the discussion of the policy proposal and its implementation if accepted:
In addition, the Executive Board would like to highlight the following potential consequences for LIRs:
EU Competition Law Considerations
An impact analysis regarding EU competition law considerations has been carried out in cooperation with an external legal advisor and is available here.
The basic points from this analysis are: