Summary
- RIPE NCC reported 5,935,616 IPv4 addresses transferred in July, up 4,159,744 from June. Summing every July row marked
POLICYacross four public IPv4 tables reproduces the headline exactly. - Four identical from-to counterparty groups contribute 5,299,712 addresses, or 89.29% of the reported subtotal. The largest, Ziggo B.V. to Vodafone Libertel B.V., contributes 52.74% by itself.
- The same tables contain 54 July rows marked
MERGER_OR_ACQUISITION, totalling 49,280 addresses. They sit outside the exact policy-coded subtotal; this is a classification boundary, not evidence that either category is wrong. - Address volume is not transaction count, price, demand or participation. A useful monthly receipt would publish the address, row, counterparty, type and direction denominators together.
The increase is exact, but its unit needs a name
The August member update gives one concise registry statistic: 5,935,616 IPv4 addresses transferred in July, with a parenthetical increase of 4,159,744. Those are unusually large figures, and the arithmetic behind them can be reconstructed from RIPE NCC's public records.
The relevant surface is not one table. RIPE NCC separates transfers within its service region into allocated PA space and assigned PI space. It separately publishes IPv4 transfers into and out of the region. Each row can carry one or several transferred prefixes, or an explicit address range. Each row also states a transfer type.
Every July prefix and range in those four datasets was converted to its IPv4 address count. The 351 rows labelled POLICY sum to 5,935,616. Repeating the same calculation for June gives 1,775,872. Subtract June from July and the result is 4,159,744—the exact increase in the member update.
That correspondence is strong public evidence about the subtotal. It is not access to RIPE NCC's internal query, and it does not show that the editorial label was meant to describe every kind of registration change. It shows that the published number equals the policy-coded rows across the four public tables at the time of capture.
Four pairs carry almost nine-tenths of the volume
The July subtotal looks different when the rows are grouped by the identical from and to strings published by RIPE NCC.
The largest group is Ziggo B.V. to Vodafone Libertel B.V.: 34 rows dated 7 July, carrying 3,130,368 addresses. That is 52.74% of the entire policy-coded month.
Three more groups make the concentration visible:
- BT Italia S.p.A. to RETELIT-X S.R.L.: 25 rows and 944,128 addresses;
- One Hungary Ltd. to 2Connect Telecommunications Infrastructure & Network Services Ltd.: 26 rows and 887,296 addresses; and
- Cityfibre Limited to ENTANET International Limited: 10 rows and 337,920 addresses.
Together the four groups contribute 5,299,712 addresses, 89.2866% of the 5,935,616 headline. The remaining policy-coded volume is spread across the other public groups, including incoming and outgoing inter-RIR rows.
“Group” is deliberate. Thirty-four rows with the same names and date are not necessarily 34 economic transactions, and they are not proven to be one contract or one operational migration. The public ledger tells us which prefixes changed recorded holder under which classification. It does not disclose the private instrument that joined those changes.
A /13 outweighs 2,048 /24s
Address-weighted reporting gives a large block a large vote. A /13 contains 524,288 IPv4 addresses. A /24 contains 256. One /13 therefore contributes as much to the monthly total as 2,048 /24s.
That is not a flaw in an address-volume statistic. It is the statistic's unit. The problem begins when the unit is read as something else.
A jump in addresses can occur while the number of rows falls. It can occur because one counterparty group moves several large prefixes. It can occur without any public change in price, number of buyers, number of sellers or intended use. Conversely, a busy month of small blocks can add many rows and counterparties while barely moving the address total.
July demonstrates the distinction. The headline rose by more than 4.1 million addresses from June, but four counterparty groups explain nearly nine-tenths of July's policy-coded volume. That supports a statement about concentration in this month's recorded address volume. It does not support a conclusion that the whole IPv4 transfer market suddenly deepened.
The policy code is not a price code
RIPE NCC's transfer terminology distinguishes a transfer according to policy from a transfer due to a change in an organisation's business structure, such as a merger or acquisition. RIPE-807 requires the published list to state which of those two descriptions applies.
The captured July tables contain 405 rows across both types, representing 5,984,896 addresses. The 351 POLICY rows produce the exact 5,935,616 headline. A further 54 rows marked MERGER_OR_ACQUISITION contain 49,280 addresses.
There is no reason to erase that classification. Business-structure changes and policy transfers answer different questions, and RIPE's rules require the distinction to be public. Nor is there evidence that the 49,280 should have been added to the member update. The narrower point is that the update's label does not tell a reader which subtotal it is using, while the underlying tables do.
The word POLICY also does not mean “sale”. A registry transfer can be permanent or temporary and can arise through arrangements whose price and commercial purpose are not in the public record. The table proves an approved registration change. It does not prove consideration, valuation, utilisation, routing, customer movement or beneficial ownership.
The register is not a market tape
This boundary matters because IPv4 scarcity invites economic interpretation. Analysts look at transfer volume for signs of liquidity, demand and consolidation. Brokers, operators and investors may compare one month with another. A single large percentage move can acquire a story before anyone asks how many blocks and counterparties produced it.
RIPE NCC is not obliged to publish private prices in order to make its own subtotal legible. The within-region IPv4 page already publishes original block, transferred blocks, parties, country codes, type and date. The inter-RIR page provides the cross-registry direction. The raw JSON makes exact aggregation possible.
What is missing from the monthly headline is a compact join. Alongside addresses transferred, it could state the number of public rows, the number of distinct normalized from-to pairs, the top-one and top-four address shares, within-region versus incoming and outgoing volume, allocation versus assignment, policy versus business-structure type, and permanent versus temporary status.
That receipt would not turn registry data into a price feed. It would prevent an address-weighted subtotal from masquerading as a participant count.
A number can be correct and still invite the wrong conclusion
The August figure passes a demanding reproducibility test. Its total and month-on-month increase both match the public tables exactly. The issue is not bad arithmetic.
The issue is compression. One number hides four data surfaces, two transfer types, hundreds of rows and a highly concentrated distribution of address space. A reader sees 5.9 million and may imagine 5.9 million interchangeable units moving through a wide market. The register shows something more specific: a few large counterparty groups dominate the month's policy-coded address volume.
The correction is small. Label the subtotal, publish its denominators and retain a calculation snapshot when the live tables advance. Then the headline can remain short without becoming ambiguous.
July was large by address count. Four pairs made it large. Those are compatible facts, and both belong in the receipt.
Sources
- https://www.ripe.net/about-us/news/ripe-ncc-member-update-august-2026/
- https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/
- https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics/
- https://www-static.ripe.net/dynamic/table-of-transfers/ipv4/transfers-allocations.json
- https://www-static.ripe.net/dynamic/table-of-transfers/ipv4/transfers-assignments.json
- https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics/
- https://www-static.ripe.net/dynamic/table-of-transfers/inter-rir/incoming-ipv4.json
- https://www-static.ripe.net/dynamic/table-of-transfers/inter-rir/outgoing-ipv4.json
- https://www.ripe.net/publications/docs/ripe-807/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
