Changes to Locking Down the Final /8 Policy
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
Summary of Proposal
Based on the ongoing discussions feedback about both the expansion of the final /8 the first version of this policy as well as some of the proposal, most of the restrictions that the original version set out to implement have been removed. The obvious loopholes that are now being exploited to get around the policy, I'd like to introduce a policy should still be reduced as this proposal makes it unattractive to collect address space for non-addressing purposes. The updated policy proposal that now does the following:
- Explicitly state states that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA
- Limit the number of “final /22s” to one per LIR, regardless of how they were received Adds a consideration to the IPv4 allocation policy that the LIR should conserve whole or part of their final /22 allocation for interoperability purposes
- Ban Bans transfers of final /22 allocations
- Change the ‘status’ “status” field in the RIPE Database to reflect the transferability of an INETNUM delete: <li> Limit reverse delegation of final /22s to a maximum of one /22 of address space per LIR delete: </li> delete: <li> Limit the number of final /22 INETNUM objects that can get RPKI validation to one per LIR delete: </li> delete: <li> Limit the number of ROUTE objects of final /22s to a maximum of one /22 of address space per LIR delete: </li>
In short, every LIR is welcome to have one /22. If you end up having more, however you got them, you're supposed to return all but one. Based on feedback on the second version, some clarifications and corrections were made in the proposed policy text.
Policy Text
delete: <i> insert: <em> [The following text will update sections 5.1, 5.3, 5.4, 5.5 and 7.0 in the RIPE Policy Document “ delete: <a class="internal-link" href="resolveuid/b97600388f9d485e87f0c532030f31b3" target="_self" title="" data-val="b97600388f9d485e87f0c532030f31b3" data-linktype="internal"> insert: <a href="../../../../../resolveuid/b97600388f9d485e87f0c532030f31b3" data-linktype="internal" data-val="b97600388f9d485e87f0c532030f31b3"> IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region ” and section 3.0 in RIPE Policy Document “ delete: <a class="internal-link" href="resolveuid/bedc207d-7057-46b9-abbf-1101392bebf0" target="_self" title="" data-val="bedc207d-7057-46b9-abbf-1101392bebf0" data-linktype="internal"> Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region delete: </a> ”, if the proposal reaches consensus.] delete: </i> insert: </em>
a. Current policy text
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document " delete: <a class="internal-link" href="resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" target="_self" title="" data-val="1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal"> insert: <a href="../../../../../resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal" data-val="1debfd86d3d2ea24a7ce6695202c44f0"> Procedure for Becoming a Member of the RIPE NCC "
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
- The size of the allocation made will be exactly one /22.
- The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
- The LIR must confirm it will make assignment(s) from the allocation. allocation.
In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request. insert: </p>
(…)
5.3 Address Recycling
Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.
This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.
(…)
delete: <p> insert: <h4>delete: </p> delete: <h4> 5.4 Sub-allocations
delete: <p> Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0. delete: </p> delete: <p> (…) delete: </p> delete: <p> delete: </p>5.5 Transfers of Allocations
Any resource holder is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System.
Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers.
(…)
7.0 Types of Address Space
(…)
ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.
ALLOCATED ALLOCATED PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.
(…)
(From RIPE-581, “Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region”) delete: </p> delete: <p>
delete: <h4> 3.0 Reverse Delegation in the RIPE NCC Service Region delete: </h4> delete: <p> The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC. delete: </p> delete: <p> The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database. delete: </p> delete: <p> Address space holders may delegate authority to another party. delete: </p> delete: <h3> delete: </h3>b. New policy text
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document " delete: <a class="internal-link" href="resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" target="_self" title="" data-val="1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal"> insert: <a href="../../../../../resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal" data-val="1debfd86d3d2ea24a7ce6695202c44f0"> Procedure for Becoming a Member of the RIPE NCC ".
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
- The size of the allocation made will be exactly one /22. In case an allocation of a single /22 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.
- The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 1,024 IPv4 addresses (a single /22 or the equivalent thereof).
- The LIR must confirm it will make assignment(s) from the allocation.
- The LIR must be aware that this is the last IPv4 allocation it will receive from the RIPE NCC, and should reserve at least part of this allocation for interoperability with networks that are only reachable using IPv4. insert: </li> insert: </ol>
All allocations made by the RIPE NCC to LIRs based on the IPv4 allocation policy after the 14th of September 2012 will be marked in the RIPE database Database as ‘ALLOCATED FINAL’ delete: </li> delete: <li> An allocation marked "ALLOCATED FINAL" is valid as long as it remains with the LIR it was allocated to. If an LIR, due to mergers, acquisitions or other means gains additional allocations marked "ALLOCATED FINAL", all but the equivalent of a single /22 will be de-registered by the RIPE NCC within 180 days. delete: </li> delete: </ol> “ALLOCATED FINAL”. insert: </p>
(…)
5.3 Address Recycling
If Any address space that is not covered by other policies, any policies or marked to be returned to IANA, will be covered by the rules in section 5.1. This includes address space that is returned is: insert: </p>
insert: <ul>- insert: <li>
- Returned to the RIPE NCC, or allocated insert: </li> insert: <li>
- Allocated to the RIPE NCC from the IANA recovered pool as defined in RIPE policy “ delete: <a class="internal-link" href="resolveuid/0cc166733ca887b35907a6dd7da41a8c" target="_self" title="" data-val="0cc166733ca887b35907a6dd7da41a8c" data-linktype="internal"> Global the RIPE Policy “Global Policy for post exhaustion IPv4 allocation mechanisms Post Exhaustion IPv4 Allocation Mechanisms by the IANA delete: </a> ” will be covered IANA” insert: </li> insert: <li>
- Given to the RIPE NCC by the same rules as the address space intended in section 5.1. delete: </p> legacy holders insert: </li> insert: </ul>
(…)
delete: <p> insert: <h4>delete: </p> delete: <h4> 5.4 Sub-allocations
delete: <p> Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. Sub-allocations cannot be made from allocations with a status of "ALLOCATED FINAL". delete: <b> delete: </b> The meanings of the various "status:" attribute values are described in Section 7.0. delete: </p> delete: <p> (…) delete: </p> delete: <p> delete: </p>5.5 Transfers of Allocations
delete: <p> insert: <ol>- insert: <li>
- Any resource holder is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System. delete: </p> delete: <p> System insert: </li> insert: <li>
- Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers. delete: <b> delete: </b> transfers insert: </li> insert: <li>
- Allocations with a the status of "ALLOCATED FINAL" cannot be transferred. delete: </p> transferred insert: </li> insert: <li>
- Point 3 of this article does not apply to any change of holdership of address space as a result of company mergers or acquisitions insert: </li> insert: </ol>
(…)
delete: <strong> delete: </strong>
7.0 Types of Address Space
(…)
ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.
ALLOCATED PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.
ALLOCATED FINAL: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. This allocation is non-transferable and every LIR is only allowed to receive up to a /22 of allocated space of this type. not transferable to another LIR.
(…) delete: </p> delete: <p> (For “Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region”) delete: </p> delete: <p> delete: </p> delete: <h4> 3.0 Reverse Delegation in the RIPE NCC Service Region delete: <b> delete: </b> delete: </h4> delete: <p> The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC. delete: </p> delete: <p> The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database. delete: </p> delete: <p> Address space holders may delegate authority to another party. delete: </p> delete: <p> For "ALLOCATED FINAL" IPv4 address space, authority may not be delegated to another party, and the reverse delegation delete: <b> delete: </b> will be limited to a total of a /22 of IPv4 address space.
Rationale
a. Arguments supporting the proposal
This proposal has the aim to reinforce the intended aim of the currently accepted final /8 policy, which is to be able to give new entrants a piece of IPv4 space for as long as possible. It does this by giving these final allocations a special status, marking them as a special case for which regular transfer, merger and acquisition transfer rules do not apply. This makes these allocations easy to recognize and unattractive for speculation and makes multiple of these allocations unpractical from an operational perspective. speculation. It also ensures that any allocations that fall into disuse will eventually be returned to the RIPE NCC for reallocation. Based on the It also sets no additional limitations set out in the policy text, the (implicit) limitations for RPKI and route objects should follow automatically. to transfers as a result of M&A activity.
b. Arguments opposing the proposal
This proposal adds significant some overhead to the management of final /8 allocations, both on the RIPE NCC and the LIR side, and does not benefit any current LIR. While this This amended proposal should still make it a lot more complicated to find creative interpretations of the IPv4 allocation policy, there are no guarantees it covers but will not cover all potential interpretations. delete: </p> interpretations or address all current loopholes. insert: </p>
insert: <hr />insert: <p>
insert: <a name="impact-analysis"> insert: </a> insert: </p>
insert: <h2>Impact Analysis: insert: </h2>
insert: <p>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 proposal might have if it is accepted and implemented. insert: </p>
insert: <h3>A. RIPE NCC's Understanding of the Proposed Policy insert: </h3>
insert: <p>This policy proposal introduces the new status “ALLOCATED FINAL” for IPv4 allocations in the RIPE Database. Despite the title of the proposal making reference to the final /8 (a common term for the IPv4 range 185.0.0.0/8) it is the RIPE NCC’s understanding that this status will be applied to any allocation made from RIPE NCC’s available IPv4 pool after 14 September 2012. insert: </p>
insert: <p>The proposed policy text defines further special transfer conditions for this type of allocation. It also clarifies what IPv4 address space should be added to the RIPE NCC’s IPv4 pool and how the final IPv4 allocation should be used by LIRs. The following sections will analyse these changes in more detail. insert: </p>
insert: <p>insert: </p>
insert: <h4>Transfer Restrictions for IPv4 Ranges with “ALLOCATED FINAL” insert: </h4>
insert: <p>Allocations with the status “ALLOCATED FINAL” cannot be transferred under the transfer policy to another LIR on either a permanent or temporary basis. This includes transfers between different LIR accounts held by the same organisation. If an LIR no longer needs an allocation with this status, it can return the range to the RIPE NCC. Alternatively, the LIR could consider providing assignments or sub-allocations from this range to other organisations. When an LIR account is closed, allocations with the status “ALLOCATED FINAL” must be returned to the RIPE NCC. insert: </p>
insert: <p>The proposed policy clarifies further that transfers related to changes in the structure of organisations (e.g., mergers, acquisitions) will not be restricted. It is the RIPE NCC’s current procedure that such changes of holdership must be supported by legal documents issued by a national authority proving that a merger or acquisition has taken place according to section 3.1 of the RIPE NCC procedural document “ insert: <a href="../../../../../resolveuid/5aa686d24933483bbec6a967b214a8d3#transfer31" data-linktype="internal" data-val="5aa686d24933483bbec6a967b214a8d3"> Transfer of Internet Number Resources and Change of a Member’s Official Legal Name insert: </a> ”. insert: </p>
insert: <p>From the moment this proposed policy reaches consensus, the RIPE NCC will not longer process new transfer requests for allocations made after the 14 September 2012. Transfers that have already been finalised by the RIPE NCC will not be impacted by this policy change. Any transfer requests submitted before the proposal reaches consensus (and that have complete, valid documentation) will continue to be processed. insert: </p>
insert: <p>It is possible that some LIRs would end up holding multiple ranges with the status “ALLOCATED FINAL” after the policy was implemented. This would be due to transfers that were already completed before the policy came into effect, and also due to mergers and acquisitions. insert: </p>
insert: <p>N.B. This proposal suggests changes to section 5.5, “Transfers of Allocations” in the IPv4 policies. The RIPE community is currently discussing another policy proposal, 2015-04, “ insert: <a href="../../../../../resolveuid/dce6971b451c4e629b74d165031290eb" data-linktype="internal" data-val="dce6971b451c4e629b74d165031290eb"> RIPE Resource Transfer Polices insert: </a> ”, that would replace this section with a reference to a new transfer policy document. If 2015-04 reaches consensus first, the suggested changes to section 5.5 in 2016-03 must be reviewed and would likely need to be adjusted. This would result in another Review Phase. insert: </p>
insert: <p>insert: </p>
insert: <h4>Usage of the Final Allocation insert: </h4>
insert: <p> The proposed policy says: insert: <br />
“The LIR must be aware that this is the last IPv4 allocation it will receive from the RIPE NCC, and should reserve at least part of this allocation for interoperability with networks that are only reachable using IPv4.” insert: </p>
The RIPE NCC understands this as a suggestion for using this address block cautiously, in the light of the fact that (especially for new LIRs) this might be their only IPv4 range that allows their IPv6 network to communicate with the IPv4-only networks of other operators. insert: </p>
insert: <p>The use of the term “should” indicates that this is a recommendation and not a mandatory policy requirement. LIRs can use this final allocation according to their own requirements. insert: </p>
insert: <p>insert: </p>
insert: <h4>Address Space Returned to the RIPE NCC insert: </h4>
insert: <p>The proposal states that all IPv4 address space that the RIPE NCC receives will be added to the available pool, unless it is covered by other policies or marked to be returned to IANA. Currently there is no address space that is marked to be returned to IANA. insert: </p>
insert: <p>IXP IPv4 assignments are the only resource type that currently has a special return policy defined. Section 6.1 of “ insert: <a href="../../../../../resolveuid/b97600388f9d485e87f0c532030f31b3#61" data-linktype="internal" data-val="b97600388f9d485e87f0c532030f31b3"> IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region insert: </a> ” states that “IP space returned by IXPs will be added to the reserved pool maintained for IXP use.” Accordingly, any such returned IXP assignments are not added to the RIPE NCC’s general available IPv4 pool. insert: </p>
insert: <p>Returned IPv4 addresses from LIRs and End Users and addresses received from IANA’s recovered pool are currently added to the RIPE NCC’s available IPv4 pool. If this proposal is accepted, legacy resources that have been handed over to the RIPE NCC will also be added to the available pool. Currently, the RIPE NCC holds a total of ten /24 IPv4 legacy resources. insert: </p>
insert: <p>insert: </p>
insert: <h3>B. Impact of Policy on Registry and Addressing System insert: </h3>
insert: <p>If the proposal is accepted, final IPv4 /22 allocations received by LIRs from the RIPE NCC will not be able to be transferred to other LIRs under the RIPE transfer policy. This may impact the consumption rate of IPv4 addresses in RIPE NCC's available pool in two ways: insert: </p>
insert: <ul>- insert: <li>
- Organisations that acquire final /22 allocations for the purpose of transferring them to another legal entity will see this road blocked. The only alternative remaining will be to insert: <em> assign insert: </em> rather than transfer the address space. This might be a less attractive option for both the party that holds the allocation and the party that uses the allocated addresses. insert: </li> insert: <li>
- Organisations that open additional LIR accounts to obtain extra /22 allocations will see the costs of holding on to this address space go up. If these allocations can’t be transferred to the primary account, the additional LIR accounts will have to be kept open, incurring yearly membership fees. This may discourage organisations from using the multiple-LIR route to acquire more IPv4 addresses. insert: </li> insert: </ul>
However, in all cases only a small impact is expected. The policy proposal 2015-01, “ insert: <a href="../../../../../resolveuid/25f63b5ed2b44008a98dd0ca122dae47" data-linktype="internal" data-val="25f63b5ed2b44008a98dd0ca122dae47"> Alignment of Transfer Requirements for IPv4 Allocations insert: </a> ”, which was accepted and implemented in July 2015, established a 24-month holding period before a new final /22 allocation can be transferred to another LIR. This has already reduced the rate of /22 transfers. From August 2015 to September 2016, the RIPE NCC recorded 70 transfers from the last /8, down from 342 in the 13 months before. To put these numbers into perspective, the RIPE NCC made 3,500 final /22 allocations in that same time period, from August 2015 to September 2016. insert: </p>
insert: <p>insert: </p>
insert: <h3>C. Impact of Policy on RIPE NCC Operations/Services insert: </h3>
insert: <p>Once this policy change is implemented, the RIPE NCC expects extra efforts will be needed to educate LIRs that they can provide assignments and sub-allocations from their allocations if they no longer need them. This effort will aim to avoid a drop in registration quality as LIRs (particularly new LIRs) might not be aware of this option and instead could provide the address space to other organisations without updating the RIPE Database accordingly. insert: </p>
insert: <p>insert: </p>
insert: <h3>D. Implementation insert: </h3>
insert: <p>With the information currently available, it is expected that implementation of the proposal would have a medium impact in terms of the software development needed to facilitate the policy changes in the RIPE Database and external and internal RIPE NCC systems. insert: </p>
insert: <p>Regarding the suggested changes in the RIPE Database, the RIPE NCC believes it is unlikely that scripts and tools used by network operators will be affected by this change, but cannot exclude this possibility as these tools are not maintained by the RIPE NCC. The RIPE NCC would first deploy this change to the Release Candidate (RC) environment and recommend that all users test that their code can handle the new “ALLOCATED FINAL” status. insert: </p>
insert: <p>Internal and external processes and documentation would also need to be updated. insert: </p>
How to read this draft document: insert: </h2>
insert: <p>This document relates to the policy proposal 2016-03, “ insert: <a class="internal-link" title="" href="resolveuid/7f5aaf4e3996415b8b01ff377a6827e3" target="_self" data-val="7f5aaf4e3996415b8b01ff377a6827e3" data-linktype="internal"> Locking Down the Final /8 Policy insert: </a> ”. If approved, it will modify insert: <a class="internal-link" title="" href="resolveuid/b97600388f9d485e87f0c532030f31b3" target="_self" data-val="b97600388f9d485e87f0c532030f31b3" data-linktype="internal"> ripe-649 insert: </a> . To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text. insert: </p>
insert: <h3>We indicate changes to existing text in the document like this: insert: </h3>
insert: <table class="plain">| insert: <p align="center"> ORIGINAL TEXT insert: </p> insert: </th> | insert: <th> insert: <p align="center"> NEW TEXT insert: </p> insert: </th> | insert: </tr>
|---|---|
| insert: <p> The text from the current policy document ripe-649, "IPv4 that will be replaced is displayed here. insert: </p> insert: </td> | insert: <td> insert: <p> insert: <span class="newdifftext"> insert: <em> The proposed text change will be displayed here. insert: </em> insert: </span> insert: </p> insert: </td> | insert: </tr>
insert: </p>
insert: <div>insert: </div>
Abstract insert: </h2>
insert: <p>This document describes the RIPE community’s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region. insert: </p>
insert: <p> Information on the Address Policy WG is available at: insert: <a class="internal-link" title="" href="resolveuid/6a73933dbb6a4d9655588d6896c4c379" target="_self" data-val="6a73933dbb6a4d9655588d6896c4c379" data-linktype="internal"> insert: <br />
https://www.ripe.net/participate/ripe/wg/ap insert: </a> insert: </p>
Contents insert: </h2>
insert: <p>1.0 insert: <a class="anchor-link" title="" href="#1" target="_self"> Introduction insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">1.1 insert: <a class="anchor-link" title="" href="#11" target="_self"> Scope insert: </a> insert: </p>
insert: <p>2.0 insert: <a class="anchor-link" title="" href="#2" target="_self"> IPv4 Address Space insert: </a> insert: </p>
insert: <p>3.0 insert: <a class="anchor-link" title="" href="#3" target="_self"> Goals of the Internet Registry System insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">3.1 insert: <a class="anchor-link" title="" href="#31" target="_self"> Confidentiality insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">3.2 insert: <a class="anchor-link" title="" href="#32" target="_self"> Language insert: </a> insert: </p>
insert: <p>4.0 insert: <a class="anchor-link" title="" href="#4" target="_self"> Registration Requirements insert: </a> insert: </p>
insert: <p>5.0 insert: <a class="anchor-link" title="" href="#5" target="_self"> Policies and Guidelines for Allocations insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">5.1 insert: <a class="anchor-link" title="" href="#51" target="_self"> Allocations made by the RIPE NCC to LIRs insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">5.2 insert: <a class="anchor-link" title="" href="#52" target="_self"> Unforeseen circumstances insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">5.3 insert: <a class="anchor-link" title="" href="#53" target="_self"> Address Recycling insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">5.4 insert: <a class="anchor-link" title="" href="#54" target="_self"> Sub-allocations insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">5.5 insert: <a class="anchor-link" title="" href="#55" target="_self"> Transfers of Allocations insert: </a> insert: </p>
insert: <p>6.0 insert: <a class="anchor-link" title="" href="#6" target="_self"> Policies and Guidelines for Assignments insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">6.1 insert: <a class="anchor-link" title="" href="#61" target="_self"> Assignments to Internet Exchange Points insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">6.2 insert: <a class="anchor-link" title="" href="#62" target="_self"> Network Infrastructure and End User Networks insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">6.3 insert: <a class="anchor-link" title="" href="#63" target="_self"> Validity of an Assignment insert: </a> insert: </p>
insert: <p style="padding-left: 30px;">6.4 insert: <a class="anchor-link" title="" href="#64" target="_self"> Transfers of PI space insert: </a> insert: </p>
insert: <p>7.0 insert: <a class="anchor-link" title="" href="#7" target="_self"> Types of Address Space insert: </a> insert: </p>
insert: <p>8.0 insert: <a class="anchor-link" title="" href="#8" target="_self"> LIR Audit insert: </a> insert: </p>
insert: <p>9.0 insert: <a class="anchor-link" title="" href="#9" target="_self"> Closing an LIR by the RIPE NCC insert: </a> insert: </p>
insert: <h2>insert: <a name="1"> insert: </a> 1.0 Introduction insert: </h2>
insert: <p>The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document " insert: <a class="internal-link" title="" href="resolveuid/24c9d290050ce09f71440263ed95a927" target="_self" data-val="24c9d290050ce09f71440263ed95a927" data-linktype="internal"> Internet Registry System insert: </a> ". insert: </p>
insert: <h3 class="western">insert: <a name="11"> insert: </a> 1.1 Scope insert: </h3>
insert: <p>This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs. insert: </p>
insert: <p> This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community’s policies for ASN assignment and IPv6 are published in the RIPE Document Store at: insert: <br />
insert: <a href="http://www.ripe.net/ripe/docs/policy"> http://www.ripe.net/ripe/docs/policy insert: </a> insert: </p>
insert: <a name="2"> insert: </a> 2.0 IPv4 Address Space insert: </h2>
insert: <p>For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses: insert: </p>
insert: <ol>- insert: <li>
- insert: <p>
Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI). insert: </p>
insert: </li> insert: <li> - insert: <p>
Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used. insert: <br />
insert: </li>
For a detailed description of “Address Allocation and for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: insert: <a href="ftp://ftp.ripe.net/rfc/rfc1918.txt"> ftp://ftp.ripe.net/rfc/rfc1918.txt insert: </a> insert: <br />
For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: insert: <a href="ftp://ftp.ripe.net/rfc/rfc2993.txt"> ftp://ftp.ripe.net/rfc/rfc2993.txt insert: </a> insert: </p> insert: <li> - insert: <p>
Some address ranges are reserved for special use purposes. These are described in RFC 3330 and are beyond the scope of this document. RFC 3330 can be found at: insert: <a href="ftp://ftp.ripe.net/rfc/rfc3330.txt"> ftp://ftp.ripe.net/rfc/rfc3330.txt insert: </a> insert: </p>
insert: </li> insert: </ol>
insert: <a name="3"> insert: </a> 3.0 Goals of the Internet Registry System insert: </h2>
insert: <p>Public IPv4 address assignments should be made with the following goals in mind: insert: </p>
insert: <ol>- insert: <li>
- insert: <p>
Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified. insert: </p>
insert: </li> insert: <li> - insert: <p>
Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing. insert: </p>
insert: </li> insert: <li> - insert: <p>
Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks. insert: </p>
insert: </li> insert: <li> - insert: <p>
Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. insert: </p>
insert: </li> insert: </ol>
insert: <a name="31"> insert: </a> 3.1 Confidentiality insert: </h3>
insert: <p>Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality. insert: </p>
insert: <h3 class="western">insert: <a name="32"> insert: </a> 3.2 Language insert: </h3>
insert: <p>Please note that all communication with the RIPE NCC must be in English. insert: </p>
insert: <h2>insert: <a name="4"> insert: </a> 4.0 Registration Requirements insert: </h2>
insert: <p> All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. insert: <br />
insert: <br />
Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained). insert: </p>
insert: <a name="5"> insert: </a> insert: <strong> 5.0 Policies and Guidelines for Allocations insert: </strong> insert: </h2>
insert: <p>An allocation is a block of IPv4 addresses from which assignments are taken. insert: </p>
insert: <p>All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document. insert: </p>
insert: <h3>insert: <a name="51"> insert: </a> insert: <strong> 5.1 Allocations made by the RIPE NCC to LIRs insert: </strong> insert: </h3>
insert: <table class="plain">| insert: <p> Details of how to join the RIPE NCC can be found in the RIPE Document " insert: <a class="internal-link" title="" href="resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" target="_self" data-val="1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal"> Procedure for Becoming a Member of the RIPE NCC insert: </a> " insert: </p> insert: <p>On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: insert: </p> insert: <ol>
In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request. insert: </p> insert: </td> | insert: <td> insert: <p> Details of how to join the RIPE NCC can be found in the RIPE Document " insert: <a class="internal-link" title="" href="resolveuid/1debfd86d3d2ea24a7ce6695202c44f0" target="_self" data-val="1debfd86d3d2ea24a7ce6695202c44f0" data-linktype="internal"> Procedure for Becoming a Member of the RIPE NCC insert: </a> " insert: </p> insert: <p>On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: insert: </p> insert: <ol>
| insert: </tr>
insert: <a name="52"> insert: </a> insert: <strong> 5.2 Unforeseen circumstances insert: </strong> insert: </h3>
insert: <p>A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. insert: </p>
insert: <p>In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document. insert: </p>
insert: <h3>insert: <a name="53"> insert: </a> insert: <strong> 5.3 Address Recycling insert: </strong> insert: </h3>
insert: <table class="plain">| insert: <p> Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. insert: </p> insert: <p>This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. insert: </p> insert: </td> | insert: <td class=" "> insert: <p> insert: <span class="newdifftext"> insert: <em> Any address space that is not covered by other policies or marked to be returned to IANA, will be covered by the rules in section 5.1. This includes address space that is: insert: </em> insert: </span> insert: </p> insert: <ul>
| insert: </tr>
insert: <a name="54"> insert: </a> insert: <strong> 5.4 Sub-allocations insert: </strong> insert: </h3>
insert: <p>Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0. insert: </p>
insert: <p>LIRs wishing to convert their allocations to PA status must contact the RIPE NCC by email at insert: <a href="mailto:[email protected]"> [email protected] insert: </a> . insert: </p>
insert: <p>LIRs may make sub-allocations to multiple downstream network operators. insert: </p>
insert: <p>The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. insert: </p>
insert: <p>Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. insert: </p>
insert: <h3>insert: <a name="55"> insert: </a> insert: <strong> 5.5 Transfers of Allocations insert: </strong> insert: </h3>
insert: <table class="plain">| insert: <p class="western"> Any resource holder is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System. insert: </p> insert: <p class="western">Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers. insert: </p> insert: </td> | insert: <td class=" "> insert: <ol>
| insert: </tr>
insert: </p>
insert: <p class="western">Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis. insert: </p>
insert: <p class="western">For transfers from RIR regions that require the receiving region to have needs-based policies, recipients must provide a plan to the RIPE NCC for the use of at least 50% of the transferred resources within five years. insert: </p>
insert: <p>While the transfer is in process, during the time the internet number resources are registered in RIPE NCC service region, then RIPE policies will apply. insert: </p>
insert: <p>LIRs that receive an allocation from the RIPE NCC or a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation. insert: </p>
insert: <p>The RIPE NCC will record the change of allocation after the transfer. insert: </p>
insert: <p>The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses. insert: </p>
insert: <p>The list will contain information about approved and non-approved transfers. insert: </p>
insert: <p>The following information will be published for approved transfers: insert: </p>
insert: <ul>- insert: <li>
- insert: <p>
the name of the transferring party, insert: </p>
insert: </li> insert: <li> - insert: <p>
the block originally held by the transferring party, insert: </p>
insert: </li> insert: <li> - insert: <p>
the name(s) of the receiving party or parties, insert: </p>
insert: </li> insert: <li> - insert: <p>
each subdivided prefix (each partial block derived from that original block) transferred, insert: </p>
insert: </li> insert: <li> - insert: <p>
the date each prefix was transferred. insert: </p>
insert: </li> insert: </ul>
Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published insert: </p>
insert: <ul>- insert: <li>
- insert: <p>
the number of requested transfers not approved after the RIPE NCC’s evaluation, insert: </p>
insert: </li> insert: <li> - insert: <p>
the sum of the number of addresses included in the requested transfers. insert: </p>
insert: </li> insert: <li> - insert: <p>
Neither the blocks nor the organizations involved will be identified in these statistics. insert: </p>
insert: </li> insert: </ul>
Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied. insert: </p>
insert: <p>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. insert: </p>
insert: <h2>insert: <a name="6"> insert: </a> insert: </h2>
insert: <h2>6.0 Policies and Guidelines for Assignments insert: </h2>
insert: <h3>insert: <a name="61"> insert: </a> insert: <strong> 6.1. Assignments to Internet Exchange Points insert: </strong> insert: </h3>
insert: <p>A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following: insert: </p>
insert: <ul>- insert: <li>
- insert: <p>
This space will be used to run an IXP peering LAN; other uses are forbidden. insert: </p>
insert: </li> insert: <li> - insert: <p>
Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE document "IPv6 Address Space for Internet Exchange Points". insert: </p>
insert: </li> insert: <li> - insert: <p>
IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment. insert: </p>
insert: </li> insert: <li> - insert: <p>
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. insert: </p>
insert: </li> insert: <li> - insert: <p>
IP space returned by IXPs will be added to the reserved pool maintained for IXP use. insert: </p>
insert: </li> insert: <li> - insert: <p>
Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN. insert: </p>
insert: </li> insert: </ul>
insert: <a name="62"> insert: </a> insert: <strong> 6.2 Network Infrastructure and End User Networks insert: </strong> insert: </h3>
insert: <p>IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. insert: </p>
insert: <p> An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at: insert: <a class="internal-link" title="" href="resolveuid/5310257d0a74134fb1fd6977cd9517ed" target="_self" data-val="5310257d0a74134fb1fd6977cd9517ed" data-linktype="internal"> insert: <br />
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/getting-started insert: </a> insert: </p>
insert: <a name="63"> insert: </a> insert: <strong> 6.3 Validity of an Assignment Policies for insert: </strong> insert: </h3>
insert: <p class="western">An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid. insert: </p>
insert: <h3 class="western">insert: <a name="64"> insert: </a> 6.4 Transfers of PI space insert: </h3>
insert: <p class="western">Any holder of Provider Independent (PI) address space is allowed to re-assign complete or partial blocks of IPv4 address space that were previously assigned to them by the RIPE NCC. insert: </p>
insert: <p class="western">Address space may only be re-assigned in accordance with the RIPE Policy, “ insert: <a class="western external-link" title="" href="http://www.ripe.net/participate/docs/contract-req" target="_self"> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" delete: </a> delete: </li> delete: <li> delete: <a class="internal-link" href="resolveuid/4d76cb50bc644534a7d2da60a8523d25" target="_self" title="" data-val="4d76cb50bc644534a7d2da60a8523d25" data-linktype="internal"> Amendments to existing policy document ripe-581, "Policy For Reverse Address Delegation of IPv4 and IPv6 Region insert: </a> ”. insert: </p>
insert: <p class="western">Re-assignments must be reflected in the RIPE Database. This re-assignment can either be on a permanent or non-permanent basis. insert: </p>
insert: <p class="western">Parties that receive a re-assignment from another party cannot re-assign complete or partial blocks of the same address space to another party within 24 months of receiving the re-assignment. insert: </p>
insert: <p class="western">The RIPE NCC will record the change of PI assignment after the transfer. insert: </p>
insert: <p class="western">The RIPE NCC will publish a separate list of all PI assignments transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses. insert: </p>
insert: <p class="western">The list will contain information about approved and non-approved transfers. insert: </p>
insert: <p class="western">The following information will be published for approved transfers: insert: </p>
insert: <ul>- insert: <li>
- insert: <p class="western">
The name of the transferring party insert: </p>
insert: </li> insert: <li> - insert: <p class="western">
The block originally held by the transferring party insert: </p>
insert: </li> insert: <li> - insert: <p class="western">
The name(s) of the receiving party or parties insert: </p>
insert: </li> insert: <li> - insert: <p class="western">
Each subdivided prefix (each partial block derived from that original block) transferred insert: </p>
insert: </li> insert: <li> - insert: <p class="western">
The date each prefix was transferred insert: </p>
insert: </li> insert: </ul>
Non-approved transfers will be published in aggregate statistics. In the statistics the following information will be published: insert: </p>
insert: <ul>- insert: <li>
- insert: <p class="western">
The number of requested transfers not approved after the RIPE NCC’s evaluation insert: </p>
insert: </li> insert: <li> - insert: <p class="western">
The sum of the number of addresses included in the requested transfers insert: </p>
insert: </li> insert: </ul>
Neither the blocks nor the organizations involved will be identified in these statistics. insert: </p>
insert: <p class="western">Please note that the transferring party always remains responsible for the entire assignment it receives from the RIPE NCC until the transfer of address space to another party is completed or if the address space is returned. insert: </p>
insert: <p class="western">Re-assigned blocks are no different from PI assignments made directly by the RIPE NCC and so must be used by the receiving party according to the policies described in this document. insert: </p>
insert: <h2>insert: <a name="7"> insert: </a> insert: <strong> 7.0 Types of Address Space in the insert: </strong> insert: </h2>
insert: <p>LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. insert: </p>
insert: <p>Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: insert: </p>
insert: <p>insert: <em> Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. insert: </em> insert: </p>
insert: <p>LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are: insert: </p>
insert: <table class="plain"> insert: <ul>
| insert: <td> insert: <ul>
| insert: </tr>
insert: </p>
insert: <ul>- insert: <li>
- insert: <p>
ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR or RIR. Assignments may be PA or PI. This status is intended to document past allocations where assignments of both types exist. It is avoided for new allocations. Sub-allocations cannot be made from this type of address space. insert: </p>
insert: </li> insert: <li> - insert: <p>
SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider. insert: </p>
insert: </li> insert: <li> - insert: <p>
LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific insert: <strong> inetnum insert: </strong> must be registered. insert: </p>
insert: </li> insert: <li> - insert: <p>
LIR-PARTITIONED PI: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific insert: <strong> inetnum insert: </strong> must be registered. insert: </p>
insert: </li> insert: <li> - insert: <p>
EARLY-REGISTRATION: This is used by the RIPE Database administration when transferring pre-RIR registrations from the ARIN Database. The value can be changed by database users (except for ALLOCATED PA). Only the RIPE Database administrators can create objects with this value. insert: </p>
insert: </li> insert: <li> - insert: <p>
NOT-SET: This indicates that the registration was made before the "status:" attributes became mandatory for inetnum objects. The object has not been updated since then. New objects cannot be created with this value. The value can be changed by database users. insert: </p>
insert: </li> insert: <li> - insert: <p>
ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. insert: </p>
insert: </li> insert: <li> - insert: <p>
ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties. insert: </p>
insert: </li> insert: <li> - insert: <p>
ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services. insert: </p>
insert: </li> insert: </ul>
The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status. insert: </p>
insert: <p>Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate. insert: </p>
insert: <p>In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. insert: </p>
insert: <p>The RIPE NCC Service Region" delete: </a> no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. insert: </p>
insert: <h2>insert: <a name="8"> insert: </a> insert: <strong> 8.0 LIR Audit insert: </strong> insert: </h2>
insert: <p>The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community's policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at: insert: <a class="external-link" title="" href="http://www.ripe.net/publications/docs/audit" target="_self"> http://www.ripe.net/publications/docs/audit insert: </a> insert: </p>
insert: <h2>insert: <a name="9"> insert: </a> insert: <strong> 9.0 Closing an LIR by the RIPE NCC insert: </strong> insert: </h2>
insert: <p class=" ">The RIPE NCC may close an LIR for any of the following reasons: insert: </p>
insert: <ul>- insert: <li>
- insert: <p>
the LIR does not pay money owed to the RIPE NCC insert: </p>
insert: </li> insert: <li> - insert: <p>
the LIR cannot be contacted by the RIPE NCC for a significant period of time insert: </p>
insert: </li> insert: <li> - insert: <p>
the LIR consistently violates the RIPE community's policies insert: </p>
The RIPE NCC takes on responsibility for address space held by closing LIRs. insert: </p>