Leasing a /24, End to End: The Operational Lifecycle for Owner and Renter
A step-by-step look at a leased /24 over its whole life - the registry, RPKI, and abuse work that decides whether the lease holds, for both the operator leasing space out and the one taking it on.
Artem Kohanevich
Co-Founder & CEO at IPbnb
Last updated
Table of Contents
item
Most writing about the IPv4 secondary market stops at the economics. But the part that actually determines whether a lease works - or turns into a support and reputation problem for both parties - happens at the registry, in RPKI, and in the abuse mailbox. So instead of talking about the market in the abstract, let's follow a single /24 through its entire life: from a dormant allocation in a RIPE record, through the deal, onto the wire, through a year of operation, and back at the end of the term.
There are two operators here, and you're probably one of them. One holds a /24 that has carried no traffic since an IPv6-and-CGNAT redesign - clean, registered, paid for, earning nothing. The other is adding subscribers this quarter, is out of space, and faces a RIPE waiting list offering a single /24 after a 12-to-24-month wait. The lease connects them.
Phase 1: Readiness
Owner side - is the block actually lease-ready? A dormant subnet is rarely as clean as its holder assumes. Before it earns anything it needs an audit - the same work regardless of who you lease through:
Reputation and blacklist history. Check the prefix against Spamhaus DROP and SBL, the common DNSBLs, and any historical abuse tied to the range. A block that's been quiet since 2021 can still carry listings from whatever ran on it before. See our notes on IP reputation tooling.
Registry hygiene. Confirm the
inetnum,status:, maintainer objects, andabuse-care current, and that no staleroute:objects point at an origin AS that no longer announces the space.RPKI state. Check whether a ROA already exists and for which origin - a leftover ROA from the pre-redesign announcement will invalidate the renter's future announcement if it isn't updated.
Geolocation residue. Old geofeed data or third-party geo databases may still place the block where it no longer lives, which the renter feels immediately as mis-geolocated users.
None of this is a barrier - it's preparation. But it's real engineering time, and skipping it is how a lease starts with a renter unable to send mail on day one.
Renter side - why you're here. The waiting list isn't a supply channel for a network growing now: one /24, LIRs only, a long queue, no timing guarantee. The realistic fallback is CGNAT, which carries a measurable, customer-facing cost rather than a free one:
Port-block exhaustion under peak concurrency, and EIM/EIF mapping that breaks inbound connections and peer-to-peer applications.
Abuse attribution that now means correlating source port and timestamp against NAT logs for every report - a tax that grows with subscriber count.
Shared reputation and geolocation, where one subscriber degrades the address for everyone behind it.
Leased space sidesteps this: on the wire it behaves exactly like owned space - you announce the prefix and routing treats it no differently. The difference is in the paperwork and the trust model.
A managed IPv4 leasing marketplace for holders
Monetize IPv4 Without Selling the Asset
Phase 2: The agreement and the trust model
A lease is an authorization, not a transfer. The owner keeps the resource in the RIPE registry; the renter gets the right to announce it. Two documents encode that:
The Letter of Authorization (LOA) - the owner's signed statement that the renter's organization and origin AS may announce the prefix. Upstreams, IXPs, and peers ask for it to justify their filters, and many still rely on it even where RPKI is deployed.
The lease contract - term, price, permitted use, abuse obligations, and what happens on default or early termination.
The trust runs both ways. The owner trusts the renter not to get the block listed or originate something that lands abuse on the owner's name and AS. The renter trusts that the owner won't pull the ROA or LOA mid-term, won't lease the same space twice, and controls what they claim to. That's why the readiness audit matters to the renter too: before announcing, verify the prefix's routing history independently through RIPEstat and bgp.tools rather than taking the LOA on faith. Our guide to leasing safety for block owners covers the owner's half.
Phase 3: Bringing the prefix up
This is where the lease becomes real, and where most technical failures happen.
ROA creation. The owner, as registered holder, creates a ROA authorizing the renter's origin ASN - in the RIPE NCC LIR Portal, under Resource Certification. The trap is
maxLength: set it equal to the prefix length (a /24 ROA with maxLength /24) and the renter can't deaggregate; set it too loose and you've authorized more-specifics that open a hijack-by-more-specific path. For a single /24 to one renter, maxLength should match the prefix unless the renter has a stated reason to announce more-specifics.IRR route object. A
route:object in the RIPE IRR matching the prefix and the renter's origin AS, so upstreams building filters from IRR data accept the announcement.The announcement. The renter configures the prefix and originates it from the authorized AS. With a valid ROA it's RPKI-valid; without the IRR object and LOA, strict upstreams still drop it.
Validation. Both sides confirm propagation and RPKI validity - bgp.tools and RIPEstat for visibility, a Routinator or Cloudflare check for validation state. The owner watches for any unexpected origin while still announcing the space.
For the registry step-by-step, our help-center walkthrough on configuring a leased subnet and ROA covers the mechanics.
Phase 4: Living with the lease
A leased /24 isn't fire-and-forget for either party, and the division of responsibility should be explicit in the contract.
Abuse and reputation. Reports flow to the
abuse-con record, which usually points at the owner even though the renter controls the traffic. Both sides need a defined path: who receives reports, who investigates, how fast the renter must act, what triggers suspension. A renter who lets the block get listed has damaged an asset they don't own; an owner with no escalation path fields the Spamhaus correspondence.Geolocation. New users are geolocated wherever the major databases think the block lives. Publish accurate geofeed data (a
geofeed:reference in theinetnum, per the geofeed RFCs) and submit corrections to the large geo providers - an ongoing coordination point, not a one-time task.Monitoring. Ongoing checks for RPKI validity drift, unexpected origins, and new blacklist entries. An expired ROA or a changed upstream filter can take the prefix partly dark with no obvious cause.
The operational load here - onboarding, ROA lifecycle, abuse, reputation, renewals - is the substance of any lease, and there's more than one way to carry it. An owner can run it in-house, keeping full visibility and margin but standing up the IPAM, abuse desk, and registry work as a small operation of its own; hand it to a broker, which removes the day-to-day load but usually costs visibility, control of the relationship, and margin; or sit it on a managed platform that keeps the relationship and economics with the owner while absorbing the tooling and compliance.
The renter has a parallel choice: handle leased space alongside their own address management, or consolidate it with whatever already runs their routing and abuse. None is automatically right - the tasks are the same regardless; the question is where the load lives.
Phase 5: End of term - renewal, return, and reclamation
Leases end, and the wind-down has its own engineering. On renewal, align ROA expiry with contract dates so the prefix doesn't go RPKI-invalid in the gap. On return, the renter withdraws the announcement, the owner revokes or rewrites the ROA and removes the renter's route: object, and the LOA is rescinded - in that order, or you create a window of valid-but-unannounced or invalid-but-announced state. And the part owners underestimate: reputation aftermath. A block comes back with whatever reputation the renter left on it. Used well, it returns clean; otherwise the owner inherits the cleanup before re-leasing. That's the strongest argument for the abuse and suspension terms in Phase 4 being real and enforced, not boilerplate.
The third position: running this yourself
Follow the lifecycle to its end and a question appears for any operator who already holds space and serves customers: why be one party in someone else's marketplace when you could run the leasing relationship under your own brand? You can - and the lifecycle above is the spec for what it takes: IPAM, an LOA and ROA lifecycle managed at scale, an abuse desk that meets report-handling timelines, delisting and reputation workflows, billing, renewals, and the compliance to stand behind it. None of it is exotic; all of it is continuous, and it's the part that doesn't show up in the lease rate. That's the real build-versus-partner decision - and data centers and hosting providers, already acting as connectivity providers to their tenants and often holding their own space, are the clearest fit.
What the lifecycle tells you
The IPv4 secondary market is more workable than its reputation suggests, but the work is real, and it's registry-and-routing work, not deal-making. Whether you're monetizing an idle block, leasing what you need this quarter, or running a leasing operation of your own, the engineering is the same: clean records, valid RPKI, a defensible LOA, disciplined abuse handling, and a clean wind-down.
Get those right and a leased /24 behaves like any other prefix in your table. Get them wrong and you have a reputation problem with someone else's name on it. On economics, price against live market data rather than any single figure - the lifecycle above, not the rate, is what decides whether a deal is worth doing.
