By Yair Knijn · June 4, 2025

The ghost allocation nobody will claim, and why you can't safely reclaim it

You are the network architect who finally ran the report. Forty-one allocations across the supernet have no owner, no ticket reference, and no application name, and half of them still answer pings. Your assumption walking in was that a live block belongs to someone who would notice if it vanished. That assumption is the trap, and it is why these blocks will outlive you in the role.

Nobody allocated 10.40.0.0/20 intending it to become a ghost. It got carved in a hurry, the person who asked changed teams, and the record that would tell you why it exists was never required.

How allocations lose their owners over a few reorgs

An owner is a person, and people move. The engineer who requested a /22 for a payments pilot is in a different org chart eighteen months later, the team got renamed twice, and the wiki page documenting it was archived in a Confluence migration. The allocation did not change, but everything pointing at it did. After three reorgs the only durable fact left is the subnet itself, with a blank owner field nobody was ever forced to fill.

This is the gap between an attribute you capture at request time and one you hope to reconstruct later. A free-text "description" an operator can skip is not metadata, it is a wish.

Why nobody will sign off on reclaiming a ghost block

Reclaiming a live-looking block is an asymmetric bet. Reclaim it and nothing breaks, you recovered some space and nobody thanks you. Reclaim it and a forgotten batch job loses its source IP three weeks later, you caused an outage that traces straight back to your change. Faced with that payoff, every reasonable architect picks the same answer: leave it. The block becomes untouchable not because anyone defends it, but because nobody can produce the evidence that would let them say yes.

So the org rations the space it can prove it owns and routes around the rest. You hand out tighter subnets and split a clean /16 to avoid the murky one next to it, and fragmentation worsens while a fifth of the supernet sits frozen.

Ownership and purpose as required fields, enforced at request

The fix is boring and it works: make the allocation request impossible to complete without an owner and a purpose. Not optional, not a description box, validated fields tied to something that persists.

• An owning team, resolved from your directory, not a person's name that leaves with them.
• A purpose or application identifier that maps to a real service or change ticket.
• A requested-by identity and timestamp, written automatically, not typed.
• An optional review or expiry date for anything that calls itself temporary.

Captured this way, the metadata survives the reorg because it points at a team and a service, not at a chair someone vacated. The cost is a few seconds at request time; the alternative is the forty-one ghosts.

Safe reclamation: evidence trails that let you say yes

Ownership at request time only fixes new allocations. For the existing ghosts you need an evidence trail, because the question blocking reclamation is always "can you prove this is dead." Flagging any address quiet for ninety days and re-reviewing it each quarter is common practice, but a date is only half the answer. The reclaimable block is the one where the IPAM record, live DNS, and what DHCP actually serves all agree it is silent, and you can see who last touched it and when. With those lined up, "reclaim it" stops being a guess and becomes a decision someone will sign.

Spot IPAM makes owner and purpose required at allocation time, scoped per Environment, so a block can never enter your inventory anonymous, and it reconciles each record against live DNS and DHCP so reclamation rests on evidence instead of nerve. See how it works on the features page.