free pool on 14 September 2012, these are now obsolete.
In anticipation of depletion, the RIPE community adopted new policies for allocations in the “last /8” (see 2010-02 Link: /membership/policies/proposals/2010-02/ ). Having reserved a /16 for unforeseen contingencies and made special provision for IXPs, the remaining space is made available on the basis of seeking to maximise the number of LIRs who will receive at least some IPv4 space, by making only a small allocation to each. Thus, each LIR is entitled to exactly a /22, even if their own needs would justify a larger allocation.
These new policies governing allocations from the last /8 also apply to address space subsequently recovered by the RIPE NCC or IANA (see 2011-03 Link: /membership/policies/proposals/2011-03/ ), or redesignated for allocation from reserved blocks, if any. In other words, since depletion of the RIPE NCC free pool on 14 September 2012, these policies control all allocations by the RIPE NCC.
Despite the above, LIRs applying for allocations are still also required to undergo the application procedures that were used in the previous allocation process. End Users have to provide documentation to the LIR (and/or the RIPE NCC) that prove their need for address space, and the LIR needs to provide similar documentation to the RIPE NCC. In all cases, the documentation has to be thoroughly vetted and archived for later auditing. The collection and collation of this information is costly, but is no longer used by the RIPE NCC to evaluate the size of the address block that should be allocated, except in the special case of IXP applicants.
The policy also regulates transfers between LIRs. Before the depletion of the free address pool, LIRs had no independent incentive to avoid inappropriate transfers; an LIR could simply apply for more address space from the RIPE NCC. This created an externality (premature depletion of the free address pool) that had to be addressed through policy. After depletion of the free address pool this is no longer the case, and so the original justification for a costly ex ante assessment of need in the transfer market no longer applies.
Existing RIPE Policy goals for IP allocation combine the concepts of conservation of the address pool, and fair distribution on the basis of need.
SectionIn short, the proposal does the following changes to the active policy:
current address allocation policy reads:“Conservation: policy, which reads:Conservation:
prevented.” [emphasis added]
This combines the concepts of “conservation” and “fair distribution”, the principles of distribution according to need and the imperative to avoid stockpiling, with the aim to “maximise the lifetime of the public IPv4 address space”. Such conflation has not weathered the transition from a situation where stewardship of the public IPv4 address space primarily entailed extending the lifetime of the free allocation pool to one where the free allocation pool has been depleted.
This proposal would simplify the goal:
“Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.”
This implicitly continues the anti-stockpiling provision: address space must be distributed to End Users operating networks.
Consistent with previous RIPE Policy, we do not attempt to fully define what is a “fair distribution”, but allow that to be inferred from policy provisions present and future. This policy goal does not confer on the RIPE NCC a responsibility to judge the “fairness” of particular allocations and assignments in the abstract. The new policy goal continues to assert the RIPE community’s right to institute new policies to address any unfairness that may arise, in the collective view of the community on the basis of rough consensus. This brings IPv4 policy into line with RIPE IPv6 Policy, which has from the beginning made a clear distinction between the two goals "Conservation" and "Fairness".
This proposal would remove the ex ante documentation of need from the LIR’s application process. Such documentation was previously used by the RIPE NCC to assess whether the LIR’s need justified the allocation of the size of the address block for which the LIR had applied.
Now that the RIPE NCC only allocates a single small (/22) address block, even when a larger allocation is needed, documentation of the scale of actual need is no longer necessary.
The proposal would also remove the requirement for an ex ante documentation of need by the End User seeking an assignment of address space from an LIR. Furthermore, removing this requirement would also implicitly lift the “two-year assignment period”, that is, the requirement that there must be a documented need for 50% of the assigned space within the first year of the assignment. This requirement undermines business planning, but was justified by the need to preventfree address pool. Now that that reason no longer applies, it is no longer appropriate to damage business certainty in this manner.
The proposal would also remove the ex ante documentation of need for the approval by the RIPE NCC of transfers. This will maintain consistency with allocation policy. The requirement to document need in the transfer process never had an independent justification, but existed to maintain consistency with allocation policy and to prevent that policy being circumvented, leading to premature depletion of the free pool [1] Link: #ref1 .
Note that adoption of this proposal would not remove the requirement for need: LIR allocations and transfers, and IXP assignments issued by the RIPE NCC, will all remain subject to a need evaluation. LIRs will still be required to 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.
The main concern that has been raised concerning the transfer market – that it might lead to stockpiling for purely speculative purposes – will remain prohibited by the policy. This is further reinforced by a provision preventing the re-transfer of address space within 24 months, a provision that also remains in place.
free pool. We therefore retained the previous policy at that time, which continued in effect until the free pool was actually depleted on 14 September 2012.The continued presence in the policy text of those historic elements of policy which are no longer operative leads to confusion. In particular, the nomenclature of (general) “policy” and “policy for the last /8” leads to the incorrect perception that IP address blocks outside 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.
block (185.0.0.0/8) continue to be governed by the previous policy. In fact, IP address space recovered by the RIPE NCC is returned to the last /8 pool, and is governed by the “last /8 policy”. This proposal would clarify the text so that this is more obvious.The proposal would also add a self-executing removal clause (a “self destruct” clause) to the “Unforeseen Circumstances” (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"
would avoid the need to re-open the policy process in a completely foreseeable circumstance.Furthermore, the proposal would remove prevents the community from having to to through a new PDP to clean it up.Furthermore, it proposal removes
Finally, the proposal it incorporates a number of editorial improvements suggested by the RIPE NCC's Policy Development Officer.
[1] The requirement to document need existed to prevent an LIR with need collaborating with an LIR without need acquiring address space by applying for one allocation, transferring it to the second LIR, and then re-applying to replace that address block. Such behaviour would have circumvented the allocation policy’s requirement to document need, resulting in premature depletion of the free address pool.
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 Link: /publications/docs/ripe-documents/other-documents/ipv4-address-allocation-and-assignment-policies-for-the-ripe-ncc-service-region-current/ (with modifications highlighted)
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.
The need requirement in existing policy arbitrarily limits the maximum length of the LIR's business planning horizon. LIR customer contracts may have a longer duration; where this is so, the existing policy requires LIRs to under-report their true need (by only considering need within that time period), leaving the LIR to shoulder a degree of business risk. Thus LIRs that comply fully with the policy suffer increased business risk compared with LIRs that (carelessly or deliberately) overestimate their need within the planning horizon.
By eliminating the planning horizon for calculating need, this policy proposal also eliminates the unintended effect of endowing non-compliant LIRs with lower business risk than their more compliant competitors.
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.
practise
The current practice 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 /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 without providing any documentation or justification for their need. These limits /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 practise, 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 practise, practice, 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 unallocated 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 Link: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html Link: http://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.
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)»
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.
Transfer of Allocations
It is stated in section 5.5:
“Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.”
It is the RIPE NCC’s understanding that the receiving LIR would be required to confirm that it would make assignment(s) from the transferred allocation(s).
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
Even though it remains important to explain the nature of this policy change to the various stakeholders, impact to the external relations department is expected to be limited and doesn't impose a change in regular operational workload.
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 analyses prepared for previous versions 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, can indeed be seen as a way to prevent discriminatory or exclusionary behavior.
Details about the “fairness” requirement are given in the explanatory text of the proposed policy. In particular: