Summary

  • On 30 October 2026, RIPE NCC recorded adjacent 80.224.190.0/24 and 80.224.191.0/24 leaving Vodafone ONO for Warian S.R.L. and CLOUD.GAL, S.L. respectively; each /24 contains 256 addresses.
  • Current RDAP places the preceding 62 /24s inside ONO's broad 80.224.0.0–80.224.189.255 record, the final two /24s in separate recipient records, and a literal 80.224.128.0/18 query at the generic 80.0.0.0/8 object.

A transferred block is a precise address interval. It is not a promise that the old parent prefix will survive as a neat, clickable registry object. RIPE NCC's allocated-PA transfer file shows the point at the far end of Vodafone ONO's 80.224.128.0/18. On 30 October 2026 it records 80.224.190.0/24 going to Warian S.R.L. in Italy and the immediately adjacent 80.224.191.0/24 going to CLOUD.GAL, S.L. in Spain. Both rows say POLICY and PERMANENT. The two destinations sit side by side on an address map; they have different names in the registry.

The file's own columns refuse to form one tidy rectangle. The Warian row calls 80.224.128.0/18 its original block and 80.224.190.0/24 its transferred block. The CLOUD.GAL row calls 80.224.191.0/24 both the original and transferred block. RIPE's field definitions define an original block as the initial address block from which all or part was moved. The two transferred /24s are mathematically adjacent and both fall within 80.224.128.0/18. That geometry does not license an editor to replace the second row's original-block value with the first row's.

The present database has its own geometry. Ask RIPE RDAP for an address at 80.224.128.0 and it returns ES-ONO-20010928, an ALLOCATED PA record spanning 80.224.0.0 through 80.224.189.255. That object reaches far below the /18's beginning but stops exactly before 80.224.190.0. Within the mathematical /18, it covers the first 62 of 64 /24-sized units: 15,872 of 16,384 addresses. This is the portion a reader would wrongly lose by treating a missing /18 object as a missing allocation.

The next address enters Warian's /24, IT-WARIAN-20010928, with registration and last-change timestamps of 30 October at 07:03:47 UTC. The address after that /24 enters CLOUD.GAL's /24, ES-CLOUDGAL1-20010928, registered at 11:10:00 UTC. The two timestamps are 4 hours, 6 minutes and 13 seconds apart. They describe registry edits. The transfer rows supply the parties, policy type and date; the current objects show where the three administrative intervals meet.

Now try the seemingly natural literal /18 RDAP request. It currently returns RIPE-NCC-MANAGED-ADDRESS-BLOCK for 80.0.0.0/8. A researcher who stops there gets a continent-sized answer to a two-/24 question. The useful read is a boundary walk: 80.224.189.255 still resolves to ONO, 80.224.190.0 resolves to Warian, and 80.224.191.0 resolves to CLOUD.GAL. An institutional ledger can preserve each transfer while the query most likely to be pasted into an audit report points somewhere too broad to explain it.

The public transfer rows contain no shared deal identifier for these adjacent /24s. A transaction document would settle whether the recipients' moves were commercially related. The registry already settles the narrower, harder fact: one old /18-sized address span now has a 62/1/1 registration boundary, and the fields describing the two exits are not interchangeable.