ARIN IPv6 Eligibility: Why /24 Is the New Minimum

A /24 is the minimum IPv6 block for end-users with two distinct external ASNs, proving ARIN policies enforce strict technical justification.

Casual users need not apply. The process demands applicants be active business entities legally formed within the service region or possess a substantial connection to it. Success depends on navigating the Number Resource Policy Manual rather than guessing at requirements.

This guide dissects resource eligibility, explaining why ARIN halted general IPv4 allocations to focus strictly on IPv6 addresses for new requests. We then execute the ARIN Online workflow, ensuring your Organization Identifier and Point of Contact records satisfy the rigorous documentation standards required for approval.

Core Concepts of ARIN Resource Eligibility and Definitions

Defining ARIN Service Region and Eligible Entities

The ARIN service region encompasses the United States, Canada, and specific Caribbean and North Atlantic islands, establishing the strict geographic boundary for direct resource eligibility. ARIN serves as the registry for this territory, distinguishing its operational scope from other Regional Internet Registries like RIPE NCC or APNIC. Entities seeking address space must be active business units legally formed within these borders to qualify for direct allocation.

Eligible applicants include businesses, nonprofit corporations, or government entities that maintain a valid legal presence. Individuals also qualify if they meet the specific legal requirements of their local jurisdiction. This structure ensures that all Organization Identifiers correspond to verifiable legal persons accountable for resource stewardship. Organizations acquiring assets from others may trigger specific transfer requirements involving distinct fee structures.

Infrastructure location introduces a critical nuance. Registered resources may function outside the geographic zone provided the organization maintains a real and substantial connection with the region. NRPM Section 9 governs this out-of-region usage, preventing policy arbitrage while accommodating global network topologies. Organizations must maintain this substantive link to apply resources outside the service region. Applicants should verify their corporate registration documents match their requested Org ID details before submission.

Applying ASN Policies for Single and Multiple Discrete Networks

An Autonomous System constitutes a distinct group of IP prefixes managed under a single, clearly defined routing policy. Organizations requesting resources must distinguish between standard single-network operations and complex topologies requiring multiple identifiers. Any organization may request a single Autonomous System Number upon establishing basic eligibility without proving unique policy requirements beyond standard operational need.

Requests diverge when an entity manages multiple discrete networks, such as separate data centers or distinct business units. ARIN policy permits issuing one ASN per discrete network, but only if the applicant demonstrates a technical necessity for unique routing policies.

ARIN strictly separates ISP allocations intended for customer reassignment from end-user assignments reserved for internal network operations. This distinction defines the operational ceiling for organizations seeking direct registry resources versus those relying on upstream providers. ARIN allocates blocks of IP addresses to Local Internet Registries (LIRs), which are generally Internet Service Providers (ISPs), for the purpose of reassigning. End-users obtain space solely for their own infrastructure without rights to further distribution.

The divergence becomes critical when an organization connects to multiple external networks. Policy mandates that an end-user with two or more distinct ASNs not owned or controlled by them must request a minimum /24 block. Entities requiring smaller address space must obtain it from their upstream providers rather than the registry directly. This constraint forces a strategic choice between direct registry engagement and wholesale provider dependency.

While ISPs must demonstrate a plan for 50% projected assignments within five years, end-users face stricter immediate utilization hurdles. The market reality is that IPv4 exhaustion limits new direct requests, pushing many entities toward the transfer market or IPv6-only deployments. This metric calculates the ratio of assigned addresses to the total available block, ensuring that operators fully exploit their current inventory before expanding their footprint. The policy allows alternative qualification paths, such as demonstrating 90% utilization at a single serving site or proving that over 90% of total space is allocated to justified sites. These criteria prevent hoarding and enforce efficient distribution across the regional registry. High utilization without a corresponding increase in customer count signals inefficient subnet sizing rather than genuine growth. Networks should audit their subnet masks and assignment patterns before filing, as raw percentage usage alone does not guarantee approval if the underlying architecture wastes address space.

Applying the /20 Reserved Block Rule for Small Prefixes

Technical assignments of prefixes smaller than /20 are drawn from a specifically reserved block to ensure efficient aggregation and routing table management. This mechanism isolates fragmented address space, preventing the pollution of the global routing table with hyper-specific routes that degrade performance. When an organization submits a request, the registry validates whether the desired prefix size falls below this aggregation threshold before sourcing it from the dedicated reserve.

Operators must recognize a critical constraint: end-users requiring space smaller than a /24 must obtain assignments from their upstream providers rather than requesting them directly from the registry. This policy enforces a strict hierarchy where Local Internet Registries absorb the complexity of small-block distribution.

Requesting a block larger than necessary creates administrative overhead without providing routing use. Most enterprises falsely assume they need direct registry resources when their actual requirement is simply connectivity. It is advisable to validate your upstream provider's capacity to delegate the required IPv6 space before initiating a complex registry application. Optimizing within the existing hierarchy often yields quicker deployment than fighting for direct allocation status.

Commercial Use Risks in Experimental IPv6 Allocations

This enforcement mechanism targets the specific risk of organizations treating temporary leases as permanent infrastructure for revenue-generating services. Experimental Allocations are granted annually, on a lease/license basis, for a period of one year. Operators must align their allocation sizes with minimum standards unless a smaller block is thoroughly justified for the specific experiment. The distinction between experimental allocations and standard assignments creates a binary compliance state where any deviation triggers reclamation.

A common failure mode involves organizations expanding service offerings without updating their experimental justification, inadvertently violating the lease terms. Maintaining strict segmentation between testbed traffic and production customer data helps avoid crossing this regulatory line. Organizations planning to scale beyond the original test parameters must transition to a standard allocation before engaging in commercial activity. Upon completion of any experimental activity, all allocated resources are returned to ARIN's free pool.

Executing the ARIN Application Workflow for IP and ASN Resources

ARIN Online Account and Org ID Prerequisites

Successful resource acquisition mandates an ARIN Online account linked to an authorized Admin or Tech Point of Contact (POC) record before submission. This structural requirement ensures that only verified entities with a valid Organization Identifier (Org ID) can initiate requests for IP Addresses or ASNs. The architecture relies on specific roles where the Organizational Tech POC holds exclusive authority to update Org details and manage reverse delegations. Without this precise linkage, the system blocks all application workflows regardless of technical justification.

Operators must execute the following sequence to establish valid credentials:

1. Log in to ARIN Online using established corporate credentials.
2. Verify that your user profile connects to an active Tech POC role within the database.
3. Confirm the target Org ID reflects current legal entity status in the service region.

A common failure mode occurs when individuals attempt requests using personal accounts unlinked to the corporate Org ID, causing immediate administrative rejection. Role-based access control prevents unauthorized modifications to critical routing assets. The Routing POC designation further integrates RPKI certification requirements directly into the maintenance lifecycle. Organizations ignoring these prerequisite configurations face indefinite processing delays.

Initiating a resource acquisition requires logging into ARIN Online, selecting IP Addresses or ASNs from the navigation menu, and clicking Request. This specific entry point triggers the workflow where operators must provide detailed network information to justify the allocation size. Unlike regions relying solely on upstream providers, this system allows direct requests for entities meeting strict policy requirements direct requests.

1. Submit the initial application with thorough technical justification and business plan details.
2. Await review by an ARIN Customer Service Resource Analyst, a process typically concluding within two business days.
3. Finalize the transaction by paying applicable fees and signing the Registration Services Agreement (RSA).

Operators often underestimate the precision required in the initial justification phase, as vague technical descriptions frequently trigger iterative information requests that delay approval. Immediate procedural friction prevents long-term routing instability caused by unjustified allocations. Once the analyst approves the request and the organization submits the signed RSA, resources issue within two business days. Delays in executing the legal agreement reset the validation clock, effectively nullifying the prior technical review.

Documentation and 60-Day Agreement Execution Checklist

Finalizing resource acquisition demands immediate submission of the Registration Services Agreement (RSA) and fee payment within a strict 60-day window to prevent request expiration. Operators must prepare detailed contact records and network diagrams that satisfy business plan details requirements for utilization efficiency. Failure to execute this contractual obligation results in the automatic voiding of the approved application, forcing a complete restart of the vetting process.

The following sequence ensures compliant execution:

1. Receive analyst approval notification via ARIN Online.
2. Submit the signed RSA and remit applicable fees.
3. Await resource issuance, which occurs within two business days of receipt.

Operational readiness often clashes with administrative urgency. Delaying signature to finalize internal networking gear often accidentally breaches the compliance deadline.

Defining Insufficient Justification and Documentation Requirements

Insufficient justification occurs when an applicant fails to demonstrate why upstream provider addresses cannot satisfy current network requirements. ARIN mandates a reasonable technical justification indicating why addresses from an ISP or other LIR are unsuitable before approving direct requests. This rigorous standard separates administrative oversights from fundamental policy violations that halt processing.

Operators often confuse simple capacity needs with the strict multi-homing or discrete routing policy proofs required for ASN issuance. The distinction matters because administrative errors allow for corrected resubmission, whereas failure to meet policy requirements results in request denial. IP addresses or ASNs face revocation primarily for nonpayment or failure to maintain accurate registration data. Unlike standard delays caused by missing documentation, failure to sign a Registration Services Agreement (RSA) or pay associated fees prevents the completion of resource transfers or new requests. This enforcement state means that while a missing business plan yields a request for more information, falsified utilization data voids the application entirely. This hold period allows time for the resource to clear any route filters and for an organization to pay overdue fees.

Hidden costs of inadequate justification include:

• Delays in acquiring necessary resources due to the need for resubmission.
• Immediate halt to processing until specific policy requirements are met.
• Potential financial obligations related to fees outlined in the ARIN Fee Schedule.
• Extended engineering hours spent revising technical narratives.
• Loss of market timing during the re-evaluation window.

Lax documentation does not merely delay approval; it triggers a requirement to provide additional technical justification or business plans.

Executing the Appeals Process for Denied Requests

The appeals activate when an organization believes community-established policies were not adhered to during the initial evaluation. This mechanism serves as a procedural remedy for disputing a denied resource request based on policy misinterpretation rather than missing data. Operators must distinguish between a simple request for more information and an actual policy violation before filing. Misidentifying a documentation gap as a policy error may result in the appeal not addressing the root cause of the denial. Unlike standard inquiries, this process demands a precise citation of the specific policy clause allegedly mishandled by the review team.

Hidden operational costs often emerge during this phase, including extended timelines and diverted engineering hours:

• Delays in network deployment schedules while the appeal or review remains under consideration.
• Resource allocation for senior technical staff to draft the policy argument.
• Potential strain on the relationship with the registry if the submission lacks merit.
• Accumulation of legacy system dependencies while awaiting resolution.

Stakeholders seeking clarity on the status of transfer requests or appeals should contact Registration Services directly at +1.703.227.0660. This direct line provides verified updates that online dashboards may not reflect in real-time. The limitation of this channel is its inability to overturn technical findings without new, policy-grounded evidence. Successful navigation requires shifting focus from operational urgency to strict policy adherence. Precision in defining the procedural error is the only variable that influences the outcome.

Considerations for Resource Transfers and Policy Timelines

Policies regarding minimum block sizes, such as the /24 minimum for end-users with distinct ASNs, represent standing enforcement metrics that dictate current allocation sizes. Recipients within the ARIN region requesting IPv4 addresses via transfer must demonstrate a need for up to a 24-month supply of addresses. Operators attempting to fix a rejected ARIN request by waiting for specific returned space often miscalculate these requirements, creating critical path delays in network expansion plans. The necessity of demonstrating long-term need means that even qualified applicants face strict scrutiny regarding their projected utilization.

Hidden operational costs emerge during this evaluation window, complicating capacity planning for time-sensitive deployments:

• Stalled hardware procurement due to missing IP inventory approvals.
• Misaligned engineering schedules waiting for address space validation.
• Potential revenue loss from delayed service activation due to policy compliance timelines.
• Increased overhead from maintaining parallel legacy infrastructure.
• Opportunity costs associated with postponed product launches.

A significant tension exists between the safety mechanism of policy enforcement and the urgent demand for IPv4 liquidity. While the requirement to demonstrate a 24-month supply protects against resource hoarding, it simultaneously restricts the speed of asset acquisition. Applicants suffering from insufficient justification errors cannot simply wait for a specific block to cycle back; they must often pivot to alternative acquisition strategies or refine their technical justification. InterLIR recommends verifying all technical documentation before submission to avoid triggering these delays unnecessarily. Strategic planning must account for these administrative requirements rather than assuming instant resource recycling.