Everything 8.3 & 8.4 Transfer Source and Recipient Organizations Need to Know
If you are a source organization involved in a transfer to specified recipients within the ARIN region (NRPM 8.3) or an inter-RIR transfer (NRPM 8.4), you are responsible for taking the necessary steps to ensure a clean transition between resource holders.
This overview outlines the actions you must take to prevent issues with your Route Origin Authorizations (ROAs) and Internet Routing Registry (IRR) or reverse DNS records when transferring resources to another organization.
At the conclusion of the transfer, recipient organizations should also review, update, or create any associated ROAs, IRR objects, and reverse DNS settings to ensure the routing security of the transferred resources.
ROA Best Practices for Source Organizations
It is the source organization’s responsibility to thoroughly review and update any ROAs associated with the resources being transferred. This is necessary to ensure that no transferring resources are included in any active ROAs.
- Before you submit a transfer: Confirm that the resources are not in any of your ROAs.
- If resources are in a multi-prefix ROA: Modify the ROA to remove the transferring prefix(es).
- If resources are in a single-prefix ROA: The ROA will be removed automatically at the time of transfer.
IRR Best Practices
It is also important to review IRR records and make updates related to the transferring resources. This clears the way for the recipient organization to update their IRR entries at the conclusion of the transfer process.
- Before the transfer: The source organization should review any route/route6 objects that reference the transferring prefixes. If they won’t apply after the transfer, update or remove them.
- After transfer: The recipient organization is responsible for publishing their authoritative IRR entries.
Reverse DNS Best Practices
If you manage authoritative reverse zones for the transferring space, you are responsible for coordinating the changes. Both the source and recipient organizations are responsible for updating the affected reverse DNS delegations to point to the correct nameservers.
- Before transfer: The source should confirm that the recipient (or their DNS provider) is ready to accept new delegations.
- After transfer: The recipient should verify that the delegations now point to the correct nameservers.
Source Pre-Transfer Checklist
Use this quick checklist when you are the source on an 8.3/8.4 transfer:
- Edit or delete transferring prefixes from source ROAs.
- Review maxLength values and update if needed.
- Update or remove IRR objects that no longer apply after the transfer.
- Coordinate a reverse DNS delegation plan with the recipient.
- Ensure the recipient understands they are responsible for creating their ROAs/IRR records and updating reverse DNS after the transfer.
A Note on Transfers and ARIN RPKI
When a transfer is completed, the source organization’s ARIN Resource Public Key Infrastructure (RPKI) certificate is automatically re-rolled to reflect the change. ROAs that contain remaining certified resources at the source are automatically re-rolled and retained by the source organization.
If you are the recipient and already have an ARIN RPKI certificate, that certificate will automatically renew to include the newly transferred resources. However, you are responsible for creating new ROAs for those resources.
If you are the recipient and do not yet participate in ARIN’s RPKI services, the transfer will not automatically register you. You must sign up for RPKI services through ARIN Online.
A successful 8.3 or 8.4 transfer depends on clear coordination between source and recipient organizations. Following these best practices ensures that routing remains accurate and that your resources remain reachable and secure after transfer completion.
Want to be the first to hear about tips and best practices? Subscribe to the ARIN Blog mailing list to ensure you never miss a post!
Recent blogs categorized under: Tips
GET THE LATEST!
Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.
SIGN ME UP →Blog Categories
Tips • RPKI • IRR • IPv6 • Public Policy • Caribbean • Outreach • Elections • ARIN Bits • Grant Program • Fellowship Program • Training • Security • Updates • Guest Post • Data Accuracy • Business Case for IPv6 • Internet Governance • IPv4 • Customer Feedback
