Inter-RIR Transfers

While IP addresses and AS Numbers can be transferred within the RIPE NCC service region, you can also transfer them to networks in the service region of another Regional Internet Registry (RIR). These are called inter-RIR transfers. It is important to note that each RIR has its own unique policy framework, which means that different requirements can apply.

Here is an overview of all RIRs facilitating inter-RIR transfers and their policy:

Inter-RIR transfers must first be approved by both the RIPE NCC and the other RIR before they can be processed.

Note: Internet number resources remain subject to the policies of the RIR they are registered with until the transfer has been completed. Once the transfer is completed and both RIRs update their registries, the resources fall under the recipient RIR's policies.

Which Resources Can Be Transferred

Because each RIR has its own policy framework, there are some differences in terms of what kinds of resources can be transferred between certain RIRs. The table below shows this in more detail. AFRINIC does not currently have an inter-RIR policy. This means that no resources of any kind can be transferred to/from this region.

Overview:


RIPE NCC	←	IPv4, ASN (including legacy)	←	ARIN
RIPE NCC	←	IPv4, ASN (including legacy)	←	APNIC
RIPE NCC	←	IPv4 (including legacy)	←	LACNIC

When resources are transferred from another RIR to the RIPE NCC, we will determine the status of these together with the receiving party. Resources with the LEGACY status can keep this status. Please see options below.

Resource Registration Options

ALLOCATED PA (PROVIDER AGGREGATABLE)
Addresses with this status can only be held by RIPE NCC members. These addresses can be used to make assignments to other parties.

ASSIGNED PI (PROVIDER INDEPENDENT)
Addresses with this status can be held by RIPE NCC members or by non-members registered through a sponsoring LIR. It is not possible to make further assignments to other parties.

LEGACY
The offering RIR will inform the RIPE NCC if a resource has the LEGACY status (i.e. resources distributed prior to the RIR system that exists today). The status can remain LEGACY or can be converted to another status if the receiving party has a contractual relationship with the RIPE NCC or a sponsoring LIR (ASNs and IPv4 ASSIGNED PI only).

Note: A contractual relationship with the RIPE NCC is not required to receive a transfer of resources with the LEGACY status. However, it is required if you want to use RPKI.

Who Can Request an Inter-RIR Transfer

From the RIPE NCC to another RIR

RIPE NCC members (LIRs), non-members through their sponsoring LIR and Legacy resource holders without a contractual relationship with the RIPE NCC.

From another RIR to the RIPE NCC

Any resource holder in the respective RIR.

How to Submit an Inter-RIR Transfer Request

We will evaluate all requests in accordance with the transfer policies and the procedural document Inter-RIR Transfer of Internet Number Resources.

Transfers from the RIPE NCC to another RIR

a. The transferring party needs to complete the inter-RIR transfer template and send an email with their request to [email protected].

b. We will ask for the following documents according to our due diligence process:

For legal persons: Recent registration document from the relevant national authorities.
For natural persons: A digital copy of the passport or another valid ID document. The validity of the document will be verified by a third party called iDenfy
The confirmation letter of the request for transfer, signed by a company director that is legally authorised to sign/act on behalf of the party within the RIPE NCC service region.
For legacy resources without a contractual relationship with the RIPE NCC or a sponsoring LIR, the transferring party needs to submit this confirmation letter instead, signed by a company director that is legally authorised to sign/act on behalf of the party within the RIPE NCC service region.

c. We will start evaluating your request as soon as we receive an email with the supporting documents.

d. Once your request has been approved, we will notify the receiving RIR, who will start their evaluation and contact the receiving party in order to complete the transfer.

e. Once the transfer request has been approved by the other RIR, both RIRs will proceed with updating their registries on a specified date.

f. On that date, we will make any necessary updates in the RIPE Database. The party within the RIPE NCC service region must assist the RIPE NCC with all appropriate actions needed for this update (e.g. removing or updating any related RIPE Database objects). The other RIR will update their registry accordingly.

Transfers from another RIR to the RIPE NCC

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.

If the receiving party does not have a contractual relationship with the RIPE NCC, it will need to establish one prior to the evaluation of the transfer request. In the case of ASSIGNED PI, a sponsoring LIR may be used instead. Please note that this is not required for resources with the LEGACY status.

An Inter-RIR transfer must start in the originating service region. A request should be submitted through the relevant RIR’s communication channel. The originating RIR will evaluate the request and contact the RIPE NCC once approved.

We will then contact the receiving party and perform due diligence checks.

a. We will ask for the following documents according to our due diligence process:

For legal persons: Recent registration document from the relevant national authorities.
For natural persons: A digital copy of the passport or another valid ID document. The validity of the document will be verified by a third party called iDenfy.
The confirmation letter for the request for transfer signed by a company director that is legally authorised to sign/act on behalf of the party within the RIPE NCC service region.
For IPv4: the desired status of the to-be-transferred IPv4 addresses.
For legacy resources where the receiving party decides not to have a contractual relationship with either the RIPE NCC or a sponsoring LIR, then this confirmation letter needs to be submitted instead, signed by a company director that is legally authorised to sign/act on behalf of the party within the RIPE NCC service region.
(If necessary) End User Assignment Agreement.
(If necessary) Legacy Agreement.
For transfers from an RIR with policies that require the receiving RIR to adhere to a needs-based policy, the recipient must provide us with a plan for the use of at least 50% of the transferred resources within five years.

Once the transfer request is approved, we will notify the other RIR and both RIRs will proceed with updating their registries on a specified date. An acknowledgement will be sent to the receiving party.

b. On that date, we will make any necessary updates in the RIPE Database (e.g. create the resource objects) and notify the receiving party or their sponsoring LIR. It is the responsibility of the receiving party to create any further (route/domain) objects in the RIPE Database.

Note: Inter-RIR transfers require considerably more work than regular transfers. Coordination between the RIRs (in different time zones) is required to ensure compliance with relevant policies in both regions, and updates to the RIR registries must be synchronised to ensure correct registration. Because of this, processing transfers between RIRs will take longer than transfers within the RIPE NCC service region.

Affected Services

Because inter-RIR transfers involve moving resources from one RIR registry to another, the following services may be affected and likely won't be available immediately.

Reverse DNS

From the RIPE NCC to another RIR
All associated objects in the RIPE Database, including DOMAIN objects, will be deleted. Any reverse delegation for the resources will be removed from the DNS immediately and it is the responsibility of the receiving party to immediately request reverse DNS delegation in the registry of the other RIR.

From another RIR to the RIPE NCC
It is the responsibility of the receiving party to create DOMAIN objects in the RIPE Database to request reverse DNS delegation for the associated address space. It may take up to 24 hours for the reverse delegation to appear in the DNS.

RPKI

From the RIPE NCC to another RIR
When resources are transferred out of the RIPE NCC service region, we will shrink or revoke the resource certificate for these resources as soon as the transfer is completed. Any ROAs issued for these resources will become invalid and will be removed. When and if these resources are eligible for certification in the receiving region depends on this region RIR’s policy. Announcements for these resources will appear with an "RPKI Unknown" status until ROAs have been issued in the receiving region.

From another RIR to the RIPE NCC
Once the transfer has been completed, the resource certificate issued in the originating region will be shrunk or revoked depending on this region's policy. If the resources are certifiable, we will issue a resource certificate within a few minutes after completing the transfer. You will then be able to issue ROAs for the newly received resources. In the meantime, any announcements for these resources will appear as "RPKI Unknown" and not as "Invalid", because there will be no other ROAs existing for these resources.

Relevant Policies

Inter-RIR transfers in our service region are regulated by the following RIPE policies and procedural documents:

If you have any questions related to inter-RIR transfers that are not answered through these pages you can contact us at [email protected].