Preparing an IPv4 block for sale: the cleanup that happens before the listing

Run the buyer's diligence on yourself first

The asymmetry that decides how a sale goes is simple: a problem the buyer discovers becomes a negotiation, a problem you disclose is just a fact about the block. And buyer diligence is not hypothetical politeness. Published buyer checklists really do read the routing past: one broker's 2026 due diligence checklist tells buyers to review past origin ASNs, route changes and prefix visibility from route collector data, and to sweep blocklist status across the full prefix rather than a sample address. Escrow guidance going back years describes pulling whois history and the registries' whowas services for every block listed. The market side is attributed rather than proven, but consistent: two brokers publicly claim that clean blocks with clear histories sell at better prices, one adding that they also sell faster, and while nobody publishes a verified premium, IPv4.Global's public prior sales table (checked late August 2026) shows real closed prices to benchmark against, with /24s that month clustering in the mid twenties of dollars per address on that marketplace and the largest blocks, /17 to /19, in the low to mid teens. Whatever the claimed premium is worth, the diligence is certain, so run it on yourself first.

Confirm you can sell it at all

Every registry puts conditions on the seller, and some of them are calendar locks you cannot fix with paperwork. At ARIN, the source must be the current registered holder and not involved in any dispute over the status of the resources, and the timing rule bites at the organisation level: under NRPM 8.3 an org that has received a transfer, allocation or assignment from ARIN in the past 12 months cannot be the source of a specified transfer, even for unrelated blocks it has held for decades. Two exceptions apply, merger and acquisition transfers under 8.2, and a waiver ARIN may grant for a renumbering exercise under 8.5.5.1; the inter-RIR rule in 8.4 is worded differently again and does not apply where one party owns or controls the other. Selling also bars the organisation from applying for space on ARIN's waitlist for 36 months, and the process wants a signed and notarised officer acknowledgement letter, so line up an officer who can sign. In the RIPE region, the 24 month holding period bars selling space for two years from the date the current holder received it, whether from the NCC, by transfer, or through a merger or acquisition, though a further merger or acquisition can still move the block inside that window without freeing it for sale. Two things fall outside that clock: legacy space transferred within the region, which RIPE transfer policy does not cover, and consolidation between LIR accounts held by the same member, which does not start a fresh period. The NCC's document checks are concrete: a recent registration document from national authorities and a transfer agreement signed by representatives legally authorised to act for each organisation, which need not be directors, plus proof that those signatories are authorised. An unrecorded name change or merger does not kill the sale but stalls it while official documents covering every entity in the chain are produced. APNIC mirrors the current holder and no dispute conditions and applies a /24 minimum transfer size, as ARIN does under NRPM 8.5.3, though RIPE sets no minimum size for IPv4 transfers at all and allows partial blocks to move. APNIC adds its own clock: space delegated from the final 103.0.0.0/8 pool cannot be transferred for at least five years after that delegation. How transfers work covers the process itself; the seller's job here is checking the locks before listing.

Wind down tenants and announcements deliberately

If the block has lessees or internal use, the wind down is the part of the preparation that is visible from space. Route collectors record when a prefix was announced, by which origin AS, and when each announcement ended, and any buyer who pulls the block's routing history will see it; the default views omit only low visibility announcements that few collector peers saw. A flurry of withdrawals and origin changes in the weeks before a listing reads like the churn buyers are trained to distrust, so plan the wind down on a schedule and keep your own dated record of what was withdrawn when. Leasing out IPv4 safely covers the tenancy side. On the mechanics, know what a letter of authorization does and does not do: an upstream that runs on letters checks the LOA once, at turn up, and nothing monitors its expiry date, so a revocation letter withdraws nothing by itself. When a lease ends, put the request to the lessee's upstreams directly, keep copies of what you issued and to whom, and back the request with the controls routers actually evaluate, which means the route objects and ROAs of the next section. On timing the registries are silent: ARIN's own seller checklist says nothing about when to stop announcing, and the specific windows circulating come from market intermediaries; one escrow agent's guidance, published in 2021 and preserved now only in archive copies of its site, recommends the announcement be withdrawn at least 48 to 72 hours before the transfer is confirmed so the block can be verified quiet before closing.

Sweep the paper: IRR, ROAs, SWIP, contacts

ARIN publishes a Source Pre-Transfer Checklist, and it is a good skeleton for any region: edit or delete the transferring prefixes from your ROAs, revisit maxLength, update or remove IRR objects that will no longer apply, agree a reverse DNS handover plan with the buyer, and make sure the buyer knows the post transfer RPKI, IRR and reverse DNS work is theirs, which the post transfer checklist covers from their side. The IRR sweep is the fiddly part because route objects belong to their maintainers: normally only the registering maintainer can delete one, so an object an old upstream registered is theirs to remove, and the escape hatches are the registry operator's support desk, the RIPE Database's force delete, which lets the maintainer on the covering allocation remove more specific objects including old customer route objects, and the automatic deletion of RIPE-NONAUTH objects that conflict with a ROA for 14 straight days, running since January 2020. RADb marks objects that no longer match routing reality with stale badges, but the badge is informational and queries still return the object, so stale still pollutes filters until someone deletes it.

ROAs deserve their own sentence because the failure mode lands on the buyer. A ROA is a standing statement that one AS may originate the prefix, and while it is the only ROA covering the block, every other origin evaluates RPKI invalid. The registries drop a seller's ROAs on transferred prefixes at completion, ARIN removing them and re-rolling the certificate and RIPE reissuing the certificate outright, so the lasting version of this problem is the lease that ended without cleanup: a ROA still naming an ex-lessee's AS keeps that AS validly authorised to originate your space. Retire it in your own portal before listing, while you still control it. Then the registry records: delete reassignment and SWIP records for wound down customers, which at ARIN happens in ARIN Online or through the API and cannot be undone, and in the RIPE Database can be force deleted under your allocation even when the old customer's maintainer is unreachable. Both registries run annual validation clocks on contacts, so an abuse mailbox that bounces or a contact marked invalid is visible hygiene failure; confirm the abuse address answers before anyone else writes to it. And if you publish a geofeed, RFC 8805 names this exact case: publishers can blank the location fields for space being redeployed elsewhere, and consumers may refresh only weekly, so edit the feed when you vacate the space, not when the buyer complains.

Start the reputation pass early

Sweep the whole prefix, not a sample address; buyer guidance says a /24 can hold clean and damaged addresses in the same range and warns about old listings that return when traffic resumes. Then work the delisting queues with their real mechanics in view. Spamhaus puts removal on the network owner: it is your responsibility to report that the conditions behind a listing no longer apply, the formal request runs through the responsible ISP, and removal is always free, with Spamhaus itself calling any paid delisting offer a scam, worth knowing before hiring cleanup help. Its automated listings mostly age out on their own about three days after the last detection, provided the abuse actually stopped, and re-listing is immediate if it did not. UCEPROTECT's published policy, read from an archived copy of its site in August 2026, expires listings free of charge seven days after the last detected abuse, with every new report restarting the clock; its paid immediate removal is barred in several cases, including while abuse is still being detected, so it cannot be relied on as a closing week rescue. None of the registry or broker guidance we reviewed names a lead time for starting this work, so the recommendation is ours alone: start the reputation pass months before listing, because delisting queues, seven day windows and relapses consume calendar time that cannot be compressed at the end.

Read your own report like a skeptical buyer

Before the listing goes anywhere, look your own block up on the front page and read the report the way the buyer's analyst will. The Type row prints the registry's status string verbatim, a Status row appears when the registry's flag says more, and the Organisation row names the holder, which should already match the entity that will sign. The origin history shows the networks collector peers have seen announce the space, with first and last seen dates, and that table includes the lessee announcements those peers saw; every row you did not expect needs an explanation you can give proactively, and reading a prefix's routing history is the guide to what a buyer will make of the patterns. The feed readings on sampled addresses show current standing only, a snapshot rather than a clean bill, and a serious buyer knows that too: absence of findings is never a finding of innocence, on this site or in their diligence. What the report cannot do is also worth knowing before someone asks: it keeps no registry holder name history and no dated blocklist records, so the provenance file, the chain of custody documents a transfer and a delisting conversation both need, is yours to assemble from registry papers and corporate records, and proving a range changed hands is the template.