ARIN policy fix: New ISP definition for LIRs

ARIN proposal ARIN-prop-339, published 8 Jan 2025, closes a logical gap in NRPM Section 2.4 by finally defining the Internet Service Provider.

The logic is straightforward but long overdue. Current ambiguity forces an assumption: every Internet Service Provider is a Local Internet Registry, yet the manual never explicitly defined the former. Doug Camin's proposal fixes this by stripping the qualifier "primarily" from the LIR definition and creating a standalone category for organizations providing connectivity services. This shift aligns ARIN policy with operational reality: not every LIR functions as a public-facing ISP.

Under the revised NRPM text, the distinction between these entities becomes binary. The new ISP definition captures specific services like colocation and virtual private servers that previously lived in a gray area. We can now dissect the mechanics of IPv6 allocation criteria with precision, specifically how initial assignments apply uniformly to the combined LIR/ISP designation. With Section 6.5 retiring outdated terminology, organizations have a clear strategic framework to determine their correct registration path.

The Critical Distinction Between ISP and LIR Definitions in ARIN Policy

Defining ISP and LIR in ARIN NRPM Section 2.4

ARIN-prop-339 cuts through the noise by explicitly defining the Internet Service Provider alongside the Local Internet Registry. The proposal codifies a simple truth: "all ISPs are LIRs, but not all LIRs are ISPs." While implied, this hierarchy lacked textual backing in the Number Resource Policy Manual. Every provider serving end-users acts as a registry, but the reverse is not true. Not every registry operates as a public service provider.

The fix is surgical. The textual modification removes the qualifier "primarily" from the LIR definition to eliminate subjective interpretation.

• Original text required an LIR to be "primarily" an IR assigning addresses to network service users.

Applying Dual LIR/ISP Terminology in NRPM Section 6.5

Amending Section 6.5 to include "LIR/ISP" resolves eligibility conflicts for entities requesting static assignments. The proposal targets Section 6.5.5.4 of the NRPM, inserting the term 'LIR' alongside 'ISP' for registration requests involving static assignments. Previously, ambiguous language in Section 6.5.1a created interpretation gaps. LIRs without immediate downstream customers struggled to validate their status under standard ISP criteria.

The proposed text changes specifically target Section 6.5.7 to add the term "ISP," creating a consistent framework where both entity types operate under identical allocation constraints. This uniformity prevents confusion for LIRs that manage infrastructure for subordinate ISPs but lack direct end-user contracts.

ARIN ISP/LIR Definitions Versus Global RIR Standards

Global registries predominantly apply the Local Internet Registry designation to classify entities assigning address space. While ARIN has historically prioritized the term 'ISP,' the global standard among Regional Internet Registries (RIR) predominantly uses 'Local Internet Registry'. Unlike ARIN, where the term LIR is noted as "not used in the ARIN service region" for operational purposes, the APNIC region explicitly defines policies describing how LIRs assign resources to downstream subordinate ISPs.

AFRINIC defines an LIR as generally being an ISP, highlighting a structural terminology difference that ARIN's proposal seeks to bridge for improved global interoperability. Operators managing cross-border infrastructure currently navigate inconsistent terminology for identical functions. This misalignment creates unnecessary friction.

Nibble Boundary Rules for IPv6 Initial Allocation

All IPv6 allocations must align to strict nibble boundaries, enforcing a binary subdivision where prefix lengths are multiples of four. This technical constraint ensures that address blocks remain aggregatable and compatible with hierarchical routing tables. Under the revised Section 6.5.2, the minimum allocation size for an LIR/ISP is a /32, though entities may specifically request a /36 or /40 if they meet reduced holding criteria. Conversely, no initial allocation shall exceed a /16, capping the maximum upfront resource grant regardless of projected demand.

Operators must navigate these size limits while planning for future growth without renumbering.

• Allocations smaller than /32 require explicit justification and adherence to specific IPv4 holding thresholds.
• Expansions from /40 to /36 occur automatically if direct IPv4 allocations exceed a /24.
• Any growth beyond /32 triggers subsequent allocation reviews rather than automatic upgrades.

The rigidity of nibble alignment creates a specific dynamic: operators requesting minimal blocks face stricter eligibility gates than those taking the standard /32. This design prevents fragmentation but demands precise capacity planning from the outset. For networks managing complex downstream hierarchies, understanding these IPv6 deployment structures is vital to avoid disqualification.

The maximum allowable allocation relies on a strict formula where serving sites drive total block size. An end site justifying more than a /48 counts as the appropriate number of /48 equivalents, effectively inflating the denominator in sizing calculations. This mechanism prevents over-allocation by treating complex customer deployments as multiple standard units. Operators must aggregate these equivalents to determine the smallest nibble-boundary block that satisfies demand without exceeding the 75% utilization threshold required for future growth.

Organizations with subordinate LIR/ISPs must treat reallocated prefixes as fully utilized when sizing their own holdings. This approach ensures parent registries maintain sufficient aggregation levels while delegating authority downstream. However, entities lacking direct ARIN resources cannot make such reallocations, forcing subordinate providers needing more than a /32 to apply directly. This structural constraint creates a dependency where smaller providers must bypass intermediate hierarchies to secure necessary space. Precise calculation avoids the inefficiency of historical allocation discrepancies where entities received blocks smaller than current entitlements.

Strategic Decision Framework for LIR and ISP Registration Paths

Clarifying LIR and ISP Roles in Section 6.5 Amendments

Section 6.5.7 now explicitly permits LIRs with legacy allocations smaller than current entitlements to receive a new initial allocation. This amendment resolves eligibility ambiguity by formally recognizing that an Internet Service Provider operates as a specific subtype of Local Internet Registry. Community feedback indicated a desire for a more explicit approach to remove ambiguity. Operators must now distinguish between general registry functions and specific service provision to determine their correct classification path.

Procedural tension arises when an entity providing only connectivity qualifies for different resource pools than one offering colocation or virtual servers. The NRPM text defines the LIR role broadly while the new ISP definition narrows the operational scope for certain applicants. Specificity prevents organizations from claiming broader rights than their actual network footprint supports. The operational benefit is a cleaner registry database where address holdings match actual infrastructure deployment.

Applying IPv6 Allocation Limits for Community Networks

Section 6.5.9.2 explicitly caps community network allocations at a /40 of IPv6 resources. This strict limit accommodates organizations operating on tighter budgets while preventing resource hoarding. Entities exceeding this boundary must transition to regular LIR/ISP status under section 6.5.2.

Accepting a /40 creates a hard ceiling on immediate expansion without re-qualification. The constraint balances resource access against the administrative burden of proving commercial service delivery. Communities serving static assignments of /64 or larger must register these in the database, a process clarified by recent terminology updates. Preparation ensures a smooth transition when the /40 limit becomes a bottleneck. Policy design intentionally separates social infrastructure from commercial internet provision to preserve address space efficiency.

Decision Checklist for LIR versus ISP Registration Paths

Validate your operational model against specific service delivery criteria before submitting registration documents. Organizations providing connectivity or hosting to external customers must apply as an LIR/ISP rather than an end user, a distinction clarified by recent policy amendments to remove ambiguity.

Downstream recipients requiring database publication force the LIR/ISP to register static assignments of /64 or larger addresses. Community networks operating on limited budgets may qualify for smaller allocations but must transition to standard LIR/ISP status if their resource needs exceed the set caps. Confusion regarding classification can be resolved by contacting the Registration Services Help Desk for direct guidance on complex organizational structures.

Internal infrastructure requests represent a common self-assessment error; even registered ISP/LIR entities must apply under specific policies when requesting addresses for their own network backbone rather than customer distribution. Auditing customer contracts helps confirm whether an organization acts as a primary service provider or a downstream recipient before finalizing an application path. The distinction between a /2, /64, or larger block determines the entire registration trajectory.

Executing Compliant Allocation Requests and Reassignment Plans

Eligibility Thresholds for IPv4 and IPv6 Holdings

Eligibility for a /40 allocation requires an LIR/ISP to hold IPv4 direct space totaling a /24 or less alongside reassignments under a /22. This strict cap ensures initial IPv6 blocks align with actual infrastructure scale rather than speculative demand. Operators must validate these holdings before submitting requests to ensure they meet the specific criteria for the requested block size.

1. Confirm total IPv4 direct allocations do not exceed the /24 boundary.
2. Aggregate all reassignments to verify the sum remains below the /22 threshold.
3. Submit the request only after both conditions are met to qualify for the /40 size.

The critical tension lies in the automatic upgrade mechanism; exceeding the /24 IPv4 limit triggers an immediate upgrade to a /36, altering long-term planning assumptions. This rule prevents fragmentation but demands precise inventory management prior to application. Historical data suggests that operators failing to distinguish between direct holdings and downstream reassignments often miscalculate their entitlement tier.

Operators must demonstrate efficient use of existing space according to strict policy metrics before ARIN approves additional blocks. Section 6.5.5 is amended to add LIR in one location, requiring LIR/ISPs to demonstrate efficient use via documentation. This documentation process validates that the network uses existing space according to the set calculation methods.

1. Demonstrate that individual serving sites are sized appropriately to satisfy the needs of the largest single serving site.
2. Register every static assignment of /64 or larger if the downstream recipient requests publication in the database.

Failure to register these downstream assignments can complicate future justification efforts. The policy prevents organizations from bypassing ISP utilization requirements even when requesting space for internal infrastructure. Section 6.5.4.1 is amended to add ISP in one location, allowing an LIR/ISP to reassign up to a /48 per PoP and an additional /48 globally for infrastructure. A network might show strong overall usage while specific subnets remain underutilized, potentially affecting the sizing of future blocks. The tension exists between rapid deployment needs and the necessity of proving every address is active. Precise documentation transforms a potential rejection into a routine administrative approval.

Checklist for Expanding Allocations from /40 to /36

Section 6.5.2 mandates that all IPv6 allocations align strictly on nibble boundaries to maintain routing table efficiency. Operators expanding from a /40 must first verify their existing IPv4 holdings remain within the strict eligibility caps for smaller blocks. If direct allocations exceed a /24, the policy triggers an automatic upgrade to a /36 rather than permitting manual expansion requests. This mechanism prevents fragmentation by ensuring block sizes match the operator's demonstrated scale of operations.

1. Confirm current IPv4 reassignments total a /22 or less to retain /40 eligibility status.
2. Validate that the requested expansion size adheres to nibble alignment rules without requiring renumbering.
3. Ensure downstream recipients of static /64 assignments are registered if they request database publication.

The following table contrasts the operational constraints between holding sizes:

A critical tension exists where an operator might technically qualify for a larger block but lacks the immediate infrastructure to apply it efficiently. Unlike subsequent allocations requiring utilization proofs, this specific expansion relies entirely on the IPv4 asset threshold rather than current IPv6 burn rates. InterLIR advises monitoring your IPv4 portfolio closely, as crossing the /24 boundary forces the IPv6 block size change regardless of immediate subnetting plans. This rigid linkage ensures that IPv6 distribution capacity never vastly outpaces the operator's core network footprint.