ARIN IPv4 Transfers: Eligibility and Timing Rules

ARIN IPv4 transfers require a clear transfer type, eligible parties and a plan for the technical handover. Teams using dedicated servers, VPS fleets, load balancers or mail gateways should separate a provider assigning an IP to a service from an organization receiving registered resources through ARIN. This guide explains the relevant rules and what network teams should consider when planning their IP strategy. It covers recipient needs, source eligibility, M&A documentation, inter-RIR coordination, budgeting and IPv6 readiness without assuming that every policy change raises prices.

Quick refresher: How ARIN IPv4 transfers actually work

ARIN and the regional IPv4 market, in plain language

ARIN serves the United States, Canada and parts of the Caribbean and North Atlantic. Its general IPv4 free pool depleted in September 2015. Eligible organizations can still consider transfers, the waiting list for returned space and reserved pools with their own purposes and conditions. Depletion does not mean no address can be obtained.

In practice this means:

• The source must meet the applicable rights-holder, dispute and timing conditions.
• The recipient must satisfy the requirements of the selected transfer type; membership alone is not the eligibility test.
• Specified transfers to ARIN recipients use section 8.5; resources in an 8.2 M&A transfer are not subject to a needs-based assessment during that transfer.

ARIN’s Number Resource Policy Manual (NRPM) defines several transfer types, including:

• M&A, section 8.2: A merger, acquisition or reorganization involving the assets using the resources, or the entire registered entity.
• Specified recipients within ARIN, section 8.3: Transfer between a qualified source and recipient in the ARIN region.
• Inter-RIR, section 8.4: Transfer between registries that agree to it and share reciprocal, compatible needs-based policies.

Publication and review dates: This article was first published on 25 December 2025, when NRPM 2025.1 was in force. ARIN-2025-2 was adopted on 15 December 2025 and implemented on 3 March 2026. It removed “within the last two versions” from section 8.5.1, leaving the determination of a current RSA to ARIN business practices. This review, dated 4 November 2026, uses NRPM 2026.1 and the change log. The amendment did not introduce the 24-month needs criterion or establish a general new tightening of all transfer rules.

What to look for in policy and registry records

Three useful themes for evaluating IPv4 transfer policy are:

• Fairness: Directing addresses toward demonstrated operational need rather than speculative accumulation.
• Conservation: Stretching remaining IPv4 space so that genuine growth projects can still function while IPv6 ramps up.
• Data quality: Keeping organization, resource and contact registration data accurate; Whois/RDAP does not independently establish where traffic originates or every private contract behind a block.

The dated Whois change, ARIN-2024-2, was implemented on 4 March 2025. It clarified and codified existing organization/contact data collection and disclosure practices. It should not be read as a new transfer completion deadline or a system verifying physical IP location. Use Whois/RDAP for registration checks and separate tools for routing, reachability and reputation.

ARIN IPv4 transfer policy areas to review

1. Proof of “need” for recipients

Section 8.5 applies to 8.3 recipients and specified 8.4 recipients inside ARIN. It provides resources solely for use on an operational network. Under 8.5.1, the receiving entity signs an RSA covering the transferred resources unless it already has a current RSA on file per ARIN business practices. Read the block-size paths separately:

• Initial minimum block: The minimum IPv4 transfer is /24. Organizations without an IPv4 allocation from ARIN qualify for an initial allocation of that minimum transfer size under 8.5.4; other requirements still apply.
• Larger initial or additional block: Section 8.5.5 requires documentation showing use of at least 50% of the requested block size within 24 months.
• Existing utilization: Organizations with an ARIN IPv4 allocation must have efficiently used at least 50% of their cumulative IPv4 blocks to receive more addresses under 8.5.6; customer reallocations/reassignments count.
• Other paths: Renumbering provisions in 8.5.5.1/8.5.6.1 and the alternative additional-block criteria in 8.5.7 have their own conditions. Do not apply one percentage to every case.

Finding a seller does not establish recipient eligibility. A 12–24 month operating forecast can support planning, but the specific 8.5.5 test is 50% use within 24 months. Diagrams and dashboards are preparation tools, not a universal checklist of mandatory exhibits. A useful preparation tool is an internal utilization dashboard for each allocation and subnet, which can help produce reports for a transfer request.

2. Transfer eligibility and timing restrictions

The 12-month rules in 8.3 and 8.4 concern the source organization’s receipt history. They are not a general instruction that every transferred block must be held for several years:

• 8.3 source: Except for 8.2 M&A transfers, the source must not have received a transfer, allocation or assignment from ARIN in the past 12 months. ARIN may waive this requirement for qualifying 8.5.5.1 renumbering.
• 8.4 ARIN source: No IPv4 transfer, allocation or assignment from ARIN in the 12 months before approval, subject to the ownership/control and common-ownership/control exceptions in 8.4. The restriction does not include 8.2 transfers.
• Waitlist restrictions: Under 4.1.8, addresses distributed from the waitlist cannot be transferred for 60 months, except through 8.2. The waitlist maximum is /22; organizations holding more than /20 in aggregate, excluding 4.4/4.10 space, cannot apply.
• After a transfer: An 8.3/8.4 source cannot apply to the waitlist for 36 months after transferring IPv4. An applicable ARIN recipient is removed and cannot reapply for 90 days. An 8.2 source has a separate 36-month restriction with a parent/subsidiary/common-ownership exception. Section 8.6 removes a waitlisted organization that applies to be a transfer source under section 8.
• Reserved pools: Address resources from reserved pools, including sections 4.4 and 4.10, are not eligible for 8.3 or 8.4 transfers.

For hosting providers, ISPs and enterprises, transfer eligibility and timing belong in capacity planning. Do not assume that space acquired as a short‑term stopgap can be resold on your preferred schedule. A multi‑year operational and financial plan can help size a purchase; that planning horizon is not itself an ARIN holding‑period requirement.

3. Documentation for mergers and acquisitions

Buying assets or a company does not by itself update the ARIN registration. ARIN’s 8.2 process requires evidence linking the recipient to the assets using the resources or to the entire registered entity. These conditions already appeared in the 2025 policy:

• Legal continuity: Supply appropriate authenticated evidence, such as asset-purchase documents, a finalized merger instrument, court order or relevant public filings. If several transactions connect the entities, document each link.
• Registration: The current registrant must not be in a dispute over the resources; the new entity signs an RSA and the resources remain subject to ARIN policies. A legal name change without M&A/reorganization has a separate name-change request path.
• Needs assessment: The resources in an 8.2 transfer are not subject to needs-based assessment during that transfer. Operational planning is useful, but do not turn 8.5’s utilization test into an 8.2 approval condition.

If you are acquiring a smaller hosting brand or a portfolio of colocation customers, you should factor ARIN policy compliance directly into the due‑diligence checklist, not as an afterthought.

4. Coordinating inter‑RIR transfers

Inter-RIR transfers require agreement and reciprocal, compatible needs-based policies between the registries. Check current compatibility before contracting; do not infer eligibility from the existence of offices or an ASN in another region.

The direction of the transfer determines the relevant party’s requirements:

• Source outside ARIN: Meets the requirements of the registry where the resource is registered.
• Recipient outside ARIN: Meets conditions defined by the receiving RIR.
• Recipient inside ARIN: Meets section 8.5 and current ARIN policies. The ARIN source’s conditions and exceptions are checked separately.

If your organization operates multi‑region networks or has customers across continents, plan each inter‑RIR transfer as a project, with timelines, legal review and a clear business case.

Planning implications for hosting and SaaS teams

1. Capacity planning needs to get more precise

Concrete utilization data and growth assumptions make capacity plans more useful than rough estimates alone. For a hosting or SaaS environment, you should be able to answer:

• How many IPv4 addresses do you use today, by service type (shared hosting, VPS, dedicated, load balancers, mail, VPN, infrastructure)?
• What is your expected growth in customers, containers, or endpoints over the next 12–24 months?
• How much of that growth can realistically be absorbed by IPv6, NAT or shared addressing rather than one‑IP‑per‑resource?

For broader planning context, see the IPv4 exhaustion and hosting address-planning guide. Keep utilization evidence and growth assumptions together before committing to new capacity.

2. Manage IPv4 as a strategic resource

IPv4 acquisition costs and transfer constraints belong in long‑term infrastructure planning. Treat address space as a strategic resource that needs lifecycle management:

• Acquisition: Size a purchase against an operating and financial plan; apply the actual transfer-type criteria separately.
• Utilization: Review idle or oversized assignments for avoidable costs, while retaining capacity justified by real operational requirements.
• Reclamation: Check DNS, customer, firewall and monitoring dependencies before releasing addresses, then reassign them through a controlled process.

Assign an owner to each pool, track fragmentation and review whether subnets are still sized appropriately. Distinguish assigned, actively used, reserved and genuinely reusable addresses. An inventory helps planning but does not automatically establish that a particular transfer meets policy.

3. Contracts and SLAs may need updated language

Review contracts for assumptions that may conflict with resource registration or transfer conditions:

• Customer contracts promising “ownership” of IP addresses without clearly describing the customer’s use rights and the registry’s transfer process.
• Vague clauses about “transferring IPs to the customer” at the end of a term, with no reference to ARIN transfer policies.
• Assumptions that any unused IPs can simply be sold on the market at short notice.

State whether the customer receives a service IP assignment or a registered resource transfer, who submits the request, and what happens if approval is delayed or refused. Check source timing restrictions and applicable recipient needs criteria before promising a transfer date. A contract between two parties cannot by itself complete the registry process.

4. Engineering teams must be ARIN‑aware, not just management

Include engineering alongside legal and finance. Network and DevOps teams need to understand how address plans, application dependencies and transfer conditions interact:

• Why IPv4 is scarce and why some blocks cost more to obtain.
• How IPv6 adoption can cut long‑term dependency on transfers.
• When using dedicated IPv4 per customer or per container is unsustainable.

For the performance, security and cost questions around a protocol change, see the IPv6 migration planning guide. Use service-specific tests when setting a rollout timeline.

Practical steps for an ARIN IPv4 transfer plan

Step 1: Centralize your IP inventory and utilization data

You cannot justify what you cannot see. Before even thinking of a new transfer, make sure you have:

• A single source of truth for all your IPv4 (and IPv6) allocations: prefixes, sizes, roles and status.
• Utilization metrics per subnet: assigned vs free addresses, customer density, per‑service counts.
• Clear tagging of hosting product or service role for each range (shared hosting, VPS, dedicated, infrastructure, internal tools, etc.).

Combine IPAM and monitoring where useful, while keeping address utilization separate from CPU, RAM, disk and traffic rates. Record the date, scope and owner of each input. A dashboard should trace back to the underlying assignments and usage records, rather than substitute for them.

Step 2: Build a conservative 12–24 month IPv4 forecast

ARIN’s needs‑based approach is not about perfection; it is about reasonable, documented assumptions. A simple but effective forecasting model can be built around:

• Historical growth: Customers or workloads added per month, averaged over the last 6–12 months.
• Per‑unit IP footprint: Typical IPv4 use per VPS, per dedicated server, per high‑availability cluster, etc.
• Efficiency gains: Expected savings from IPv6 rollout, NAT improvements, or consolidating under‑used blocks.

By combining these, you can estimate how large a transfer you truly need – and prove that estimate if ARIN asks. In our previous article on ARIN IP allocation changes and their impact on hosting and networks, we examine address-acquisition and planning options. IPv6 only reduces a projected public IPv4 requirement where a design actually avoids or releases those addresses.

Step 3: Test IPv6 in new designs

IPv6 can reduce dependencies in suitable designs, but traffic moving to IPv6 does not automatically free public IPv4. A dual-stack endpoint still uses both families, and replacing private internal IPv4 does not itself reduce purchased public addresses. Prioritize specific dependency changes:

• For VPS and dedicated server builds, confirm product/location support and retain needed IPv4 access while testing IPv6.
• Verify routing, listeners, TLS, firewall, proxy/WAF coverage and external reachability before publishing AAAA. For setup context, see our IPv6 setup and configuration guide for VPS servers.
• Update documentation, runbooks and monitoring to always include IPv6 addresses, not just IPv4.

Measure the public IPv4 addresses actually avoided or released, alongside the cost of operating both protocols. Keep compatibility for required clients, APIs and email peers. Neither IPv6 traffic share nor a successful pilot guarantees transfer eligibility or a lower hosting bill.

Step 4: Clean up legacy assignments and reduce fragmentation

Inspect legacy assignments for reclaimable capacity, without assuming that apparently quiet addresses are unused:

• Old testing or staging ranges that still reserve public IPv4 instead of using RFC1918 or IPv6.
• Customers long gone whose IP assignments remain in ACLs, firewall rules or DNS zones.
• Overly generous per‑customer allocations from earlier years (for example, a /29 where a single IP would be enough today).

Before reclaiming an address, confirm ownership and DNS, routing, firewall, monitoring and customer dependencies. Released space can reduce the need for a new block, but document the actual result; a cleanup exercise does not itself guarantee ARIN approval.

Step 5: Treat each ARIN transfer as a mini‑project

Manage the transfer as a project with separate registry and technical acceptance criteria. Obtain case-specific timing information; the full approval process has no universal duration implied by this guide.

• Stakeholders: Involve network engineering, legal, finance and – if needed – external counsel early.
• Timeline: Track document preparation, source/recipient requests, review, fees and any applicable RSA separately. Agree a technical cutover only after its prerequisites are met.
• Documentation pack: Prepare utilization data, growth forecasts, org paperwork and any M&A documents upfront. For an 8.3 transfer, the source organization must provide a signed and notarized Officer Acknowledgement Letter.
• Post‑transfer plan: Coordinate source ROA edits/removal, recipient ROAs, IPv4 IRR route records, reverse-DNS delegation, monitoring and customer allocations. Match prefix, origin ASN and maxLength to intended BGP announcements, test external reachability, and retain a rollback plan.

The ARIN transfer operations guide for network and DevOps teams provides related operational context for this policy overview.

Discussing IP requirements with a hosting provider

1. Aligning product design with IP scarcity

For a new hosting, VPS, dedicated or colocation project, confirm the service’s actual IP options and responsibilities:

• Shared IPv4: Use it where the protocol and isolation requirements allow. Modern TLS SNI supports multiple hostnames on one IP; HTTPS alone is not a reason every site needs a dedicated IPv4. Legacy clients or other protocol requirements can differ.
• IPv6 support: Confirm the exact product and location, allocation, routing, PTR, recovery access and protection coverage.
• Internal services: Test management, backup and monitoring dependencies before changing their address family. Keep restricted access controls; an internal IPv6 migration does not automatically free public IPv4.

Record both one-time and recurring charges, including additional IPv4, registry processing, technical migration and ongoing operations. Use dated offers with clear inclusions; ARIN policy does not set the secondary-market price or guarantee predictable customer costs.

2. Strengthening IPAM, monitoring and reporting

A useful inventory and reporting design can include:

• IPAM integration: Keep allocation, utilization, service tags and ownership current.
• Controlled reclamation: Verify decommissioning and stale dependencies before marking an address reusable.
• Product visibility: Distinguish public IPv4 required by web, email, VPN, load-balancer and other roles; customer or traffic totals alone are not address-use measurements.

Ask who can provide these records and who is responsible for registry changes. If a customer brings resources to dedicated or colocation infrastructure, define its authorization, routing and reverse-DNS responsibilities separately from the hosting contract.

3. Helping customers move more workloads to IPv6

Use a representative IPv6 pilot with acceptance checks:

• Prepare routing, listeners, TLS, firewall and per-family monitoring before publishing dual-stack DNS with A and AAAA records.
• Verify IPv6 support in the actual network and protection services; product availability is not proof that your application is correctly configured.
• Use the IPv6 adoption guide as planning context, then test application flows and rollback on your deployment.

Treat mail separately: verify sending-IP authorization, PTR and forward DNS, SMTP identity and the recipient’s support. Web IPv6 does not require immediate SMTP migration. Routing records and correct email authentication do not guarantee inbox placement or reputation.

Make the transfer decision from the right evidence

Start with the transfer category and the roles of each organization. Apply 8.5 to the specified recipients it covers; preserve the 8.2 needs-assessment exclusion. Separate source receipt-history rules from waitlist restrictions, and distinguish the 2025 adoption of ARIN-2025-2 from its March 2026 implementation. Check current policy and process guidance again when applying.

For a DCHost project, bring a dated address inventory, growth assumptions, required IPv4 dependencies and an IPv6 pilot plan to the service discussion. Confirm product support and responsibilities in the offer. Size any transfer from the actual application and policy requirements; assess costs from real quotes and technical acceptance from testing.