IPv4 Needs Justification: Evidence and Calculations
IPv4 needs justification connects a requested block to documented network use. A useful submission reconciles existing holdings, current utilization and dated demand. The applicable test depends on the receiving RIR and transfer route; there is no universal percentage or planning horizon.
Identify the applicable test first
| Case | Assessment to prepare |
|---|---|
| ARIN ordinary transfer | Initial /24 eligibility for an organization without an ARIN IPv4 allocation; larger or additional requests follow the applicable NRPM 8.5 route |
| APNIC ordinary transfer | Detailed 24-month use plan; existing holders also show previous utilization and policy compliance |
| RIPE ordinary intra-region transfer | No recipient needs assessment under the ordinary transfer policy |
| RIPE inbound from a needs-based region | Plan for at least 50% use within five years |
| LACNIC or AFRINIC recipient | Applicable initial/additional allocation or assignment justification; do not import ARIN’s thresholds |
Checked 8 November 2026. The RIR policy comparison links to the individual registry references and exceptions. An ARIN M&A request under section 8.2 follows a different route from an ordinary section 8.3 request.
Build a worksheet that reconciles
Export the existing inventory from IPAM. Separate resources held directly, provider-assigned or leased resources, and resources that will be returned or transferred away. Identify which holdings the receiving registry counts under the selected rule.
| Worksheet field | Evidence | Common failure |
|---|---|---|
| Existing prefixes | Prefix, holder, status and registry/account reference | Omitting a quiet or recently acquired block |
| Current use | Assigned subnets, service or customer counts, and snapshot date | Calling a BGP announcement full utilization |
| New deployment | Service, location, quantity and activation date | An undated sales forecast |
| Required addresses | Hosts or assignments plus explained subnet overhead | Equating every potential customer with a public address |
| Migration | Old and new space, overlap period and retirement dates | Counting both networks as permanent growth |
| Supporting material | Contracts, purchase orders, deployment approvals or network diagrams as relevant | Numbers that differ between the plan and evidence |
Use IPAM records for registry audits to preserve the inventory and supporting trail. Submit sensitive customer evidence through the registry’s requested channel, not in public WHOIS comments.
Calculate demand without double counting
For each deployment, calculate the public addresses required by the architecture, the portion already available, and the remaining demand within the policy horizon. Distinguish addresses from customer counts, VM counts and subnet counts.
Illustrative sizing check: an ARIN applicant requesting a /22 has 1,024 addresses in the requested block. Under the ordinary 50%-within-24-months route, the plan must support at least 512 of those addresses. This does not replace the separate test for existing holdings or any other eligibility condition.
Suppose documented services account for 600 addresses, but 180 can be supplied from existing free inventory. Net new demand is 420, so those facts alone do not support 512 addresses of new use. Document further qualifying demand, reduce the request, or use the applicable alternative policy route. Do not inflate demand to fit a preferred prefix.
The worked example leaves 420 addresses of net new demand against the illustrated 512-address threshold: an evidence gap of 92. The figures are hypothetical and use ARIN’s ordinary 50%-within-24-months route. Existing-holdings utilization and other eligibility conditions remain separate checks.
View full diagram
The subnet calculator checks prefix sizes and boundaries. It cannot decide whether a particular deployment satisfies registry policy.
Explain gaps before the reviewer asks
Describe why a sparse block cannot meet the new requirement: a separate site, customer commitments, a pending return or a necessary renumbering interval. Support the explanation with inventory and dates. “Reserved for growth” without a scheduled deployment does not make the calculation auditable.
Keep the worksheet, prefix list and request text on the same revision. If the deployment changes during assessment, update the case rather than leaving two incompatible plans with the registry.
For procurement of additional IPv4 capacity, complete this sizing work before committing to a block size. Commercial availability does not determine the receiving registry’s approval.