RIPE NCC and the economics of address-reputation contamination

Summary

• Address-reputation contamination is the economic residue that remains when private trust systems remember old abuse, spam, scanning, proxy use, botnet traffic, geolocation errors or customer complaints after the RIPE NCC record and route state have been corrected.
• In a scarce IPv4 market, a range can be properly registered, transferable, routeable and still impaired because mail receivers, payment providers, cloud platforms, security vendors, upstreams and customers do not treat registry recognition as a reputation reset.
• RIPE NCC's facts matter as evidence: current holder, contacts, transfer history, reverse DNS, RPKI and routing records can help prove present responsibility. They do not guarantee delisting, cloud admission, mail deliverability, payment acceptance or geography correction.
• Contamination comes from prior tenants, leased use, unmanaged hosting customers, compromised infrastructure, open proxies, abusive scanners, botnet traffic, stale reverse names, old route origins, noisy neighbours and vendor files that decay slowly.
• The cost bearers are uneven: buyers, sellers, lessors, lessees, hosting customers, public-service users, upstreams, abuse desks, lenders and auditors each absorb a different part of the cleanup bill.
• Serious transactions need reputation warranties, evidence schedules, escrow holdbacks, indemnities, post-transfer cooperation, cleanup logs, delisting records and intended-use testing rather than generic claims that a block is clean.
• Small networks are disadvantaged because they have fewer vendor relationships, less mail and abuse capacity, less cloud leverage and fewer spare ranges for quarantine or segmentation.
• The moral hazard is that dirty ranges can circulate toward weaker buyers while clean holders subsidise opaque users through higher diligence, stricter filters and broader suspicion.
• RIPE NCC should remain a reliable registry ledger, not a reputation court. Its useful contribution is narrow: accurate records, role contacts, reverse-DNS and RPKI surfaces, clear transfer history, and limited status language that helps markets prove current control.
• The watchpoint for 2026-2029 is whether scarce IPv4 is priced and governed as a bundle of current registry facts plus external memory, rather than as a number range that becomes economically new when a record changes.

The record is right and the traffic is still distrusted

The buyer has done the part of the transaction that the Internet usually sees. The RIPE NCC record names the right holder. The seller has signed. The route is visible from the expected network. The abuse contact now reaches the new desk. Reverse DNS has been drafted, and the first customers have scheduled their migration windows. On paper the range is ready. Then the deployment meets a different ledger.

A customer cannot send password-reset mail without throttling. A payment provider asks why callback traffic comes from addresses associated with a previous high-risk hosting cluster. A cloud platform delays a bring-your-own-IP admission because its trust team sees a history that the buyer did not see. A geolocation vendor still places a subrange in the wrong country, breaking content rights and fraud rules. A security feed remembers scanning from the same /24. An upstream asks for extra proof that the new route and the customer story are legitimate. The registered state is correct. The market does not behave as if the slate has been wiped clean.

That is address-reputation contamination. It is not a defect in uniqueness and it is not a challenge to the importance of the RIPE NCC ledger. It is the residue of earlier use in systems that sit outside the registry: blocklists, mail filtering, payment and fraud scoring, anti-abuse vendors, cloud admission desks, geolocation files, security products, customer allowlists, upstream risk teams and complaint histories. These systems do not move at the speed of a registry update. Some are public and appealable. Some are private and opaque. Some refresh daily. Some preserve old judgements because abuse networks also claim to be under new control.

The phenomenon matters because IPv4 scarcity has changed the commercial status of history. RIPE NCC says on its IPv4 run-out page that its remaining IPv4 pool was exhausted in November 2019. Its service-region description places the registry across Europe, the Middle East and parts of Central Asia, with thousands of networks depending on the shared record. Scarcity means a buyer cannot always walk away from a range with awkward history. It may have to buy, lease, quarantine, clean and prove the range before the range can support the intended service.

The economics are therefore not merely about whether addresses can be sold, nor mainly about leasing contracts, nor about route hijack controls. Those questions matter elsewhere. Here the thesis is reputation residue: private memory attached to public-number resources. A technically correct address range can arrive with baggage. The bag may be small enough for ordinary hosting. It may be crippling for payments, public-sector services, regulated SaaS, mail platforms, cloud import or customer-facing security tools. The difference is value.

RIPE NCC's institutional boundary is central. A regional registry can maintain authoritative registration facts. It can support current contacts, reverse-DNS delegation, RPKI services, recognised transfer records and public evidence of who is now responsible. It cannot command every mail receiver, fraud vendor, bank, cloud platform or security feed to forget earlier traffic. It should not become a reputational court deciding which private list is fair or which customer category deserves trust. But the quality of the public record still matters because cleanup begins with proof. When private systems remember the past, the registry ledger becomes the first page of the evidence file showing why the present is different.

Reputation is external memory, not registry state

An IPv4 range now carries at least two kinds of history. The first is registry history: recognised holdership, contacts, transfer dates, route-related records, reverse-DNS authority and service status. This history is structured, visible and bounded by RIPE NCC's role. It gives strangers a common starting point. The second is external memory: operational observations stored by parties that receive, filter, route, score, admit, sell to, buy from or complain about traffic. That memory is not one database. It is a landscape of private and public judgements.

The two histories answer different questions. Registry history asks who is recognised now and how a responsible party can be reached. External memory asks whether earlier behaviour from the same range, neighbour range, origin network, provider brand or customer class predicts risk. A transfer can change the first answer. It cannot automatically change the second. A new route authorization can show that a network is allowed to originate the range. It does not prove to a bank that a fraud score should fall. A reverse-DNS correction can make names coherent. It does not erase months of spam complaints. A current abuse contact can make reports reachable. It does not persuade a cloud platform that previous malicious use is irrelevant.

External memory exists for rational reasons. Mail receivers need to resist spam and phishing. Payment networks need to reduce fraud. Cloud platforms need to prevent imported address space from poisoning their infrastructure. Security vendors need to remember malware, scanning and proxy behaviour. Upstreams need to avoid carrying traffic that creates collateral complaints. Customer security teams need to decide whether a supplier's endpoints look safe. If every claim of new control forced immediate forgiveness, abusive users would rotate through scarce ranges and turn registry updates into reputation laundering.

The same memory is also unfair in predictable ways. It can punish successors who had no connection to earlier conduct. It can mark a whole range because one previous customer ran compromised servers. It can follow an address after a lease ends. It can confuse a data centre, a reseller, a cloud customer and a final service. It can attach to an ASN or brand rather than to the precise addresses that caused harm. It can persist because some vendors have weak correction channels or poor incentives to revisit old data.

This is why the issue is economic rather than moral. The market must decide who pays for proving that a remembered risk is stale. If the seller says the range is clean because the public record is correct, the buyer may disagree. If the buyer says all old risk should be the seller's problem, the seller may answer that no one can know every private model. If a lessee damages a range, the lessor needs cleanup rights. If a customer inherits old mail history, the hosting provider needs a remediation plan. The range is not simply clean or dirty. It has a set of external memories that must be tested against intended use.

The registry layer can make this process cheaper by being dependable. A coherent RIPE NCC record helps a buyer show when recognised control changed. A stable contact path helps vendors reach the current operator. Reverse-DNS authority shows who can align naming. RPKI and routing evidence show that the origin is not random. Transfer records help mark time. None of these facts forces forgiveness. Together they let the current operator argue from evidence rather than assertion.

Scarcity turns residue into an asset-quality problem

In a world of abundant replacement space, reputation residue is an operational annoyance. A provider can choose another range, leave the dirty block for lower-trust uses, or renumber away from the problem. In the RIPE NCC region after run-out, the choices are narrower. A scarce IPv4 range may be too valuable to abandon and too expensive to replace. That changes the accounting. Reputation becomes part of asset quality.

The analogy is imperfect but useful. A building with environmental residue can still be a good building. A loan with a troubled past can still perform. A vehicle with repair history can still run. The value depends on intended use, evidence, repair cost and buyer tolerance. IPv4 now behaves similarly. A range with prior spam problems may be unsuitable for transactional mail in the near term but fine for internal service endpoints. A range associated with proxies may be poor for consumer-account creation but acceptable for controlled enterprise infrastructure. A range with stale geolocation may be tolerable for backend traffic and damaging for streaming, advertising, tax, public access or payment fraud systems. The defect is not an abstract stain. It is a mismatch between past memory and present purpose.

Scarcity also converts time into cost. Cleanup rarely happens instantly. Mail reputation may need warm-up, authentication discipline and complaint control. Payment and fraud acceptance may require evidence, exception handling and a period of low-risk behaviour. Cloud import may require letters, route evidence, registry alignment and trust review. Geolocation corrections can propagate unevenly across vendors. Security feeds update on their own cadence. A three-month delay is not just inconvenience. It is working capital, missed revenue, staff time, customer uncertainty and sometimes a failed launch.

The cost can be hidden because the registry part looks complete. The transaction closes. The record changes. The route works. Finance books the asset. Then operating teams discover that the range is not ready for the business case used to justify it. A buyer who planned bank-facing SaaS may have to use the range for lower-risk hosting while repairing trust. A public-service provider may delay migration. A cloud customer may keep paying for old infrastructure because imported addresses are not yet accepted. The impairment appears after closing unless diligence tests reputation before money changes hands.

This distinction separates reputation contamination from a simple liquidity discount. A contaminated range may still sell quickly if the price is low enough or the buyer's intended use is tolerant. Its problem is not only whether there are buyers. It is what the buyer can safely do after taking control. The price, the holdback, the warranty and the cleanup schedule should follow from intended use. A range ready for mail-heavy regulated service is different from a range that must be quarantined. Both may be scarce. They are not economically identical.

RIPE NCC's transfer policy is a factual anchor, not a reputational guarantee. The Resource Transfer Policies require transfers to be reflected in the RIPE Database and distinguish permanent and non-permanent movement of number resources. That recognition is necessary for reliance. It does not say that old spam history has disappeared, that a cloud platform will admit the range, that geolocation is correct or that a payment vendor will trust the traffic. The registry records the recognised state. The market still has to price the residue.

How contamination is written into a range

Reputation contamination has many authors. The simplest is spam. A previous user may have sent bulk mail, phishing lures or malware campaigns from the range. Even if public blocklists are cleared, receivers may retain internal history. Google says its Postmaster Tools can show measures such as IP reputation, spam rate, authentication and delivery errors for senders who have enough traffic. Microsoft describes SNDS as a service that gives data about traffic seen from IPs. These systems show the obvious point: mail trust is measured by behaviour, not by registry recognition alone.

Compromised infrastructure is another author. A hosting customer may run a vulnerable CMS, an abandoned database, an open proxy, a malware dropper or a command-and-control node. The holder may remove the customer, but security archives and vendor feeds may still connect the addresses with the incident. If the abusive customer sat near innocent customers, the memory may spread to a broader neighbourhood. Receivers do not always know the internal assignment boundary. They see noisy traffic from a range and mark risk where their data allows.

Botnet and scanning traces are especially persistent because they are often observed by many parties at once. A range used for credential stuffing, exposed-service scanning or proxy rotation may appear in network telescopes, customer firewalls, threat feeds and law-enforcement reports. Some uses are malicious. Some may be legitimate security research conducted without enough disclosure. Some may be customer compromise rather than intentional abuse. The external memory can still look similar: repeated unsolicited traffic from a place that later claims to be under new use.

Leased and hosted use can write history without leaving clear public traces. A lessor may keep the recognised relationship while a lessee or a customer produces the traffic. A hosting provider may assign addresses to customers that churn quickly. A reseller may sell service through another brand. A cloud or managed-service platform may originate the route while the customer controls applications. These arrangements are not inherently improper. They become a contamination problem when the party now trying to clean the range cannot prove who used it, when the conduct stopped, and which control changes were made.

Stale names and routing memory add quieter forms of residue. Reverse DNS may point to a former provider or customer type. Passive DNS may show domains that no longer belong to the current user. Historical route data may associate the range with a network that had a poor reputation. Old geolocation may place addresses in the wrong country. A public complaint archive may name a range in a way that search tools continue to surface. None of these facts necessarily proves current risk. Each adds to the burden of explanation.

Neighbour effects complete the picture. Vendors often score at /24, aggregate, ASN, provider or brand level because precise customer attribution is expensive. If a noisy customer harms a segment, innocent neighbours may pay. If a network tolerates abusive use in one corner, more cautious counterparties may distrust nearby inventory. Large platforms can segment risk. Smaller providers with fewer ranges cannot always isolate high-risk and high-trust uses. Contamination is therefore partly a portfolio-management problem.

The common feature is memory without automatic reset. A new holder can repair records, change routes, update contacts, delegate reverse DNS, produce letters and answer complaints. It still needs time and evidence. The market does not have to assume the old story remains true. It does have to be shown why the old story has ended.

Mail, payments and cloud admission turn memory into operating cost

Mail is the most visible reputation market because delivery failure is immediate and measurable. A sender may configure SPF, DKIM and DMARC, align reverse DNS, monitor complaints and send only legitimate transactional mail. If the address range has earlier spam history, the sender may still face throttling, greylisting, junk-folder placement or manual review. Public blocklist absence is useful but incomplete. Spamhaus describes DNS blocklists as tools for identifying sources of spam and related threats, but mail receivers also maintain private models. A range can be absent from a famous public list and still perform poorly in a major receiver's internal scoring.

The economics are harsh because mail reputation is often tied to customer trust. Password resets, invoices, fraud alerts, account confirmations, security notifications and public-service messages must arrive quickly. A contaminated range can force a provider to keep using old space, pay for a specialist sender, warm addresses slowly, separate traffic classes or delay a migration. If the buyer purchased the range to support a mail-heavy service, the impairment is not theoretical. It is direct revenue and customer-support cost.

Payment and fraud systems make the same problem less visible but often more expensive. Payment providers, banks, fraud-prevention vendors and merchant-risk teams evaluate endpoint behaviour. They may consider IP history, geography, hosting category, VPN or proxy signals, customer complaint records and observed account abuse. A registry record may prove that a new operator is responsible. It does not prove that the new traffic deserves lower risk immediately. A payment callback rejected by a risk system can break a service even though the route is correct.

Cloud platforms add a formal admission layer. Bring-your-own-IP services let customers use address ranges inside a cloud environment, but platforms do not treat all ranges as equally acceptable. AWS says in its BYOIP documentation that address ranges must meet requirements and that AWS may reject ranges with poor reputation or associated malicious behaviour. Google Cloud's BYOIP documentation describes validation and provisioning steps for publicly advertised prefixes. These requirements are not registry rules. They are private platform trust rules that determine whether a scarce range can enter a large operating environment.

This matters because cloud admission can be the difference between owning capacity and using capacity. A company may buy addresses precisely to preserve customer allowlists while moving into cloud infrastructure. If the platform delays or rejects admission, the buyer must hold parallel systems, negotiate exceptions, provide more documentation or acquire a different range. The seller may say the addresses are valid RIPE-region resources. The buyer may answer that validity was only the first condition. The platform's risk screen is the gate that makes the business plan possible.

Upstreams and peers also translate reputation into cost. They may ask for letters of authority, current route authorization, RPKI alignment, abuse-contact proof or explanation of past events before accepting a route. The request may be reasonable caution, especially where a range has changed hands or has a history of abuse. It may also create delay. A smaller buyer without established trust channels can spend weeks assembling evidence that a larger cloud or carrier would deliver in one email. Reputation thus compounds scale advantage.

The lesson is not that private systems are illegitimate. They are part of how the Internet defends itself. The lesson is that address buyers and operators should treat them as part of deployment. A range is not ready when it is only registered and routed. It is ready when the external systems needed for the intended service have accepted the current story.

Registry evidence helps cleanup but does not guarantee forgiveness

The cleanup file begins with RIPE NCC facts because they are the easiest shared evidence to verify. The current registry record shows recognised responsibility. The transfer date helps explain when control changed. The abuse contact provides a route for reports. Reverse-DNS authority shows who can align names with the service. RPKI and route authorization show that the current origin is expected. RDAP and Whois surfaces provide public contactability. These facts are necessary because vendors are rightly sceptical of unsupported claims that a range is under new control.

They are not enough. RIPE NCC's reverse-DNS material explains the registry's role in registering reverse delegations for address space. A corrected reverse delegation can reduce confusion, especially for mail, logs and customer reassurance. It cannot make a mail receiver ignore prior complaint rates. RIPE NCC's RPKI pages describe route-origin authorization as a routing-security tool. A valid ROA helps prove expected origin. It does not prove that payment vendors, cloud platforms or security feeds trust the traffic. RIPE NCC's abuse-contact materials set out contactability. A valid abuse path does not erase earlier non-response.

Geolocation is a useful illustration of the limit. RIPE Database documentation on geolocation says RIPE NCC is not a geolocation provider and that geolocation attributes are holder-supplied rather than verified by RIPE NCC. That is a sensible boundary. It also means a buyer cannot treat registry-side geography data as a guarantee that streaming platforms, fraud tools, advertising systems or government-service checks will classify the range correctly. A corrected public field may be one exhibit in a correction request. It is not the correction itself.

The same is true for route history. Historical origins can tell a useful story: when an old provider stopped announcing, when a new operator began, whether more-specific announcements appeared, and whether the route story aligns with transfer evidence. But route evidence does not identify every customer behind the traffic. It does not prove that old abuse stopped unless paired with logs, customer removal, contract evidence, monitoring and time. Treating route authorization as reputation cleansing would confuse reachability with acceptance.

A strong cleanup package therefore layers evidence. It includes current RIPE NCC records, transfer or control-change dates, route authorization, RPKI alignment where used, reverse-DNS updates, updated abuse contacts, prior-use disclosures, known public listings, vendor correspondence, customer-removal evidence, clean-traffic monitoring, geolocation correction tickets, mail warm-up data and escalation contacts. It may include a statement that the current operator will cooperate with reasonable vendor inquiries. It should avoid claiming universal cleanliness.

This approach protects both sides. Vendors receive proof rather than slogans. Buyers avoid overpaying for an untested range. Sellers avoid impossible promises. RIPE NCC remains the public anchor without being asked to certify private reputation. The registry's value is that it makes the current state provable. Forgiveness remains with the systems that remember.

Geolocation residue is a jurisdictional tax

Geolocation errors often look less severe than blocklists until a business depends on place. A range may be used by a public-service portal in one country but still classified by vendors as another. A streaming service may apply the wrong rights rules. A payment provider may see cross-border inconsistency. A tax or advertising platform may infer the wrong market. A security tool may label traffic as a data-centre pool in a jurisdiction that triggers extra review. Customers do not experience this as a database nuance. They experience it as failed access, false fraud flags or unexplained friction.

The RIPE NCC region makes this especially sensitive because it spans many legal, linguistic and commercial environments. A range could move from a Western European enterprise to a Gulf cloud customer, from a regional ISP to a pan-European SaaS platform, from a data centre to a public contractor, or from one national market to another. The registry record can be correct while private geography systems lag. Some vendors may update quickly. Others may depend on old WHOIS-derived data, routing inference, customer traffic, passive measurements or purchased feeds. The same address can appear in different countries across different tools for weeks or months.

Geolocation residue is not always a simple error. Sometimes the current use is genuinely multi-country. A provider may serve customers across borders. A cloud platform may route traffic through one country while customers sit in another. A content service may use anycast-like architecture. A reseller may market locally while addresses remain tied to a foreign holder. The problem is not that every IP has one true physical location. The problem is that many commercial systems act as if the classification is decisive.

This creates a tax on cleanup. The operator must identify which vendors matter, file corrections, provide registry evidence, show network design, explain customer geography and then wait. Public agencies and regulated customers may require written assurance that geography-related controls have been tested. A buyer may need a holdback until a critical vendor updates. A seller may need to cooperate after closing because some correction channels require proof from the recognised holder. If the range was leased, both lessor and lessee may have to coordinate because the customer-facing operator and the registry-facing holder differ.

Geolocation also creates adverse-selection risk. Ranges with stubborn misclassification may be pushed toward uses that do not care about place, while cleanly classified ranges command a premium for regulated or consumer-facing services. That allocation is rational, but it can harm smaller networks in misclassified regions. They may lack the staff to correct many vendors and the leverage to get attention. Large platforms can maintain geolocation teams. A small ISP or hosting company may rely on a few tickets and hope.

RIPE NCC's proper role is restrained. It should keep holder-supplied registry data clear and current, and it should not pretend to be a global geolocation authority. The market should use RIPE facts as correction evidence, not as a guarantee. Buyers should test the vendors that matter to their actual use. Sellers should disclose known stubborn misclassifications. Contracts should allocate correction duties and post-transfer cooperation. Geography residue is not a registry failure by itself. It becomes an economic failure when nobody prices or assigns it.

Cleanup costs fall on the party least able to wait

Reputation cleanup creates a chain of cost bearers. The buyer pays when a range cannot support the intended use on day one. The seller pays if warranties, holdbacks or indemnities require repair. A lessor pays if a lessee returns damaged space. A lessee pays if customer conduct creates cleanup duties. A hosting customer pays when service is delayed or routed through alternative ranges. A public-service user pays when a portal, notification system or procurement review is disrupted. An upstream pays through extra review and complaints. An abuse desk pays through triage. A lender or auditor pays through lower confidence and higher diligence.

The burden rarely follows legal theory neatly. It follows urgency. The party that needs the range to work tomorrow often pays first. A buyer with a customer launch cannot wait for a seller to debate causation. A public contractor with a deadline buys alternate service. A mail operator uses a specialist sender. A cloud customer keeps old infrastructure alive. A small hoster discounts service or loses customers. Later, contracts may reallocate some cost, but operating pressure decides who funds the first repair.

This is why quarantine should be treated as working capital. A range may need a holding period before sensitive use. During quarantine, the operator tests mail, watches complaints, corrects geography, updates reverse DNS, confirms route acceptance, provides proof to platforms, and builds clean traffic history. The range is economically held but not fully productive. If the buyer financed the acquisition, debt service runs during the hold. If the buyer promised customers immediate migration, delay creates penalties. If the buyer lacks spare addresses, quarantine may be impossible without sacrificing revenue elsewhere.

The cost structure favours large operators. They can stage introductions, use clean pools for sensitive customers, isolate risky use, maintain vendor contacts, keep abuse specialists and absorb idle inventory. Small networks often use what they have. A contaminated /24 can represent a large share of their usable public space. They may not have alternative ranges for mail warm-up or public-service customers. They may not know which private vendors matter until a customer complains. The same historical residue that a hyperscale platform treats as a manageable ticket can be a serious commercial hit for a regional provider.

The cost also favours parties with information. A seller that knows prior use can price and disclose. A buyer that knows its intended vendor screens can test early. A broker that understands reputation can separate ranges by use class. A lender that sees cleanup logs can underwrite more accurately. Without information, parties replace evidence with discount, delay and suspicion. The market becomes less efficient, and clean holders pay more diligence cost because dirty history is hard to distinguish from missing history.

Cleanup economics should therefore be contractual, not improvised. Transactions should include reputation diligence before closing, defined test sets tied to intended use, known-listing disclosures, known geolocation issues, prior-use schedules where available, cooperation duties, data-retention promises, and limits on claims that cannot be verified. The goal is not perfect foresight. It is to decide who funds the likely costs before the first customer fails.

Warranties should promise disclosure and cooperation, not universal cleanliness

The cleanest-looking warranty is often the least credible. A seller says the address range is free of negative reputation, blocklist history, abuse complaints, geolocation problems, security-vendor concerns and cloud admission issues. The buyer feels protected. The promise is too broad to be real. No seller can know every private model, bank file, fraud score, enterprise firewall list, cloud desk history, mail receiver memory or neighbour-based signal. A universal-cleanliness warranty invites later dispute because the first undiscovered private flag becomes an argument over whether the seller lied or merely could not know.

Better warranties are knowledge-based, evidence-based and use-aware. The seller can disclose known public listings, known material abuse events, known prior high-risk use, known cloud admission failures, known geolocation disputes, known mail complaints, known payment or fraud friction, known neighbour contamination and known remediation steps. It can represent that it has not knowingly withheld material reputation information. It can attach recent test results. It can agree to cooperate with reasonable delisting, geolocation or platform-admission requests after closing. That is a serious promise without pretending to control the entire external memory market.

The buyer must identify intended use. A range suitable for low-volume infrastructure may be unsuitable for outbound mail. A range acceptable for generic hosting may fail a payments vendor. A range that passes cloud import may still need geography correction for public services. If the buyer hides a sensitive use, it cannot fairly demand that the seller warranted suitability for that use. If the seller knows the use and has contrary evidence, the warranty can be stronger.

Escrow holdbacks are a practical tool. A portion of the price can remain held until specific cleanup conditions are met: transfer recognition, route acceptance, reverse-DNS handover, removal from named public blocklists, cloud admission, correction of specified geolocation errors, cooperation with stated vendors, or a defined clean-traffic period. The holdback should not be a vague fund for every future complaint. It should match known risks and time windows. Otherwise it becomes an open-ended price cut disguised as risk control.

Indemnities should also be narrow. A seller can indemnify for undisclosed known abuse history, false statements, failure to cooperate, or specific pre-closing conduct within its control. A lessee can indemnify a lessor for contamination caused during the lease and for failure to support return cleanup. A hosting provider can pass duties to customers whose conduct creates listings or complaints. But an indemnity that covers every private reputation consequence forever will either be overpriced or unenforceable in practice. The range's external memory cannot be made fully contractual.

Evidence logs are the practical backbone. They should record dates, vendor contacts, public-list checks, reverse-DNS changes, route authorization changes, abuse-ticket closure, customer removal, geolocation requests, mail warm-up metrics and platform correspondence. These logs help later users avoid rediscovering the same facts. They also deter moral hazard: a party that knows its conduct will be documented has less incentive to leave contamination for the next holder.

Moral hazard sends dirty ranges toward weaker buyers

Reputation contamination creates a market-selection problem. Clean ranges are easier to sell, lease, finance and deploy into high-trust uses. Dirty ranges require more skill, patience and vendor contact. If the market cannot reliably distinguish clean, repairable and unsuitable ranges, sellers of weak inventory have incentives to describe all ranges in the same language. Buyers respond with broad discounts or avoid smaller sellers. The result is adverse selection: good inventory is under-rewarded, bad inventory circulates, and the average level of trust falls.

The moral hazard is sharper in leases and short-term hosting. A party can earn revenue from risky customers while another party bears long-term reputation damage. A lessee may route customers aggressively and return a range with blocklist history. A reseller may sell to high-churn users and leave the holder to handle complaints. A hosting provider may accept questionable signups because immediate revenue is visible and future contamination is diffuse. If return duties, evidence logs and cleanup obligations are weak, the party creating the residue does not pay the full cost.

Dirty ranges may then move toward weaker buyers. Sophisticated buyers test and demand discounts or cooperation. Large platforms can reject. Banks and public agencies can insist on proof. The remaining buyers may be smaller networks, less experienced operators, distressed users or firms that intend lower-trust activity. Some may be honest and simply under-resourced. Others may value the opacity. The range's history then worsens, and reputation systems become even more cautious. This is how contamination can compound.

Clean holders also pay. If external systems cannot distinguish current responsibility reliably, they score broadly. A cautious mail receiver may distrust a provider brand because of repeated customer issues. A cloud platform may impose more documentation on all imported ranges. Upstreams may demand extra route proof for ordinary moves. Buyers may discount whole classes of supply. The cost created by opaque or irresponsible use is socialised through higher diligence and slower trust for everyone.

The answer is not to ask RIPE NCC to punish every dirty range or approve every customer. That would turn the registry into a gatekeeper and invite political capture. The answer is market discipline built on evidence: prior-use files, reputation schedules, cleanup logs, role contacts, customer-vetting duties, lease-return requirements and transparent statements about what has been tested. Bad ranges should not be banned by folklore. They should be priced by evidence.

This distinction matters for institutional legitimacy. If the registry is asked to cleanse reputation centrally, private vendors and counterparties will still maintain their own memories. The registry would gain political heat without solving the problem. If the registry refuses to keep reliable public facts, private systems will become more powerful because there will be no trusted anchor for current responsibility. The ledger must be strong precisely so that it does not become a reputational court.

Small networks face a higher proof burden

Address-reputation contamination is not class-neutral. A large cloud, telecom group or data-centre platform can maintain abuse teams, mail specialists, trust contacts, route-engineering staff, legal support, geolocation vendors, customer segmentation and spare inventory. It can warm mail gradually, isolate high-risk customers, keep sensitive services on clean ranges, and escalate to major platforms through established channels. It can afford to leave a range idle while trust improves.

A small ISP, hoster, enterprise, university spinout or regional public-service provider may have none of that. It may acquire a small range because it has a concrete need: a customer migration, a public portal, a dedicated mail pool, a payment endpoint, a cloud move or a set of legacy allowlists. If contamination appears, the small network has fewer alternatives. It may not know which vendor file is causing the problem. It may not have enough traffic to generate reputation data quickly. It may lack a named contact at a cloud platform. It may have no spare range to keep customers away from the contaminated one.

This asymmetry can turn reasonable trust controls into an incumbency tax. Private platforms and security vendors may require evidence that only well-staffed operators can produce quickly. Buyers may prefer ranges from large known holders because the cleanup file looks more professional. Public customers may overreact to one flagged range and choose a hyperscale provider instead of a local network. The local network may be technically competent but economically unable to carry the proof burden.

The solution is not weaker hygiene. Small networks should not receive a license to ignore abuse, mail trust or customer vetting. The solution is proportional evidence. A small provider should be able to assemble a credible file: current RIPE NCC record, transfer date, route authorization, reverse-DNS plan, abuse contact, known-list checks, geolocation tickets, customer-vetting policy, prior-use disclosure where known, and a clean-traffic observation plan. Vendors and counterparties should evaluate that file against the use, not against the staffing model of a global platform.

RIPE NCC can help by keeping the public evidence surfaces simple, current and machine-readable while avoiding unnecessary burden. Clear contact semantics, reliable transfer history, accessible reverse-DNS and RPKI services, and understandable status language reduce the gap between large and small operators. If the public record is confusing, only large actors can compensate. If it is coherent, smaller actors can point to it as part of their proof.

Policy also needs to avoid laundering private gatekeeping through the registry. A rule framed as reputation protection can easily become a capital-control device if it lets large buyers, major platforms or politically connected actors decide which smaller networks deserve trust. Reputation discipline should focus on evidence and conduct, not on institutional prestige. A small network with good records should not be treated as dirty because it lacks brand power. A large platform should not be treated as clean merely because it is large.

RIPE NCC's boundary is narrow but economically important

RIPE NCC should not be expected to solve address reputation. It cannot force Spamhaus, Google, Microsoft, a bank, a payment-risk vendor, a cloud provider, a security company or an upstream to change a score. It cannot know every customer history behind a leased or hosted range. It cannot guarantee that a transferred block will be accepted by every platform. It cannot certify that geolocation is right. It cannot make a private blocklist transparent by declaring a registry fact. A registry that claimed such power would invite mandate laundering and make every private reputation dispute a registry dispute.

Its boundary is still important. A weak registry ledger raises cleanup cost because current operators cannot prove the present clearly. A reliable registry ledger lowers the cost of proof. The public record should identify recognised responsibility, role contacts, status, transfer history, reverse-DNS authority and route-related evidence in ways that are current and legible. The abuse contact should be reachable. The holder should be able to align reverse DNS. RPKI services should support expected route authorization. Public records should not overstate what they prove, but they should be dependable for what they do prove.

The ledger-versus-gatekeeper distinction is the policy guardrail. As a ledger, RIPE NCC records and serves stable facts that markets can use. As a gatekeeper, it would approve business models, inspect every customer, adjudicate private lists, bless reputation, punish unpopular use or turn number resources into a lever for national or commercial pressure. The first role is necessary. The second would damage institutional legitimacy.

This boundary also protects the market from false comfort. If RIPE NCC were treated as a reputation authority, buyers might under-test. They would assume that a clean record means clean acceptance. That would fail in deployment. Better to state the boundary clearly: RIPE NCC facts are proof of current registry state and responsibility surfaces, not guarantees of private trust. A buyer who needs mail, payments, cloud admission or geography accuracy must test those systems directly.

RIPE NCC can still improve the evidence environment. It can keep contacts current and role-based. It can preserve clear transfer timelines. It can make reverse-DNS and RPKI service paths reliable. It can publish careful educational material explaining what registry facts do and do not prove. It can use narrow status language for serious disputes without turning status into reputational judgement. It can publish aggregate timing or service metrics that help buyers plan. These are ledger improvements, not reputation policing.

The strongest version of the narrow role is boring by design. It does not promise that every address will be trusted. It promises that when a current operator approaches a private vendor, customer, upstream or court with evidence, the RIPE NCC part of the story is coherent. In a market of external memory, coherence is valuable.

The better market file is use-specific

The mature response to address-reputation contamination is a market file tied to intended use. It should not be a generic certificate of cleanliness. It should answer a practical question: for this range, under this current control, for this planned service, what external memories are known, what has been tested, what remains uncertain and who will cooperate if repair is needed?

For mail-heavy use, the file should include public-list checks, authentication readiness, reverse-DNS plan, sending-domain alignment, warm-up schedule, complaint monitoring, past known mail events and sender-specific vendor evidence where available. For payment and fraud-sensitive use, it should include endpoint geography, customer category, hosting classification, proxy or VPN history where known, fraud-vendor exceptions where available and escalation contacts. For cloud import, it should include holder evidence, authorization letters, RPKI or route expectations, platform admission status and any prior rejection. For public-service use, it should include continuity planning, geography checks, escalation paths, route acceptance, reverse-DNS control and customer-impact testing.

The file should also describe prior use without overclaiming. "Previously used by a hosting provider with unknown customer mix" is more useful than silence. "Known spam listing cleared on this date" is more useful than "clean." "Geolocation corrected with two major vendors, unresolved with one vendor" is more useful than "location fixed." "No known cloud admission failures, not yet tested with the buyer's platform" is more useful than a universal claim. Specific uncertainty is manageable. Vague certainty is expensive.

For leases and hosted assignments, the file should include return duties. The party using the range should maintain abuse records, customer-vetting evidence, route changes, reverse-DNS changes, known complaints, delisting work and cleanup cooperation. At return, the lessor should receive enough evidence to protect the range's next use. Without such duties, the range can be monetised during the lease and damaged after it leaves the lessee's hands.

For transfers, escrow and holdback design should follow the file. If the only known issue is one public blocklist, the holdback can target removal or proof of cooperation. If cloud admission is essential, a condition can target platform acceptance. If geolocation is critical, the holdback can cover specified vendors and time windows. If the issue is unknown private reputation, a broad holdback may be unfair unless the buyer disclosed the sensitive use and the seller made a strong claim. Precision reduces disputes.

For lenders and auditors, the file should separate recognised control from service acceptance. It should show that the borrower has registry standing and also that the intended revenue streams are not blocked by hidden trust problems. If a range is quarantined, the file should treat that as a time and cost assumption. If a range is suitable only for lower-trust use, the valuation should reflect the limitation. Scarce IPv4 can support capital value, but only if the capital model includes cleanup risk.

The market file is not bureaucracy for its own sake. It is a way to keep scarce resources from being priced by rumour. It rewards clean operators, protects cautious buyers, assigns repair duties and reduces the temptation to push dirty ranges toward whoever asks the fewest questions.

The 2026-2029 test is whether the market prices memory honestly

The next phase of IPv4 scarcity in the RIPE NCC region will not be defined only by whether addresses can still be bought, leased or routed. It will be defined by whether the market treats address history honestly. Scarce resources invite financial language: inventory, asset, collateral, rent, return, transfer, optionality. Reputation contamination adds a less comfortable term: baggage. A range may be valuable and burdened at the same time.

Honest pricing begins with admitting that registry correctness and private acceptance are different states. A buyer should not pay a ready-use price for a range that needs months of mail, cloud or geography repair. A seller should not be punished for invisible private models it could not know, but it should disclose known material history. A lessor should not let lessees monetise risky customers without return cleanup duties. A public customer should not accept "the route works" as evidence that payment, mail, geography and abuse systems are ready. A lender should not treat number-resource value as near-cash without testing use fitness.

The institutional temptation will be to ask the registry for shortcuts. Declare a range clean. Force vendors to reset. Publish more customer detail. Police leases. Penalise unpopular traffic categories. Use registry status to solve private trust. Each shortcut expands the registry beyond its legitimate role and still fails to bind the external systems that matter. The better discipline is harder but more durable: keep the RIPE NCC ledger narrow and reliable, then require market actors to build evidence around intended use.

There is also a fairness test. Reputation controls should not become a hidden tax that only the largest platforms can pay. Small networks should maintain serious records and answer abuse. They should also be able to prove current responsibility without needing a global trust department. Clean holders should be rewarded for evidence. Dirty history should be repairable when conduct changes. Vendors should remain cautious but responsive to credible proof. Buyers should stop treating silence as cleanliness.

Address-reputation contamination is finally a story about the limits of administrative state. A registry record can settle who is recognised. It can establish a public point of responsibility. It can support route authorization, reverse naming and contactability. It can provide a timestamp that helps the current operator explain a change. It cannot erase memory held by the rest of the Internet. In scarce IPv4 markets, that memory has become part of the economic bundle.

RIPE NCC's value is highest when it resists both extremes: not a passive line in a database that ignores downstream consequences, and not a gatekeeper that tries to adjudicate every private risk signal. The right role is a disciplined ledger that makes current facts clear enough for markets to repair reputation without pretending that reputation is a registry field. The right market practice is to price the address, the evidence and the cleanup path together.

When a buyer says, "the record is correct, so why is the range still failing," the answer is no longer mysterious. The record is the starting point. The reputation work is the rest of the transaction.