Summary

  • A June 2026 movement of 262,144 IPv4 addresses appears in 39 ARIN records and one APNIC record. The address ranges match; the packaging differs.
  • Registration, commercial agreement and working network are separate things. Neither a busy transfer log nor a correct registry entry proves the other two.

Thirty-nine entries look busier than one. In an IPv4 transfer log, that can be an illusion created before a single market conclusion is drawn.

Take 22 June 2026. ARIN's record names Globenet Cabos Submarinos America Inc. as the source and DingFeng XinHui (HongKong) Technology Limited as the recipient of 39 IPv4 ranges moving from ARIN to APNIC. The receiving registry records the same date, recipient and ranges in one entry. Both descriptions cover 262,144 addresses. Opening the APNIC entry reveals the ranges that occupy separate entries in ARIN's file.

This is not a claim that 39 commercial transactions became one. The logs do not establish how many contracts were signed. It is a simpler, reproducible observation: counting entries without looking inside them gives very different answers about the same recorded resources.

Open the entry before counting it

BTW compared the cumulative ARIN log served by APNIC's official mirror with APNIC's own log, both produced on 25 October. For the June example, all 39 normalised start-and-end address pairs match, and none of those ranges overlaps another. The source's full company name comes from ARIN; APNIC uses a registry handle in that field. Matching the resources is more reliable here than expecting every identity field to look identical.

The difference persists across a wider, carefully bounded comparison. For IPv4 resource transfers from ARIN to APNIC dated from 1 January through 30 June 2026, the ARIN file contains 130 entries and APNIC's contains 45. Each sums to 2,356,224 address occurrences. The calculation uses the ranges actually transferred, excludes the merger-and-acquisition category, and does not include transfers in the reverse direction.

Those two totals must not be added together. They are two descriptions of the same corridor, not two independent supplies of addresses. Nor does 130 or 45 tell us how many independent buyers participated. A recipient may appear more than once; a record may contain several ranges; a commercial arrangement is not fully described by either file.

The NRO format documentation explains the common structure used to publish transfers within and between registries. A common file format makes comparison possible. It does not make every record a standard-sized unit of market activity.

A headline number needs its original date

The earlier version of this article relied on a September analysis of the first half of 2026, which reported approximately 8.8 million addresses associated with about 293 inter-registry transfers, excluding mergers and acquisitions. That remains an attributed historical estimate. The October files examined here do not independently reproduce its full global total or its event-counting method.

Our narrower comparison is not evidence that the earlier estimate was false. Cumulative logs can change, the observation dates differ, and a count requires decisions about what constitutes an event. Treating a fresh download as though it were the original historical dataset would introduce a new error while trying to correct an old one.

Even agreement between two registries should not become an assumption. In the October snapshots, ARIN-to-RIPE NCC address totals differ by 8,192 between the RIPE NCC file and ARIN's file under the same stated filter. That discrepancy requires reconciliation, not an invented explanation. The successful ARIN–APNIC comparison does not certify every other corridor.

There is a tempting shortcut once the numbers are assembled: rising volume with little change in the entry count must mean a handful of larger transactions. It need not. Many entries could have grown together. Establishing concentration requires the distribution of sizes and recipients, not merely dividing one total by another.

The address can stay put while its registration moves

The administrative movement is real. It still is not a map of traffic.

An inter-registry transfer changes the recognised registration relationship; the address numbers remain the same. It does not by itself show a server being relocated, a new network originating the route, or a service moving to another country. Nothing in the June example establishes where those addresses were used or whether their routing changed.

That distinction becomes practical when someone has to make the resource work. A registered holder can authorise another organisation's autonomous system to originate a prefix. A lease or operating arrangement may change the user without producing a new transfer entry. A different name in the routing evidence is therefore a question to resolve, not automatic evidence of misuse.

RIPE NCC's explanation of origin validation identifies what a Route Origin Authorisation, or ROA, does: it authorises an autonomous system to originate a prefix and can set the maximum permitted prefix length. It does not show that the route is currently being announced, validate the whole path, or confirm that a customer can reach a service.

An engineer accepting transferred addresses needs the intended state of each relevant layer: registration, origin authorisation, routing, provider filters, reverse DNS and working contacts. The test is consistency with the intended arrangement. It is not a demand that every field change merely because a transfer has occurred. Keeping the same origin can be entirely deliberate.

Count carefully, then test something different

A transfer log can answer who is recorded, which resources are involved and when the registry recorded a movement. It cannot carry the entire burden of a commercial or operational assessment.

The June example makes that boundary unusually visible. Thirty-nine entries on one side and one on the other describe the same 262,144 addresses. Before calling a market more active, count comparable things. Before putting the addresses into service, stop counting and check whether the promised network state actually exists.

Updated 25 October 2026: this article now distinguishes the previously cited historical estimate from a new comparison of primary registry logs. It corrects the inference that stable event counts and rising volume alone establish concentration, and removes an incomplete prefix-splitting example. The original URL and publication date are retained.