Changes to Policy for Inter-RIR Transfers of Internet Resources

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>

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>

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.

delete: <p> The proposed policy asks the RIPE NCC to define the communication and operational procedure with the RIR involved in the transfer. delete: </p> delete: <h3> Applicable Types of Internet Resources delete: </h3> delete: <p> Currently the RIPE NCC service region has a transfer policy for IPv4 Provider Aggregatable (PA) allocations and IPv4 Provider Independent (PI) assignments. If this proposal is accepted, it will be possible to transfer these resources to and from the RIPE NCC service region. IPv4 PA allocations and IPv4 PI assignments transferred to the RIPE NCC service region will be considered as registrations made directly by the RIPE NCC. Existing RIPE Policies will be applied to IPv4 resources. delete: </p> delete: <p> The RIPE NCC will only register resources if the network that will be using them has at least one active element located in the RIPE NCC service region. This is in line with the current practice of only allocating or assigning resources for use in our service region. delete: </p> delete: <p> Legacy resources that are transferred to the RIPE NCC service region, and have not had their legacy status revoked by the transferring RIR, will be treated as legacy according to RIPE Policy. If they have lost their legacy status, they will be handled in accordance with the RIPE Policies corresponding to their new status. delete: </p> delete: <p> IPv4 PA allocations, IPv4 PI assignments and legacy resources transferred from the RIPE NCC service region to another RIR will receive the status defined by the policies and contracts of the receiving RIR. Currently no other Internet number resources can be transferred. delete: <b> delete: </b> delete: </p> delete: <h3> Applicable Policy delete: </h3> delete: <p> The proposed policy asks the RIPE NCC to process a transfer only if it complies with the relevant policies in the relevant RIR service regions. It is the RIPE NCC’s understanding that the resources to be transferred would remain subject to the policies of the sending RIR until the transfer is completed. After the transfer has been completed, the resource will be under the policy of the receiving RIR. delete: </p> delete: <p> The proposed policy can only apply between Regional Internet Registries (RIR) with a compatible inter-RIR transfer policies. delete: </p> delete: <p> The RIPE NCC cannot guarantee that the other RIR will agree to a resource transfer, even if it is approved by the RIPE NCC. The requirement to ensure consistency between RIRs means that both registries have to be in agreement to execute a transfer. In situations where a transfer is not accepted by one of the involved registries, it can not be completed. The RIPE NCC can not, on its own, ensure that the policy requirements of the other RIR are met. Failure to comply with any RIR policy in such cases could lead to a difference of opinion on whether a transfer is acceptable between the transferring and receiving RIRs. delete: </p> delete: <p> The proposed policy text has no defined limit on the desired level of policy compliance towards the RIRs involved and suggests that the RIPE NCC adopts procedures and coordinates with the other registry in fulfilling requirements for the transfer to succeed. delete: <b> delete: </b> delete: </p> delete: <h3> Transfer Period delete: </h3> delete: <p> It is the RIPE NCC’s understanding that a resource transfer can be on a permanent or non-permanent basis. Temporary transfers will be moved back from the RIPE Registry to the transferring RIR once the transfer period has ended. delete: <b> delete: </b> delete: </p> delete: <h3> Deregistration delete: </h3> delete: <p> Resources that are permanently transferred to the RIPE NCC service region, and are later deregistered (for any reason), will be added to the RIPE NCC’s pool of available resources. delete: <b> delete: </b> delete: </p> delete: <h3> Documentation delete: </h3> delete: <p> The RIPE NCC will publish a list of transferred resources between RIRs if this is required in the applicable transfer policy for the RIPE NCC service region. Similarly, if the applicable transfer policy contains a holding period for received resources, then this will also apply to resources received from other RIR regions. delete: <b> delete: </b> delete: </p> delete: <h3> Arbitration delete: </h3> delete: <p> The potential for disagreement between RIRs on policy compliance could require cross-registry arbitration to resolve such conflicts, for example if a member of the RIPE NCC disagrees with the decision of another RIR. The RIPE NCC Conflict Arbitration procedure does not include appeals of this nature and can only settle disputes between members and the RIPE NCC, between members, and between legacy Internet resource holders and the RIPE NCC. delete: </p> delete: <p>   delete: </p> delete: <h2> B. Impact of Policy on Registry and Addressing System delete: </h2> delete: <p> Address/Internet Number Resource Consumption: delete: </p> delete: <p> 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. delete: </p> delete: <p> Fragmentation/Aggregation: delete: </p> delete: <p> If it is accepted, the proposal would likely result in increased deaggregation, as existing IP ranges could be split and transferred in parts. The RIPE NCC has no historical data to estimate the likely amount of deaggregation.  delete: </p> delete: <p>   delete: </p> delete: <h2> C. Impact of Policy on RIPE NCC Operations/Services delete: </h2> delete: <h3> Registration Services:  delete: </h3> delete: <h3> Amount of Requests delete: </h3> delete: <p> In the RIPE NCC service region there are more than 23,000 PA allocations, more than 22,000 PI assignments, and more than 5,000 legacy resources that can potentially be transferred. This is in addition to all of the eligible prefixes registered in other RIR service regions that could be transferred. delete: </p> delete: <p> At least 800 PA allocation transfers are expected to be processed within the RIPE NCC service region by the end of 2014. The RIPE NCC has seen a considerable increase in transfer activity since 2012. A similar number of inter-RIR transfers will likely result if the proposal is accepted, though the RIPE NCC is unable to provide an actual estimate.  delete: </p> delete: <h3> Inter-RIR Coordination and Evaluation of Requests  delete: </h3> delete: <p> If this proposal reaches consensus and is deemed compatible by other RIRs, the Registration Services Department will process requests to transfer resources to or from the RIPE NCC service region: “when Internet number resources are transferred to another RIR, the RIPE NCC will work with the receiving RIR to allow the transfer to the receiving resource holder” and “when Internet number resources are transferred from another RIR, the RIPE NCC will work with the resource holder to fulfil any requirements of the sending RIR.” This means that the RIPE NCC may need to evaluate the transfer requests according to policies set by other RIR communities. delete: </p> delete: <p> In this context, it is important to highlight that maintaining the inter-RIR transfer framework is expected to require considerably more work than transfers within the RIPE NCC service region. Inter-RIR transfers would require the RIPE NCC to evaluate transfer requests according to the policies and procedures of multiple RIRs delete: <i> . delete: </i> Each RIR might have different requirements delete: <i> . delete: </i> In order to create and maintain this knowledge base, the RIPE NCC will have to increase its coordination effort with the other RIRs. Furthermore, it is expected that a mechanism would need to be established to allow other RIRs to review whether the RIPE NCC’s evaluation of their requirements matches their expectations. This work is expected to require a considerable amount of time and resources. delete: </p> delete: <h3> Billing/Finance Department: delete: </h3> delete: <p> 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. delete: </p> delete: <h3> RIPE Database and DNS: delete: </h3> delete: <p> The RIPE Database will reflect inter-RIR transfers. delete: </p> delete: <p> For prefixes transferred to the RIPE NCC service region, resource holders will be able to setup reverse DNS in the RIPE Database based on the existing inter-RIR DNS information exchange delete: <b> . delete: </b> delete: </p> delete: <h3> Software Engineering: delete: </h3> delete: <p> Software development will be needed to process inter-RIR transfers. Given the information that is currently available, a medium impact is expected, with between two and three months needed to develop the necessary software tools. delete: </p> delete: <p>   delete: </p> delete: <h2> D. Legal Impact of Policy delete: </h2> delete: <h3> Contractual Relationship delete: </h3> delete: <p> The RIPE NCC can only evaluate a transfer request for resources that are subject to a contract, except in the case of legacy resources. Requests to transfer legacy resources can be evaluated without a contract, though the other RIR may have concrete contractual requirements in these cases. delete: </p> delete: <h3> delete: <b> Transfer Procedure and Due Diligence delete: </b> delete: </h3> delete: <p> A procedure will need to be drafted that outlines the transfer procedure and due diligence checks of all the RIRs involved in inter-RIR transfers. delete: <b> delete: </b> delete: </p> delete: <h3> Shift of Responsibility – Updates on Contracts delete: </h3> delete: <p> Until the transfer is completed, the transferring party is responsible for complying with the transferring RIR’s policies and any relevant contractual and legal obligations with regards to the resources to be transferred. delete: </p> delete: <p> After the transfer is completed, the transferring party may need to update their contract so that the resources are no longer subject to it anymore. The receiving party is responsible for complying with the receiving RIR’s policies. The existing contractual obligations of the receiving party will have to extend to the transferred resources. A new contract may therefore need to be signed or the existing contract may need to be updated in order to include the transferred resources (e.g. if legacy resources are transferred to or from the RIPE NCC service region, the existing contract with the RIPE NCC or a RIPE NCC member will need to be updated accordingly). The receiving party will also be responsible for any other legal obligations regarding to the transferred resources. delete: </p> delete: <h3> Responsibility for the Evaluation delete: </h3> delete: <p> The requirements for a transfer to be approved by the RIPE NCC may be different from those of other RIRs. According to the proposal, the RIPE NCC “will work with the resource holder to fulfil any requirements of the sending RIR” and “will comply with the commitments imposed by the receiving RIR” in order to facilitate the transfer. delete: <br /> delete: <br /> When the other RIR has additional requirements, the RIPE NCC will work with the resource holder to comply with these. This will require the RIPE NCC to share confidential information about the resource holder with the other RIR, though it will only do so if it has the resource holder’s approval. The RIPE NCC will also need to draft and sign an NDA with the other RIR regarding the third party information shared. delete: </p> delete: <p>   delete: </p> delete: <h2> E. Implementation delete: <b> delete: </b> delete: </h2> delete: <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 inter-RIR transfers in internal RIPE NCC systems. The RIPE Registry will document transfers and received resources. New processes and documentation will also need to be created in coordination with other RIRs. delete: </p> delete: <p> It is important to note that the implementation will only establish the framework for the RIPE NCC to process inter-RIR transfers. The actual execution will be dependant on matching policies and procedures between the RIRs involved. delete: </p>

Draft documents relating to "Policy for Inter-RIR Transfers of Internet Resources":

1. 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>
2. 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>

  insert: </p>