Summary

  • LACNIC’s current revoked-resources table lists 45.230.86.0/23 on 10 July 2023 and the nested 45.230.86.0/24 on 20 August 2026.
  • Archived delegated-statistics snapshots show the /23 allocated before the first date and reserved afterwards; a /24 at the same starting address was allocated in February 2024, remained allocated on 19 August 2026 and was reserved the next day.
  • That sequence is consistent with a legitimate recovery, split, new allocation and later recovery or return. It is not evidence that LACNIC revoked one continuous allocation twice.
  • LACNIC should add a privacy-safe allocation-episode receipt that joins each row to its allocation date, prefix lineage, event class and next public state without naming a debtor or exposing a private case file.

Two rows that look like one story

Start with the geometry. 45.230.86.0/23 covers 512 IPv4 addresses. 45.230.86.0/24 covers 256 and sits inside the lower half of that earlier range. LACNIC’s current Spanish table of revoked resources displays the /24 with the date 20 August 2026. Farther down the same page, it displays the /23 with the date 10 July 2023.

A reader who treats the prefix as the identity of the resource will see an apparent echo. The first address is identical. The second row is wholly contained inside the first. The natural suspicion is that LACNIC has recorded the same administrative act twice, or recovered in 2026 something already recovered in 2023.

The public evidence does not support that conclusion. It supports two allocation episodes separated by a return to registry custody.

The distinction matters because an IP prefix does two jobs in ordinary speech. It describes a piece of address space, and it often stands in for whoever has a right to use that space at a particular time. Only the first meaning is stable. The addresses remain the same after a recovery, a split or a new allocation. The administrative episode does not.

Six snapshots reveal the break

LACNIC publishes archived delegated-statistics files. The format specification describes them cautiously: each file is a snapshot of current allocations and assignments, without transactional or historical detail. A single file cannot tell a recovery story. Comparing files on the edges of a known date can nevertheless establish that the public state changed.

The first pair brackets the 2023 row. On 9 July, the extended file records 45.230.86.0 with a value of 512, status allocated and allocation date 26 February 2018. On 10 July, the same 512-address range is reserved; the country and allocation-date fields are blank. That transition aligns with the /23 date displayed in the revocation table.

The second pair shows that the address space did not remain one undifferentiated /23. On 21 February 2024, a value of 256 at 45.230.86.0 is reserved. On 22 February, that 256-address range is allocated with a new allocation date, 22 February 2024. The format defines the starting address and the count separately, so the row describes a /24, not the former /23 continuing under a shorter label.

The third pair brackets the 2026 row. On 19 August, the /24 still appears allocated with the 2024 date. On 20 August, the same 256-address range appears reserved. LACNIC’s current revoked-resources table gives the /24 that same date.

Placed in order, the observations are simple:

Observation date Public range state What the snapshot establishes
9 July 2023 512 addresses allocated; allocation date 2018-02-26 The /23 allocation episode was still represented before the table date.
10 July 2023 512 addresses reserved The public state changed by that day.
21 February 2024 256 addresses reserved The lower /24 was represented separately before its new allocation.
22 February 2024 256 addresses allocated; allocation date 2024-02-22 A later /24 allocation episode began.
19 August 2026 That /24 allocated The later episode was still represented the day before the second table date.
20 August 2026 That /24 reserved Its public state changed by the date shown in the table.

This is a reconstruction from daily states, not a transaction ledger. It does not reveal the hour of the change, the notice sequence, the contractual ground, the decision maker or whether either resource was voluntarily returned. It does not disclose the later state of the upper half, 45.230.87.0/24. It does not identify a holder. Those absences are limits, not blanks to fill with inference.

The policy explains reuse, not the lineage of this case

LACNIC Policy Manual v2.21 supplies the general frame. Section 7 lists circumstances that may lead to revocation. Once evidence is detected and confirmed, LACNIC seeks contact and regularisation; unresolved resources may be publicly listed for up to three months, followed by the manual’s later steps. Recipients may also return resources wholly or partially.

The manual then says LACNIC publicly lists resources that have been recovered or returned so routing filters can be changed. That sentence is important for interpreting the table. A row on the public surface does not, by itself, distinguish a compulsory recovery from a voluntary return. The page label may use the language of revocation, while the policy’s publication rule covers more than one event class.

Section 7.5 says recovered or returned IPv4 resources go to the end of the pool in force at the time, for later use in insertion order, while preserving a best-practice discretion. Reuse is therefore part of the policy design. An address range can leave one allocation episode and later enter another. It can also be divided into different prefix sizes before that later use.

That is why the two rows are not an internal contradiction. The 2023 /23 row and the 2026 /24 row can both be accurate. The daily files make a legitimate sequence plausible and, on the public state evidence, more convincing than the duplicate-revocation reading.

But the manual does not give these particular rows a lineage. A reader must discover the archived files, know that 512 and 256 are address counts, select the right boundary dates and refrain from treating snapshot changes as disclosed transaction reasons. The registry has published enough to reconstruct the outline, but not enough to identify the administrative object that changed.

A prefix is geometry, not a durable case identifier

Suppose a land registry reused the same street address after one lease ended, a building was subdivided and a new lease began. Searching by address would find both leases. It would not make them the same contract. A contract number, effective dates and a relation to the earlier parcel would keep the history intelligible.

IPv4 history needs the same separation. The prefix says which addresses are in scope. The allocation episode says which bounded grant, assignment or custody period is in scope. When the boundary moves from /23 to /24, the prefix string becomes an especially weak surrogate for the episode: an exact-string search misses the relationship, while an overlap search can merge distinct episodes.

This is not a demand to expose the organisation behind the record. The exchange format’s country code is itself limited: it describes the legal base of the resource holder and cannot reliably locate network use. The final extension values in the frozen files should not be promoted into holder identities or canonical transaction IDs without an authoritative definition. Third-party routing observations would answer different questions and are unnecessary to establish the registry-state sequence.

The public object can be opaque. What matters is that episode A for a 2018 /23 is not silently treated as episode B for a 2024 /24, and that the split relation between their address ranges remains queryable after both have ended.

The missing receipt

LACNIC could close the gap with a compact allocation-episode receipt attached to each recovered or returned row. It would not replace the delegated-statistics files or turn the revocation list into a case-management system.

The receipt needs a stable, non-personal episode ID; the prefix and size at the event; the allocation or assignment date; and a relation to any parent, child, split or merged episode. It should state the public event class—recovered, voluntarily returned or another carefully defined state—where disclosure is appropriate. It should record the effective date, controlling policy version, resulting public state and the first daily snapshot in which that state appears.

If the space is later allocated again, the new episode can point back to its predecessor without naming either recipient. A correction history can preserve the earlier receipt if a prefix boundary or event class is amended. Definitions should keep revoked, recovered, returned, reserved and reallocated from collapsing into one word.

The privacy boundary is equally important. No debtor name, invoice, personal contact, staff note, credential or non-public security evidence belongs in this receipt. Nor should publication become an external approval gate that delays recovery or reuse. The receipt records an effective public state transition; it does not authorise it.

Why the join is worth publishing

Operators already consume registry data as if every row were self-explanatory. Routing-filter maintainers need to know whether a listed prefix is no longer under the earlier allocation. Investigators need to distinguish a new allocation from continuity by the old holder. Buyers and advisers assessing address history need to avoid attaching an earlier dispute or obligation to a later episode merely because the bits overlap.

The cost of ambiguity rises when prefixes are split. An exact-match database can lose the parent history. An overlap database can over-attach it. A report may say the /24 was “revoked twice” because it was contained within a revoked /23, even though the later /24 allocation did not begin until months after the first event. The error then propagates into risk scoring, compliance review or abuse attribution.

LACNIC’s existing records already contain the outline needed to prevent that mistake. The 2018 allocation date disappears when the /23 becomes reserved. A new 2024 allocation date appears when the /24 is allocated. The second reserved state follows in 2026. A stable episode relation would make that break explicit without publishing anything about the merits of either case.

The lesson is narrow. LACNIC does not need to justify these two events to prove the table is coherent. It needs to give each event a public object that survives a change in prefix geometry. Once address space can return and be used again, the prefix alone is no longer enough history.

Sources