Best Practices for ARIN IPv4 8.3 & 8.4 Transfer Requests

If your organization is involved in an ARIN 8.3 transfer (Specified Transfer Recipient) or an 8.4 inter-RIR IPv4 transfer, it’s critical to manage the handoff correctly. A successful transfer isn’t just about paperwork — it also requires updating routing security and registry records so the IP space remains reachable, secure, and properly authorized after the transfer completes.

This guide outlines the key responsibilities for both the source organization (seller) and the recipient organization (buyer), specifically around:

• ROAs (Route Origin Authorizations)
• IRR (Internet Routing Registry) route objects
• Reverse DNS delegation

1) ROA (RPKI) Best Practices for the Source Organization

Before submitting an ARIN 8.3 or 8.4 transfer request, the source organization must carefully review all ROAs tied to the IPv4 prefixes being transferred. The goal is simple:

✅ Make sure no transferred prefixes remain covered by the source’s active ROAs.

Recommended steps:

• Before initiating the transfer: verify the IP block being transferred is not included in any active ROA.
• If the prefix is part of a multi-prefix ROA: edit that ROA and remove the prefix(es) being transferred.
• If the prefix is covered by a single-prefix ROA: it will typically be removed automatically once the transfer finalizes.

2) For recipient organizations, once the transfer is complete

Recommended steps:

• If you already use ARIN’s RPKI services, create new ROAs for the newly received resources.
• If you don’t yet use ARIN’s RPKI services, enroll in RPKI so you can generate ROAs for your IP space.
• Prepare for updated reverse DNS delegations after the transfer is finalized.

3) IRR Best Practices (Route / Route6 Objects)

In addition to RPKI settings, the source organization should review its IRR route objects before the transfer completes. This ensures the buyer can publish correct and authoritative routing information after the resources move to the new holder.

What to do:

• Pre-transfer: locate any route or route6 objects referencing the IPv4 space being transferred.
• If those objects won’t be valid after the ownership change, update or delete them.
• Post-transfer: the recipient organization should publish their own authoritative IRR entries for the transferred IP block.

4) Reverse DNS Best Practices (rDNS Delegation)

Reverse DNS often gets overlooked, but it can cause real operational problems if not updated properly.

If the source organization manages authoritative reverse DNS zones for the IPv4 space being transferred, both parties should coordinate delegation updates to ensure the reverse DNS points to the correct nameservers after the transfer completes.

Reverse DNS checklist:

• Before transfer: confirm the recipient (or their DNS provider) is prepared to accept the new reverse DNS delegation.
• After transfer: the recipient should validate that the reverse DNS is now delegated to the correct nameservers.

5) ARIN 8.3 / 8.4 Source Organization Pre-Transfer Checklist (Quick Reference)

If you’re the source organization in an ARIN transfer, use this checklist to prevent routing or registry issues:

• Remove transferred prefixes from source ROAs (or delete ROAs that no longer apply)
• Review maxLength values and adjust where needed
• Update or remove IRR route objects referencing transferred space
• Coordinate reverse DNS delegation updates with the recipient
• Confirm the recipient understands they must publish new ROAs and IRR objects after transfer completion

6) Important Note: What Happens in ARIN RPKI After a Transfer?

Once the transfer is completed, ARIN automatically updates certificates and resource coverage at the registry level:

• The source organization’s ARIN RPKI certificate is automatically re-rolled after the transfer completes.
• Any ROAs for remaining resources still held by the source will be retained and re-rolled.
• If the recipient already has ARIN RPKI enabled, their certificate automatically renews to include the new resources — but they must still create new ROAs for the transferred space.

One key point:

If the recipient does not currently use ARIN RPKI, they are not automatically enrolled when receiving transferred resources. They must enable RPKI services separately through ARIN Online.

Final Takeaway: Clean Transfers Prevent Downtime and Routing Confusion

ARIN 8.3 and 8.4 transfers require more than a registry transaction. The best results come from proactive coordination with an approved facilitator — especially around ROAs, IRR objects, and reverse DNS.

When both organizations follow these transfer best practices, the newly transferred IPv4 resources remain:

✅ routable
✅ reachable
✅ compliant
✅ secure