Changes to Policy for Inter-RIR Transfers of Internet Resources
Legend | (+) Added | (-) Deleted |
---|---|---|
Changed | Tag Added | Tag Deleted |
Summary of Proposal
This policy proposal describes how the transfer of Internet number resources will occur between resource holders in the RIPE NCC service region and those in other Regional Internet Registry (RIR) service regions.
The policy should be the same for transfers both outside and within and outside the RIPE NCC service region. If another RIR has a different policy, the RIPE NCC should create an operational procedure that satisfies the requirements of both RIRs in order procedure, in cooperation with that RIR, to allow transfers to and from its service region. In all cases, the registries of the different RIRs must be consistent.
With this policy, legacy resources can be transferred to or from the RIPE NCC service region, in spite of the fact there is there is no specific transfer policy for them. delete: </p> delete: <p> Amendments to the existing policy, policy “ delete: <a href="http://www.ripe.net/ripe/docs/ipv4-policies"> insert: <a class="external-link" href="http://www.ripe.net/ripe/docs/ipv4-policies" target="_self" title=""> IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region ”, ” are also proposed proposed, to bring it in into line with the new policy.
insert: <br />
insert: <br />
Policy Text
a. New Policy
Abstract:
This policy describes the transfer of Internet number resources between a resource holder an LIR of another Regional Internet Registry (RIR) and an entity or LIR within the RIPE NCC service region and a resource holder of another Regional Internet Registry (RIR). region. insert: <b> insert: </b>
1.0 Introduction
This policy outlines the rules for Internet number resource transfers between the RIPE NCC and other RIR service regions.
1.1 Scope
The policy for transferring Internet number resources to or from the RIPE NCC service region will be general for any resource. A transfer policy must exist for each type of Internet number resource within the RIPE NCC service region. With this policy, legacy resources can be transferred to or from the RIPE NCC service region, in spite of the fact there is there is no specific transfer policy for them. insert: <b> insert: </b>
2.0 Transferring Internet Resources to the RIPE NCC Service Region
The RIPE NCC shall accept all transfers of Internet number resources to its service region, provided they comply with the policies relating to transfers within its service region.
When Internet number resources are transferred from another RIR, the RIPE NCC will work with the resource holder its member LIR to fulfil any requirements of the sending RIR.
3.0 Transferring Internet Resources from the RIPE NCC Service Region
When transferring Internet number resources to another RIR, the RIPE NCC will follow the transfer policies that apply within its own service region. The RIPE NCC will also comply with the commitments imposed by the receiving RIR, in order to facilitate the transfer. transfer. insert: </p>
insert: <p>
b. Modification to existing policy document ripe-623 RIPE-606
[The following text will update section 5.5 in the RIPE Policy Document ripe-623, “ delete: <a href="http://www.ripe.net/ripe/docs/ipv4-policies"> insert: <a class="external-link" href="http://www.ripe.net/ripe/docs/ipv4-policies" target="_self" title=""> IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region ”, if the proposal reaches consensus.]
delete: <h3> insert: <h4>insert: <b> b.a. insert: </b> insert: <b> Current policy text delete: </h3> insert: </b> insert: </h4>
insert: <b> 5.5 Transfers of Allocations insert: </b>
Any LIR 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 LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation.
Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.
LIRs that receive 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.
[…]
delete: <h3> insert: <h4>b.b. New policy text delete: </h3> insert: <b> insert: </b> insert: </h4>
insert: <b> 5.5 Transfers of Allocations insert: </b>
Any resource holder LIR 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 LIR that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation.
Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.
When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving RIR to allow the transfer to the receiving resource holder. LIR.
When Internet number resources are transferred from another RIR, the RIPE NCC will work with the resource holder its member LIR to fulfil any requirements of the sending RIR.
Resource holders If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources. insert: </p>
insert: <p style="padding-left: 30px; ">LIRs that receive a re-allocation from another resource holder LIR cannot re-allocate complete or partial blocks of the same address space to another resource holder LIR within 24 months of receiving the re-allocation.
[…]
Rationale
a. Arguments supporting the proposal insert: <b> insert: <br />
insert: </b>
- Provides a minimal framework for inter-RIR Internet number resource transfers that doesn’t set any new rules on either party or the resources involved
- Can be applied to multiple resources insert: </ul>
- Increases the supply of IPv4 addresses available to RIPE NCC resource holders LIRs
- Maintains the integrity of the RIPE Database and ensures the RIPE NCC is part of the approval and transfer process insert: </ul>
- Allows resource holders in the RIPE NCC service region RIPE NCC entities to participate in a market already available to ARIN and APNIC resource holders LIRs
- Allows RIPE NCC members with excess resources to transfer to these to networks in other RIR regions
b. Arguments opposing the proposal
- Resource holders LIR’s with excess IPv4 addresses in the RIPE NCC service region may not wish to expand IPv4 inventories in the region delete: </li> delete: <li> Other RIRs may have needs justification requirements, and it is not within the RIPE NCC’s power to do anything about this other than guide its resource holders through the transfer process delete: </li> delete: </ul> delete: <p> delete: </p> delete: <hr /> delete: <h2> delete: <a name="impact-analysis"> delete: </a> Impact Analysis delete: </h2> delete: <p> In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. This analysis is 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. delete: <b> delete: </b> delete: </p> delete: <h2> Executive Summary delete: </h2> delete: <ol> delete: <li> The proposed policy sets a general framework for inter-RIR resource transfers delete: </li> delete: <li> Executing inter-RIR transfers successfully depends on the other RIRs having compatible policies: ARIN sees no compatibility with its current policy, APNIC will ask its community for guidance region.
- The proposed inter-RIR transfer policy would apply to IPv4 PA allocations, IPv4 PI assignments and legacy resources delete: </li> delete: <li> Resources being transferred would remain subject to the policies of the sending proposal will re-introduce operational needs justification, if any RIR until the transfer is completed delete: </li> delete: <li> For resource transfers to the RIPE NCC service region, the RIPE NCC will fulfil any requirements the sending RIR may have delete: </li> delete: <li> The RIPE NCC Registration Services Department expects a considerable increase in administrative work if the proposal is accepted delete: </li> delete: </ol> delete: <h2> Note: Compatibility with other RIRs delete: <b> delete: </b> delete: </h2> delete: <p> The proposed policy sets a general framework for transferring Internet number resources between the RIPE NCC service region and other Regional Internet Registry (RIR) service regions. The effectiveness and execution of the proposed policy depends not only insists on its implementation by the RIPE NCC, but also on its acceptance by the other RIRs. The RIPE NCC has therefore contacted the other RIRs with inter-RIR transfer policies in place (APNIC and ARIN) for feedback. delete: </p> delete: <p> The following statement has been received from APNIC and ARIN: delete: </p> delete: <p> delete: <i> “After consulting with both ARIN and APNIC, the two RIRs have confirmed how ARIN policy requires ‘needs based’, explicitly stated, policy principals to be in place to allow for inter-RIR resource transfers, and that APNIC’s has the same needs based principles explicitly stated in its policy document. RIPE policy document ripe-622 (paragraph 5.1, sub 3), addresses a needs base in an implicit manner. It is therefore not possible for the APNIC secretariat to interpret this and take a position. The APNIC secretariat indicates that it will consult their community this, in order to get guidance on how to proceed. ARIN staff notes that the lack of a specific needs-based requirement in the RIPE policy document will prevent the policy from being deemed compatible with ARIN's Inter-RIR transfer policy requirements to the RIPE region (although its adoption will have no effect on Inter-RIR transfers between ARIN and the APNIC region.)” delete: </i> delete: </p> delete: <p> It is therefore important to note that the following impact analysis focuses on the interpretation and implementation details only as they relate to the RIPE NCC. It only considers situations in which another RIR allows transfers to or from the RIPE NCC service region. This may not be possible at the time of writing and depends on policy development in other regions. delete: </p> delete: <p> delete: </p> delete: <h2> A. RIPE NCC's Understanding of the Proposed Policy delete: <b> delete: </b> delete: </h2> delete: <h3> General delete: </h3> delete: <p> The proposed policy sets a general framework for transferring Internet number resources between RIPE NCC members and resource holders in other Regional Internet Registry (RIR) service regions. delete: </p> delete: <p> Resources may be transferred to and from the RIPE NCC service region if: delete: </p> delete: <ul> delete: <li> There is a policy allowing these resources to be transferred within the RIPE NCC service region (legacy resources can be transferred although there is no relevant transfer policy) delete: </li> delete: <li> The transfer is in accordance with the existing RIPE Policy on transfers within the RIPE NCC service region delete: </li> delete: <li> The transfer is compatible with the other RIR’s policy on inter-RIR transfers certain transfers.
Draft documents relating to "Policy for Inter-RIR Transfers of Internet Resources":
- delete: <a class="internal-link" href="resolveuid/4d39309c8f56481388f11e4b49bc2685" target="_self" title="" data-val="4d39309c8f56481388f11e4b49bc2685" data-linktype="internal"> delete: <span class="internal-link"> insert: <a class="internal-link" href="resolveuid/f659ab4db90d4c03885a68970895aff4" target="_self" title="2014-05:Draft: Policy for Inter-RIR Transfers of Internet Resources - New Policy Text" data-val="f659ab4db90d4c03885a68970895aff4" data-linktype="internal"> New policy delete: </span>
- delete: <a class="internal-link" href="resolveuid/79bce202b89c46aa9800426cfc4eaf00" target="_self" title="" data-val="79bce202b89c46aa9800426cfc4eaf00" data-linktype="internal"> insert: <a class="internal-link" href="resolveuid/710d99d9022742f4b8893b132189a7ba" target="_self" title="" data-val="710d99d9022742f4b8893b132189a7ba" data-linktype="internal"> Amendments to existing policy document ripe-623 ripe-606
insert: </p>