This policy proposal has been accepted
The new RIPE Document is: ripe-604
You're looking at an older version: 3
The current (published) version is 4In 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. [emphasis added]
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 the "Conservation" goal and all policy mechanisms that were working exclusively towards attaining it. However, the initial (non-emphasised) sentence of the goal is retained verbatim as a separate "Fairness" goal. This matches our IPv6 policy, which has from the beginning made a clear distinction between the two goals "Conservation" and "Fairness".
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. This means that LIR allocations and IXP assignments issued by the RIPE NCC will remain subject to a need evaluation, like today: LIRs must confirm that they intend to make assignments to their End Users and/or their own infrastructure, and IXPs will receive an assignment sized according to their actual utilisation.
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 go through a new PDP to clean it up.
Furthermore, the 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
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.
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.
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".
Current policy states:
Conservation and aggregation are often conflicting goals.
By removing conservation as a goal, this dilemma is no more.
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.
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.
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.
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
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 allocation pools, there is nothing left to conserve. Furthermore, RFC 2050 has recently formally obsoleted by RFC 7020, whose updated goal reads:
1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation.
The proposed policy upholds the current level of operational need justification required in order to receive IPv4 addresses from the NCC's allocation pool (the so-called "last /8" pool): LIRs must confirm that they will make assignments to their End Users and/or their own infrastructure in order to receive their final /22 allocation, while IXPs must demonstrate future utilisation requirements in order to receive an assignment larger than the minimum size. Therefore, the proposed policy is compliant with RFC 7020's goal 1 (at least to the same extent our current policy is).
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.
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 require LIRs to confirm that assignment(s) will be made from that allocation. 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 (PI) Internet 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 IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined. "
It is the RIPE NCC’s understanding that Internet Exchange Point assignments larger than /24 would be based on documented calculations that allow the utilisation to be estimated one year after the date of assignment. This utilisation should be at least 50% of the assignment.
Inter-RIR Transfers
There is currently no inter-RIR transfer policy in place in the RIPE NCC service region. If such a policy were to be adopted in future, it is the RIPE NCC’s understanding that removing the needs-based requirement for transfers could conflict with the requirements for inter-RIR transfers in other RIR service regions where a needs-based requirement is still in place. This potential lack of compatibility could result in organisations being unable to transfer Internet number resources to/from other RIR service regions.
Removing the needs-based requirement would facilitate transfers within the RIPE NCC service region. This may have a positive effect on the quality of 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.
The RIPE NCC expects that the adoption of this policy would have a significant impact on our operations and services. Many external and internal procedures, documentation, tools and services would need to change.
Registration Services
If accepted, the proposed policy would remove the need to evaluate Provider Aggregatable (PA) assignments, which represent around 10% of the overall tickets handled by Registration Services since reaching the last /8. However, when further considerations are taken into account, this is expected to have a neutral impact, rather than lead to a reduction in workload.
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 removal 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 also expected that new LIRs will need more education on assignment registrations, as well as increased assistance to help them develop their internal assignment guidelines.
The expected increase in workload to support proper registration will be balanced by no longer having to evaluate PA assignments. As a result, the overall impact on Registration Services is expected to be neutral.
External Relations
Adoption of this policy would have a major impact on RIPE NCC External Relations, and would require the investment of considerable resources in messaging and defending/explaining this policy shift to stakeholders both inside and outside the technical community. Additionally, these activities would need to target not only stakeholders within the RIPE NCC service region, but also those in other RIR communities.
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.
Business Applications Department
This proposal is expected to have a low-to-medium impact if it is implemented.
The RIPE NCC Executive Board notes the improvement to the EU competition impact analysis by the introduction of the "fairness" principle. Unless the community comes up with an appropriate definition of "fairness", the Executive Board suggests that definition of this principle in this context be left to the RIPE NCC.
EU Competition Law Considerations
As mentioned in the impact analysis prepared for the previous version of this proposal, from an EU competition point of view, it is important that IPv4 allocations and transfers are conducted in a way that cannot be seen as discriminatory or exclusionary.
The fact that the RIPE NCC has allocated IPv4 addresses on the basis of the proof of objective need, rather than purely economic considerations, has protected the RIPE NCC from competition law claims. After depletion, IPv4 allocations and transfers should continue to be conducted in a non-discriminatory or non-exclusionary way, particularly if there is a risk of stockpiling.
The “fairness” requirement, which is even broader than the “need” requirement, could indeed be seen as a way to prevent discriminatory or exclusionary behavior. However, this requirement applies only to the distribution of IPv4 addresses from LIR to End User and not from LIR to LIR (“Public IPv4 address space must be fairly distributed to End Users operating networks”).
Removing the needs-based requirement, which is currently used to evaluate allocation transfers between LIRs, would create an exposure to competition law claims based on discriminatory treatment or refusal to supply. Competition law claims would be mainly addressed to LIRs that could be seen as coordinating in stockpiling and applying discriminatory practices. Such claims may also be addressed to the RIPE NCC, if only in order to make more publicity for the claim.
The “fairness” requirement for distribution by LIRs to End Users may prevent EU Competition Law challenges if there are transparent guidelines on what is considered to be “fair”. In particular, if the proposal is accepted, the RIPE NCC will have to make sure that RIPE Policies are implemented correctly by LIRs when they assign IP addresses to End Users. Such checks by the RIPE NCC should be conducted based on transparent guidelines/criteria that outline what is considered to be fair. If not, the RIPE NCC may be legally challenged.