Summary

  • ARIN’s public request guide describes a multi-stage path: initial processing, possible staff review and additional information, approval, up to 60 days for applicable fees and a signed Registration Services Agreement, then issuance.
  • Its 2025 Annual Report lists 1,339 IPv6 requests and regional allocation display values that sum to 1,032. The comparable 2024 figures are 1,304 and 955.
  • The differences—307 in 2025 and 349 in 2024—are arithmetic, not observed counts of rejections, approvals, withdrawals, pending cases or any other outcome.
  • A privacy-safe cohort table could connect request year, processing path, coarse final state, decision year, agreement completion and issuance year without disclosing member tickets or private commercial information.

A request has more than one clock

The first clock starts when an organisation submits a request for Internet number resources. ARIN says an analyst will typically review a request within two business days and either approve it or ask for more information. That statement describes service cadence, not a guarantee that every case closes in two days. An information request can open another interval in which the applicant and registry are still resolving what the record needs.

The path is not uniform. ARIN’s help-desk guidance says many requests are processed automatically and do not receive a ticket. Requests requiring staff review do receive one, and an applicant can add information to a pending ticket. A count of requests is therefore not necessarily a count of tickets. Nor can a ticket be assumed to represent a single final allocation.

Approval starts another clock. Once the requirements have been met, ARIN says the applicant has 60 days to pay applicable fees and submit a signed Registration Services Agreement. ARIN then says resources are issued within two business days after it receives both. A request approved near the end of December can therefore produce an issuance in a later calendar year without anything being late, rejected or anomalous. The annual boundary belongs to the reporting calendar; it is not a wall inside the operational process.

That sequencing matters before any annual totals are compared. Submission year, analyst-action year, approval year, agreement-completion year and issuance year can be different fields. A public table that supplies only the first and last aggregates leaves the middle states unjoined.

What the annual reports actually show

Page 7 of ARIN’s 2025 Annual Report lists 1,339 IPv6 requests: 1,065 ISP requests and 274 end-user requests. On the same page, the regional IPv6 allocation display gives 941 for the United States, 64 for Canada, 11 for the Caribbean and 16 for Other. Those four displayed values sum to 1,032.

The 2024 Annual Report uses the same neighbourhood of the report. It lists 1,304 IPv6 requests—940 ISP and 364 end-user—and regional allocation values of 857 for the United States, 77 for Canada and 21 for the Caribbean. Those displayed values sum to 955.

Subtracting the displayed allocation total from the request total yields 307 for 2025 and 349 for 2024. That calculation is reproducible. Its interpretation as an outcome measure is not.

The reports do not say that the requests counted in either year are the same cohort as the allocations displayed for that year. They do not say that one request always produces one allocation row, one delegation, one ticket or one /32 equivalent. They do not assign either arithmetic difference to denied, withdrawn, duplicate, expired, incomplete, pending or approved cases. They also do not say whether corrections or multiple resulting records affect the relationship. The numbers may be adjacent on a page, but adjacency is not a database join.

This is why the phrase “conversion rate” would be too strong. A denominator needs a defined cohort, and a numerator needs a stated outcome from that cohort. Without both, division merely manufactures precision around unmatched populations.

Three public surfaces, three different units

ARIN’s statistics landing page points readers to current and historical resource data. Its historical statistics page publishes separate series for IPv6 requested and issued, along with a series expressed as /32-equivalent delegations. These are valuable longitudinal views. The accompanying public text does not provide an aggregate request-level key linking a submission cohort to its processing path, final state and eventual issuance year.

The unit distinctions are not pedantry. “Request” can describe an intake record. “Ticket” describes a support or review container when one exists. “Allocation” and “delegation” describe registry outputs, while a /32 equivalent is a normalised measure of address-space quantity. A single request might conceivably interact with these units in ways the aggregate series does not expose. The safe conclusion is not that any particular multiplicity exists; it is that the public material reviewed does not define a one-to-one rule.

There is also a tempting but invalid shortcut elsewhere in ARIN’s statistics. A transfer chart defines “Processed” for transfer tickets as closed regardless of status. That definition belongs to that transfer chart. Importing it into the IPv6 request series would silently change the subject, workflow and unit. Labels travel badly when their data dictionaries do not travel with them.

The missing join is the finding

The absence of a public cohort join does not make ARIN’s annual figures wrong. The request count can accurately describe intake, the allocation display can accurately describe output, and the historical series can accurately describe its own selected unit. The limitation appears only when an outside reader tries to answer a question the published aggregates were not designed to answer: What happened, in aggregate, to the requests submitted in a particular period?

A defensible answer would require more than another total. It would require a cohort definition and a state transition table. At minimum, the table would name the request year; ISP or end-user class; automated or staff-reviewed path; final state with a coarse, non-identifying reason class; decision year; applicable fee and RSA completion state; issuance year; rules for multiple outputs and later corrections; and an exact “as of” date.

Such a matrix could be privacy-safe. Counts can be aggregated; rare cells can be suppressed or combined; reasons can be broad; no applicant, contact, ticket text, invoice, fee amount or agreement need be exposed. The purpose would not be to audit individual members. It would be to make the public annual story coherent across the clocks ARIN already describes.

This is an editorial proposal, not an existing ARIN obligation or announced feature. It also would not measure deployment. Issued address space does not prove routing, Route Origin Authorisation coverage, customer use, traffic or IPv6 adoption. A cohort join would improve process evidence, not turn registration into an operating map.

What can and cannot be inferred

The public evidence supports five bounded observations. ARIN publishes annual request totals. It publishes annual regional allocation display values. It describes automated and staff-reviewed processing paths. It describes a post-approval window for fees and an RSA, followed by issuance. It publishes historical request, issuance and delegation series.

The evidence does not reveal the final state of each request, the age of open cases, the number of information cycles, or a request-to-output key. It does not tell us that 307 or 349 cases failed. It does not establish an approval rate, a rejection rate or an operational backlog. It does not show that an issuance was routed or used. And it gives no basis to allege concealment, error or noncompliance.

Those are not rhetorical caveats attached after a dramatic conclusion. They are the boundaries that make the conclusion useful. ARIN has published two sides of a process. Until the cohorts are joined, the space between them should remain unknown rather than be filled with labels the data did not provide.

Sources