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.
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.
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.
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.
RIPE NCC members (LIRs), non-members through their sponsoring LIR and Legacy resource holders without a contractual relationship with the RIPE NCC.
Any resource holder in the respective RIR.
We will evaluate all requests in accordance with the transfer policies and the procedural document Inter-RIR Transfer of Internet Number Resources.
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:
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.
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:
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.
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.
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.
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.
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].