Summary
- IRR database fragility around RIPE NCC-administered resources is a cross-source problem: a prefix, origin ASN or AS-set path can look different in the RIPE Database, RIPE-NONAUTH, another IRR, a mirror, a private registry or a stale local filter file.
- The economic question is not only whether one routing record is correct, but which evidence source a transit provider, cloud platform, exchange route server, broker, buyer or lender can rely on when filter tools disagree.
- RIPE Database material has special value because it sits close to the Internet number resource ledger, but it is consumed through a wider environment of RPSL records, source order, recursive set expansion and private acceptance rules.
- Mirroring and near-real-time distribution improve availability, yet they can also give old data an operational afterlife when copies lose source context, freshness metadata or cleanup accountability.
- AS-set expansion turns small inconsistencies into portfolio-scale costs, because one stale member, duplicate set name or cross-source reference can alter generated filters for many downstream routes.
- RPKI and ROAs strengthen origin evidence, but they do not retire IRR data because networks still use routing-registry records for customer cones, AS-set membership, route-server admission and private risk controls.
- RIPE NCC should act as a reliable ledger and evidence service layer, not as a general route-acceptance authority, pricing supervisor, commercial-dispute forum or market-access regulator; the test is whether it lowers proof cost without accumulating discretionary market power.
The filter job before the deal closes
The cutover plan looked ordinary. A European hosting group had bought a smaller network, moved a customer block into its migration calendar and asked its transit providers to refresh filters before traffic was shifted. The engineering team ran the usual job: query routing-registry sources, expand the customer AS-set, compare expected origins against live announcements, check RPKI status and stage the prefix list for approval. The result was not a clean yes or no. It was a stack of plausible but inconsistent evidence.
The RIPE Database showed a current prefix-origin record tied to the buyer's planned ASN. A mirrored IRR source still exposed an older origin used by the seller during a managed-service contract. A private filter file inside one upstream's provisioning system retained a legacy exception from years before the transaction. An old AS-set expansion pulled in a reseller path that nobody on the buyer's team recognised. A route server at an exchange accepted the new route in a test view, while a cloud platform's bring-your-own-IP review paused because its diligence tool saw the stale origin first. Nothing in this scene required malice. The cost came from disagreement among sources.
That is the question by which IRR database fragility should be judged: which routing-registry source can a market counterparty rely on, and who pays when stale or conflicting IRR evidence delays acceptance? The answer is not found by asking whether a single entry is valid in isolation. A prefix can be correctly recorded in the RIPE Database and still be doubted by a private filter that reads a mirror or a historical AS-set path. A third-party source can describe a once-valid routing relationship and still mislead a current buyer. A private exception can protect a network from risk and still act like an undisclosed toll on the next migration.
The Internet Routing Registry environment is often described as a set of operational databases, but that phrase understates its economic role. Routing-registry data is evidence used by people who must say yes or no under time pressure: upstream provisioning teams, exchange route-server maintainers, cloud onboarding desks, security reviewers, address brokers, M&A advisers, lenders and enterprise customers. The records do not transfer property. They do not command BGP. Yet they often decide whether a route is accepted without manual escalation. In an IPv4 market, that is enough to affect price.
RIPE NCC is central to this discussion because its service region combines dense routing infrastructure, large hosting and cloud markets, many legacy operating arrangements, sanctions and compliance overlays, active address transfers, cross-border acquisitions, and a long history of European network coordination through the RIPE Database. The RIPE Database is not merely a public directory. It is a routing-evidence source adjacent to the Internet number resource ledger. Its routing records, aut-num data, maintainers, AS-set entries and source labels are read by tools that turn database entries into filters.
But the market does not consume the RIPE Database alone. It consumes it through a supply chain: mirrors, local copies, source lists, recursive set expansion, private registries, provider-maintained files, route-server configurations, cloud review tools and old scripts that may have outlived the engineers who wrote them. The fragility sits in that supply chain. A clean ledger can be weakened by dirty copies. A current prefix-origin record can be offset by a stale AS-set. A provider's conservative source order can give practical power to an entry that no longer reflects the resource holder's plan.
The ideological line matters. RIPE NCC should not become a general route-acceptance authority, pricing supervisor, commercial-dispute forum or market-access regulator for scarce addresses. Its legitimacy comes from narrower work: reliable registration, clear source semantics, accountable update paths, evidence that lowers transaction cost, and service continuity. The proper institutional question is how to make routing evidence easier to trust without turning the registry into a discretionary choke point.
The RIPE Database is a ledger-adjacent source, not the whole market
Official RIPE Database documentation makes the institutional overlap explicit. Aut-num records carry registration details for AS numbers and also allow routing policies to be published. The documentation treats route and route6 records as core pieces of the RIPE Internet Routing Registry, with prefix and origin data used to describe interdomain routing. It also notes that authorisation can require both address-space and AS-number control when RIPE NCC-administered resources are involved. Those mechanics are narrow facts, but they explain why the RIPE Database has stronger evidentiary weight than a free-floating private entry.
The weight is not magic. A RIPE Database routing record proves that a statement has passed the relevant database rules and source semantics. It does not prove that every upstream will accept the route, that every private copy is current, that every old commercial arrangement has been cleaned, or that every AS-set path used by a filter builder points to the same story. The database is a ledger-adjacent source, not the whole routing market. That distinction is where many costly mistakes begin.
An address block in the RIPE NCC service region may have several lives. It has a registry life: who is recorded as holding or sponsoring the resource, which contacts exist, which status applies, and which contractual or policy conditions surround it. It has a routing-registry life: which prefix-origin records and AS-set entries are visible to operators. It has a cryptographic life through RPKI and ROAs where deployed. It has an observed BGP life in live route collectors. It has a commercial life in contracts, leases, transfers, outsourcing and cloud onboarding. It has a private-filter life inside networks whose acceptance rules are not public.
IRR fragility appears when those lives are treated as interchangeable. A routing-registry record is not a title deed. A ROA is not a customer-cone map. A live BGP announcement is not proof of current authority. A private filter exception is not a public registry statement. A third-party IRR entry may be useful evidence of a service relationship and still be weak evidence of current resource control. Each signal has competence. The market becomes fragile when tools flatten those signals into a single accept or reject decision without telling the affected holder why.
RIPE NCC's proper role is to keep its own signal crisp. The RIPE Database should make source identity, creation and modification history, maintainers, authorisation logic and routing-evidence boundaries as hard to misunderstand as possible. That does not require the registry to police every commercial route. It requires it to make the RIPE source more legible than its shadows. The closer a record sits to the number-resource ledger, the more clearly the market should understand what the record says and what it does not say.
The complication is RIPE-NONAUTH and other non-authoritative material. Such data can be operationally useful, especially where out-of-region AS numbers or historical routing relationships must be represented for routing-policy publication. Yet a non-authoritative source is not equivalent to current RIPE NCC resource authority. If a filter builder gives it equal rank without preserving that distinction, convenience becomes hidden power. If a network ignores it entirely, it may miss the evidence that a customer or provider actually used. The answer is not purity. It is labelled hierarchy.
Labelled hierarchy is a market good. A buyer can price cleanup risk when it knows which records are authoritative, which are non-authoritative, which are mirrored and which are private residues. A cloud platform can ask for specific remediation instead of pausing an account with a vague "IRR mismatch" notice. An exchange route server can publish a source policy that lets members test in advance. A small ISP can learn whether the problem sits in RIPE, in another IRR, in a mirror or in a private file. Uncertainty does not disappear, but it stops pretending to be certainty.
The point is not institutional deference to RIPE NCC. It is institutional economics. A registry earns trust by lowering the cost of reliance on scarce resources. If its own source is clear, markets can use it as an anchor while still respecting private routing autonomy. If its source is blurred by mirrors, duplicates and stale AS-set paths, private actors must adjudicate the mess. They will do so in ways that protect themselves first. That is rational, but it shifts cost onto whoever needs acceptance most urgently.
Mirrored data can make yesterday's routing story look current
Mirroring is a necessary convenience. Operators need resilient, fast and automated access to routing-registry data. RIPE NCC's documentation for near-real-time mirroring describes a public service through which users can receive streams of available RIPE Database data and later protocols built around snapshots, deltas, timestamps, source identifiers and integrity checks. Those details matter because they show that replicated registry data is not an informal scrape. It is part of the operating supply chain for the routing ecosystem.
The economic risk is that availability can be mistaken for freshness, and freshness can be mistaken for authority. A mirror that answers a query today may be reproducing a source whose claim is old, non-authoritative or superseded elsewhere. A private system that began as a mirror can later become a local database of exceptions. A carrier's filter builder can refresh daily while its source order still prefers a stale path. The query works; the data parses; the filter builds. The current holder then has to explain why the machine-readable answer is not the right answer.
This is the afterlife of routing evidence. A former upstream may have created a prefix-origin record during a valid customer relationship. The customer later changes provider, sells the address block, merges into a new group or moves to a cloud origin. RIPE-side records may be updated. ROAs may be adjusted. The former upstream may even delete its current entry. Yet a mirrored source, old export, third-party registry or private file can continue to feed a filter-generation path. The stale evidence is no longer authoritative, but it remains operational.
For a market counterparty, this creates an awkward incentive. The rejecting network may not care whether the old record is authoritative. It cares whether accepting the route increases risk, violates its source policy or breaks its automation. It will ask the holder to clean the record or produce proof. The holder may not control the source. The source may be a mirror. The mirror may not own the underlying record. The old provider may no longer have a commercial reason to help. The buyer of the address block pays for the investigation because it needs the route accepted.
Mirroring therefore turns data governance into a supply-chain question. When a supermarket sells old stock, the customer does not care that the factory corrected the recipe. In routing, a registry can correct a source while downstream systems continue consuming an older view. The analogy is imperfect because networks have legitimate autonomy, but the market cost is similar. The current holder must find the distributor of stale evidence and persuade it to stop shipping.
Source provenance should travel with the data. A routing-registry answer should preserve source, freshness, last-modified information where available, mirror status and enough context for a filter user to know whether it is reading RIPE, RIPE-NONAUTH, another IRR, a mirrored view or a local residue. If a mirror cannot preserve meaning, it should at least preserve warning. If a private filter file overwrites source context, it should be treated as a local risk policy, not as public evidence.
There is also a competitive issue. Large incumbents can run extensive source comparisons and maintain relationships with other networks. They can ask why a mirror is stale, persuade a peer to bypass a record, or file cleanup requests through contacts that small networks do not have. Smaller providers often see only the rejection. They may not know whether the failure is due to a mirror, a source preference, a stale AS-set member, a private route-set, an RPKI issue or a private exception rule. The same inconsistency imposes different costs depending on scale.
RIPE NCC cannot and should not command every mirror or private copy. It can, however, make the source chain easier to inspect. It can publish clear semantics, support tooling that shows RIPE-side state, make mirroring metadata robust, and signal when data is near-real-time rather than final. It can also resist the temptation to convert mirroring defects into broad regulatory authority. The narrow task is better information, not central routing permission.
AS-set expansion is where small errors multiply
AS-set entries are practical because networks are large. A transit provider does not want to hand-edit every downstream prefix. An exchange route server cannot negotiate bespoke policy for each member every morning. A cloud or DDoS platform cannot rely only on support emails when thousands of customer routes must be assessed. AS-set expansion turns published routing policy into generated filters. It lets a customer say, in effect, "these ASNs belong behind this policy," and lets the counterparty build a prefix list.
The same mechanism multiplies fragility. RIPE Database documentation describes AS-set entries as sets of AS numbers that may include direct members, references to other sets and indirect population through membership attributes. That is useful recursion. It is also a way for weak source choices to travel far. A filter builder asks for a customer's AS-set, expands it across selected sources, follows member references, maps ASNs to prefixes and emits configuration. A single stale member can affect many routes. A duplicate set name can produce different results at different providers. A cross-source reference can import an authority model the accepting network never meant to trust.
The user-facing ticket is usually bland: "AS-set not valid," "IRR mismatch," "prefix not in policy," or "customer cone inconsistent." Behind that message may be a deeper chain. The customer's set in RIPE may be current, but a similarly named set in another IRR may be found first. A provider-maintained set may still include an acquired ASN. A reseller set may pull in old customers. An indirect membership rule may admit an ASN because a maintainer relationship was never cleaned. A route-server tool may stop at a source boundary that the customer's internal test environment crossed. Each step is defensible locally. Together they produce surprise.
AS-set fragility matters especially during migration and acquisition. Corporate networks do not move as single clean blocks. They carry old upstreams, managed-service providers, reseller arrangements, DDoS scrubbing origins, cloud test origins, remote peering relationships, subsidiaries and decommissioned ASNs. An acquisition team may update the obvious prefix-origin records and still miss the AS-set path that a major transit provider uses. The first sign appears when a filter refresh rejects a route or removes a downstream that was supposed to remain reachable during transition.
This creates a due-diligence task that many financial advisers still underweight. IPv4 portfolios should be checked not only for registry status, transfer eligibility, abuse reputation and RPKI posture, but for AS-set exposure. Which sets include the seller's ASNs? Which sets include the prefixes by expansion? Are there provider-maintained entries that the seller cannot change alone? Do major counterparties use source-qualified set names? Do route servers and upstreams expand through all sources, preferred sources or local mirrors? Does the buyer's intended origin appear in the same evidence chain that the counterparty will actually query?
AS-set recursion also gives private filter operators quiet power. If a carrier's source order is hidden, its expansion result becomes a private market rule. If a cloud platform requires a particular AS-set structure but discloses only a generic rejection reason, it can delay onboarding without explaining the actual cure. If a dominant upstream maintains customer sets on behalf of small networks, those customers may become dependent on the upstream's registry hygiene. A tool meant to reduce transaction costs can become an administrative moat.
The cure is not to abolish AS-set use. That would increase manual work and reduce routing hygiene. The cure is path visibility. Filter builders should preserve expansion paths, source names, timestamps, duplicate names and conflict indicators. Route-server operators should publish how they treat cross-source recursion. Transit providers should tell customers whether a set name must be source-qualified. Buyers should require sellers to disclose known provider-maintained sets. RIPE NCC should make its own set entries and source semantics easy to inspect so that the RIPE source can act as a stable reference point.
This is also where the ledger/service-layer principle becomes practical. RIPE NCC does not need to decide every member of every customer cone. It does need to provide reliable base evidence that private filters can use without guessing. If the registry source is clean and the expansion path is visible, the market can place responsibility where it belongs: holder, provider, route server, mirror, private filter operator or buyer. If the path is hidden, the holder pays by default.
Conflict is a hierarchy problem, not a vote
When two routing-registry sources disagree, the easy but wrong habit is to treat the conflict as a vote. One source says AS A. Another says AS B. A third says nothing. A fourth includes the prefix through a set. A filter builder may prefer the first source in its local order. A support desk may ask the holder to remove the conflict. A buyer may discount the block. But source count is not authority. The market needs a hierarchy of competence, not a tally of claims.
The RIPE Database is strongest where it is closest to RIPE NCC-administered number resources and the authorisation logic of the database. It is weaker where it carries non-authoritative copies or routing-policy statements outside the direct resource ledger. A third-party IRR may be strong evidence of a customer-provider relationship and weak evidence of current resource control. A private filter file may be strong evidence of one network's risk rule and no evidence at all for public authority. A mirror is only as strong as its source, timestamp and integrity. RPKI is strong evidence for origin authorisation and weak evidence for AS-set membership.
Conflict handling should therefore ask: what is each source competent to prove? If current RIPE-side resource evidence, current ROA posture and current RIPE-source routing records align, a stale private or non-authoritative entry should not hold the market hostage without explanation. If a third-party IRR entry records an active customer relationship that the RIPE source does not capture, the relationship may deserve operational weight. If a mirror disagrees with its source, freshness is the issue. If an AS-set imports a stale member, the relevant question is not ownership of the prefix but maintenance of the set path.
This hierarchy would reduce false certainty. It would also reduce overreach. A registry should not use conflict as an excuse to decide every commercial relationship. A private network should not use conflict as an excuse to impose undisclosed proof burdens forever. A cloud platform should not demand cleanup of irrelevant historical residue if current authoritative and cryptographic evidence align. A buyer should not ignore non-authoritative records merely because they are not title-like. Each actor should carry the part of uncertainty it is best placed to control.
The current environment often does the opposite. The rejecting network controls the filter, so it controls the immediate outcome. The holder controls only some records. The old provider may control the stale source. The mirror controls the copy. The registry controls the ledger-adjacent source. The buyer needs the route. The party with the urgent business deadline pays the coordination bill, even when the cause lies elsewhere. That is the economics of fragmented evidence.
Clear rejection reasons are a low-cost remedy. "Rejected because source X contains prefix Y with origin Z" is very different from "IRR invalid." "AS-set expansion via source A included stale ASN B" is more useful than "policy mismatch." "RIPE source and ROA align, but our private file still contains a legacy exception" tells the provider what must be fixed internally. Such messages do not expose sensitive configuration if written carefully. They do turn a black box into a repairable system.
Markets price opacity harshly. An address block with unknown IRR conflicts receives a liquidity discount because the buyer cannot estimate cure time. A block with known, isolated external residue can be priced more accurately. A network with transparent filter rules is easier to integrate. A cloud platform with clear evidence requirements is less likely to trap customers in support queues. A registry with clear source semantics reduces the need for counterparties to invent their own authority model.
This hierarchy also protects small networks. Without it, the burden of proof becomes infinite. A small ISP can show current registry evidence, current ROAs and current routing records, only to be told that another source still disagrees. It may not be able to identify or remove that source. At some point, stale evidence must lose practical weight. A system that never lets current authority overcome old claims is not cautious; it is anti-liquid.
The price of being believed
IPv4 scarcity is what turns IRR fragility into a market problem. If address space were abundant, a dirty history could be avoided by renumbering, taking a different block or waiting for cleanup. Scarcity changes the calculus. A routable IPv4 block carries customer dependencies, reputation history, firewall allowlists, reverse DNS expectations, geolocation assumptions, cloud mappings, lender attention and transaction value. Its worth depends not merely on being registered, but on being believed by many independent systems.
Belief has a cost. A buyer needs confidence that the block can be announced by the planned ASN. A broker needs confidence that the asset will not stall after closing. A lender needs confidence that address-dependent revenue is not exposed to unexplained filter exceptions. A cloud platform needs confidence before it advertises customer space. A managed-service provider needs confidence that old customer routes can be separated from new ones. An exchange route server needs confidence that route propagation will not import risk for members. Each counterparty asks a different version of the same question: what evidence should I trust?
Stale AS-set expansion raises the cost because it hides old relationships inside automated filters. Conflicting prefix-origin records raise the cost because the holder must explain why one source is more reliable than another. Private mirrors raise the cost because the holder may not know they exist. Filter exceptions raise the cost because they replace standardized evidence with relationships and escalation. Migration failures raise the cost because customers experience operational delay, not database nuance. M&A delay raises the cost because closing mechanics and network acceptance move at different speeds. Lender haircuts raise the cost because ambiguity becomes a risk premium.
Address-market liquidity is especially sensitive to this kind of uncertainty. A buyer can value a clean /20 differently from a /20 that carries old IRR debris, even if both are recognised in the registry. The discount is not a judgment about ultimate rights. It is a discount for time, expertise and counterparty risk. If a buyer must spend weeks identifying stale entries, persuading former providers, testing source order at major networks and seeking manual exceptions, the block has less immediate productive value. In markets, delay is a price.
The burden falls unevenly. A large cloud provider buying or leasing space can maintain a team for routing diligence. A small access network cannot. A multinational carrier can push peers to examine source conflicts. A regional hosting firm may wait in a support queue. A well-known content network may receive an exception call. A new entrant may be told to fix "IRR" without further detail. The same data inconsistency thus reinforces existing scale advantages.
This is one reason fragmented IRR evidence can give incumbents hidden power. An incumbent with a broad private filter, old customer sets and established support channels can shape acceptance without saying so publicly. It can accept routes quickly for known customers and slow others through opaque source rules. It can keep provider-maintained entries that small customers depend on. It can make itself the easiest path through the proof maze. None of this requires a conspiracy. It is the predictable result of private systems filling gaps left by public evidence.
The policy trap is to respond with a demand that RIPE NCC take command of the whole market. That would be the wrong lesson. A registry with price-control or routing-permission powers would become a much larger target for capture, litigation and political pressure. It would also make commercial routing depend on discretionary administrative judgment. The better answer is to reduce the value of private ambiguity: clearer source labels, better provenance, visible freshness, conflict reports, low-cost holder tooling and public expectations around rejection reasons.
In institutional terms, RIPE NCC should help make being believed cheaper. It should not decide who deserves to route in a commercial sense. It should not supervise every transaction. It should not become the final arbiter of cloud onboarding or acquisition timing. It should make the registry-adjacent evidence reliable enough that private networks can make risk decisions without treating every inconsistency as a courtroom.
Private filters are market rules in disguise
Every large network has local policy. That is normal. BGP is decentralised, and each network has to protect its customers, peers and reputation. A route server may use one source list. A transit provider may use another. A cloud platform may combine registry data, ROAs, abuse history and customer documentation. A managed-security provider may require specific delegation evidence before originating a customer's prefix. These rules are not public law. Yet they often function as market rules because they decide whether an address block can be used in practice.
The problem is not private filtering itself. Private filtering is a necessary risk control. The problem is private filtering that consumes public and semi-public routing evidence but does not disclose enough to let holders cure defects. If an upstream rejects a route because a local copy still contains an old prefix-origin record, the holder needs to know that. If a route server fails because an AS-set expands through the wrong source, the member needs the expansion path. If a cloud platform pauses because a private dataset disagrees with RIPE and RPKI evidence, the customer needs to know whether the private dataset is authoritative, stale or merely conservative.
Opaque private filters create an insider economy. Networks that know the habits of major carriers can prepare. Brokers with engineering depth can pre-clean portfolios. Large customers can escalate. Smaller customers wait. The result is not simply unfairness; it is inefficient allocation of scarce addresses. Blocks flow toward actors that can manage proof rituals, not necessarily toward the actors that can use them most productively. Address markets then reward administrative sophistication as much as connectivity need.
There is a compliance dimension as well. The RIPE NCC service region spans countries with different legal, sanctions, corporate and telecommunications environments. Private networks may impose conservative controls for reasons that have little to do with IRR data alone. That is their right. But when a compliance pause is expressed as an IRR problem, the holder may chase the wrong cure. The distinction between routing evidence and other risk screening should be kept visible. Otherwise IRR fragility becomes a label for any private reluctance to accept a route.
M&A exposes the problem sharply. Corporate counsel can transfer shares or assets. Registry staff can update records. Engineers can create current prefix-origin records. Yet old filter files may sit inside upstreams, cloud platforms and security vendors. During a cutover, each private system becomes a veto point in practice, even though none claims formal authority. The acquirer may have paid for address-dependent revenue but receives a proof burden scattered across networks it does not control.
The efficient market response is a standard evidence pack. For a significant migration or acquisition, the pack should include current RIPE-side resource evidence, current routing-registry records, AS-set expansion reports with sources, known external IRR entries, known private-filter dependencies, ROA status, observed BGP history, planned cutover windows and a list of counterparties whose source rules matter. The pack should separate facts from permissions. It should say what RIPE records show, what RPKI authorises, what third-party sources still show, and what private acceptance remains unresolved.
This kind of pack is not bureaucracy for its own sake. It is a way to turn uncertainty into priced work. A seller can disclose known stale entries. A buyer can negotiate cleanup covenants or escrow. A lender can see whether ambiguity is narrow or systemic. A cloud provider can map required evidence to its policy. A route server can test before the maintenance window. The address block becomes more liquid because its evidence risks are named.
RIPE NCC can support that practice without becoming a transaction supervisor. It can publish guidance on source categories, explain how RIPE Database routing records and RPKI relate, provide examples of AS-set source qualification, and make holder-facing views easier to interpret. It can encourage, not compel, better private rejection messages. It can remain a ledger and service layer while markets build diligence around it.
RPKI improves the hierarchy but does not replace IRR
RPKI is the strongest improvement in the routing-evidence stack because it answers a precise question with cryptographic backing. RIPE NCC describes RPKI as a framework that lets resource holders obtain certificates listing their Internet number resources and supports BGP origin validation. ROAs allow a holder to authorise an ASN to originate a prefix within specified bounds. When validators classify an announcement as valid, invalid or not found, the signal is clearer than a loose third-party IRR record.
That clarity matters. A current ROA aligned with current registry evidence can reduce the power of old prefix-origin claims. A buyer can show that the new origin is authorised. A route server can drop invalid announcements. A cloud platform can use RPKI as a stronger origin check. Wider RPKI deployment reduces the space in which stale IRR records can masquerade as route-origin authority. It raises the evidentiary floor.
But RPKI does not replace IRR because it does not answer the same set of questions. A ROA authorises origin. It does not describe a customer cone, a transit relationship, an AS-set, a private route-server membership, a managed-service delegation, a reseller chain or a provider's filter source preference. A network building customer filters often needs more than origin validity. It wants to know which ASNs sit behind the customer, which prefixes are expected, and whether the customer's routing policy is consistent with what has been published. IRR data remains the language for much of that work.
The two systems also interact during change. A migration may require a new ROA, updated RIPE routing records, cleanup of third-party IRR entries, AS-set edits and temporary overlap between old and new origins. If the ROA is correct but an AS-set is stale, a filter may still reject. If the AS-set is correct but the ROA marks the route invalid, origin validation may reject. If both are correct but a private mirror is stale, onboarding may still pause. A robust cutover treats RPKI and IRR as complementary evidence, not substitutes.
There is a sequencing risk. Operators sometimes update the easiest signal first and assume the rest will follow. Creating a ROA may be easier than finding every old IRR entry. Editing a RIPE routing record may be easier than changing a provider-maintained AS-set. Updating an AS-set may be easier than changing a private filter file. Each partial fix can create a period in which evidence is mixed. During that window, different counterparties will see different truths because they rely on different source combinations.
The best hierarchy is explicit. Registry recognition and RIPE-side records show ledger-adjacent state and routing publication under RIPE Database rules. RPKI shows cryptographic origin authorisation. AS-set entries show policy grouping and customer-cone intent, subject to source and recursion limits. Other IRRs show additional routing claims, sometimes useful and sometimes stale. Private filters show local risk acceptance. Observed BGP shows what is being announced, not what should be accepted. A mature market keeps these layers separate and reconciles them deliberately.
RIPE NCC can help by presenting RPKI not as a public-relations victory over IRR, but as a stronger signal inside a wider evidence file. The institutional virtue of RPKI is precision. It should not become a pretext for neglecting routing-registry hygiene. Nor should IRR data be used to dilute a clear RPKI origin signal without explanation. Where RIPE-side evidence, ROA posture and observed routing align, stale non-authoritative IRR residue should be treated as a cleanup issue, not as an equal veto.
This approach also protects the registry from mandate creep. A cryptographic origin system does not turn RIPE NCC into a routing police force. It improves one layer of proof. The registry's job remains to keep the ledger and related evidence reliable, narrow and legible. The more precise each layer is, the less temptation there is for any single institution or private filter to claim total authority.
Small networks pay a regressive proof tax
IRR fragility imposes a fixed cost. Learning source semantics, maintaining AS-set entries, checking mirrors, coordinating ROAs, cleaning old third-party records and answering opaque support tickets take time whether the network is a multinational carrier or a small regional provider. The revenue base is not the same. A large platform can amortise the work across thousands of prefixes and customers. A small ISP may do almost the same proof work for a handful of blocks. That is a regressive proof tax.
The RIPE NCC service region includes major European carriers and cloud firms, but also small access networks, local hosting companies, universities, municipal networks, enterprise holders, Middle Eastern operators, Central Asian providers and specialist infrastructure firms. Many depend on sponsoring LIRs, contractors or upstreams for some registry and routing work. Some inherited old entries from providers. Some acquired networks without receiving complete AS-set histories. Some use legacy space. Some have limited leverage over international carriers whose filters they must satisfy.
For these networks, a stale external IRR entry is not an abstract inconsistency. It can delay a transit turn-up, block route-server acceptance, complicate a cloud migration, or force reliance on a more expensive provider that already knows the records. If a customer launch depends on the route, the small network may absorb service credits or reputational damage. If a lender asks about network assets, the operator may not have a clean evidence file. If a buyer sees unresolved routing evidence, the seller receives a lower price.
The fixed cost is worsened by language and expertise barriers. Routing-registry syntax is not ordinary business language. AS-set recursion is not obvious to finance teams. RPKI validation states are not familiar to many lawyers. Source order is often hidden. A small operator may know that it owns or lawfully uses a block, but not how to make that claim legible to a filter-generation system in another country. The market then mistakes administrative fluency for operational legitimacy.
This is where a registry service layer matters most. RIPE NCC should not subsidise every network's engineering department, but it can lower the fixed cost of proof. Holder views can show relevant RIPE-side routing records. Guidance can explain how AS-set entries and ROAs interact. Examples can show how source-qualified names reduce ambiguity. Transfer materials can warn that external IRR cleanup is separate from registry recognition. Public tooling can help identify when current RIPE evidence conflicts with common external sources. The aim is not to protect small networks from all responsibility. It is to prevent routine evidence work from becoming a barrier to market entry.
Private networks also have duties if they want the benefit of IRR-derived filtering. Route servers can publish source policies and give actionable rejection messages. Transit providers can expose expansion paths in customer portals. Cloud platforms can distinguish old non-authoritative residue from current RIPE and RPKI evidence. Brokers can include routing-registry diligence in transfer packages rather than treating it as a post-closing surprise. Each duty is modest. Together they reduce the proof tax.
The alternative is a market in which hidden expertise becomes capital. Firms that understand private filters acquire address blocks more cheaply, clean them faster and resell them at a premium. Dominant carriers keep customers dependent by maintaining the registry machinery on their behalf. Small networks avoid transfers because cleanup feels unpredictable. Address scarcity then rewards those closest to the evidence infrastructure, not those with the highest productive use. That is a poor outcome for competition and for Internet resilience.
Small-network burden also sharpens the mandate boundary. If RIPE NCC responds by becoming a central permission authority, small networks may gain a clearer path but lose autonomy to administrative discretion. If it responds by doing too little, private filter operators become the default market arbiters. The better answer is reliable, low-cost evidence. Make the source clear; make the path visible; make cleanup understandable; leave routing choices to networks.
Cleanup accountability should follow control
The hardest IRR disputes often begin with a simple question: who can fix the stale record? The current holder may control the RIPE-side entry but not a third-party IRR. The old upstream may control the provider-maintained entry but have no current commercial incentive. The mirror operator may only replicate. The accepting network may only consume. The buyer may need the route accepted but control none of the stale evidence. Accountability is scattered.
Cleanup should follow control. A holder should maintain records it controls, keep ROAs current and disclose known external dependencies during transactions. A provider that created records for a customer should remove or transfer them when the relationship ends, unless a documented transition requires temporary overlap. A mirror operator should preserve source and freshness metadata. A route-server operator should identify the source of rejection. A private filter operator should retire local exceptions that no longer reflect current policy. A registry should make its own source and correction path reliable.
This division sounds obvious, but markets fail when it is not written down. Former providers may treat old entries as harmless. They are not harmless if a new counterparty consumes them. Buyers may assume registry transfer completes routing acceptance. It does not. Route servers may assume members understand source rules. Often they do not. Mirrors may assume downstream users will infer limits. Many tools strip context. Each assumption shifts cost to the party under deadline.
Contracts can help. IPv4 transfer and acquisition agreements should include routing-evidence schedules where operational continuity matters. Sellers should disclose known IRR entries, AS-set memberships, provider-maintained records, ROA status and major filter dependencies. Buyers should specify intended origins and acceptance milestones. Escrow can distinguish registry recognition from operational readiness at named counterparties. Providers can commit to removing customer records after service termination. None of this changes who holds a resource in the registry. It clarifies who must clean which evidence.
The registry can support, not enforce, this market discipline. RIPE NCC can provide checklist language, not legal advice. It can explain that the RIPE Database source is not the same as every mirrored or private source. It can make historical and current RIPE-side data easier to compare. It can expose enough record history to support audit without turning every cleanup into a public dispute. It can keep forceful administrative tools narrow and procedural. It should avoid acting as the forum of first resort for stale entries outside its control.
Cleanup also needs a time dimension. Some old evidence is legitimate during migration. A seller may need to keep the old origin live while customers move. A DDoS provider may need temporary origin authorisation. A cloud platform may stage an announcement before final cutover. The problem is not overlap; it is unbounded overlap. Records and AS-set memberships that exist for transition should have owners, dates and retirement criteria. Otherwise temporary evidence becomes permanent ambiguity.
The market would benefit from a standard cleanup vocabulary. "Current RIPE source aligned." "External IRR residue known." "Provider-maintained AS-set pending removal." "Mirror lag suspected." "Private filter exception confirmed." "ROA transition window active." Such labels are not glamorous, but they are how a fragmented evidence market becomes manageable. They turn a vague routing problem into a set of tasks.
Accountability following control also limits private leverage. A former provider should not be able to impose a market discount indefinitely by leaving stale data behind. A buyer should not demand that a seller cure records the seller never controlled without pricing that burden explicitly. A route server should not reject silently when it can identify the source. A registry should not be blamed for every stale private copy. Each actor's duty should match its control.
What RIPE NCC can do while staying bounded
RIPE NCC's constructive path is narrow but important. It should not decide which commercial routes the Internet must accept. It should not set prices for IPv4 assets, supervise leasing contracts, police every cloud onboarding case or adjudicate all stale third-party records. Its authority is strongest when it acts as a reliable ledger and evidence service layer. IRR fragility needs precisely that kind of institution: boring, procedural, legible and resistant to discretionary expansion.
First, RIPE NCC can improve source clarity. RIPE, RIPE-NONAUTH, mirrored data and other source categories should remain distinct in ways humans and tools can preserve. Source labels should not be lost when data moves into mirrors, exports or holder-facing views. If a record is non-authoritative for a resource, that fact should be visible. If a record is mirrored, the copy should not look like an original claim. If an entry is old, freshness should be easy to inspect. This is not policy drama; it is market plumbing.
Second, it can improve conflict visibility. A holder should be able to see when RIPE-side routing evidence conflicts with common external IRR signals or when a current prefix-origin record is likely to be contradicted by old source paths. RIPE NCC does not need to certify every external database to provide useful warnings. Even a limited view that says "your RIPE evidence may not be the only evidence filters read" would improve transfer diligence and onboarding.
Third, it can strengthen AS-set guidance. Operators need plain examples of source-qualified set use, recursive expansion risks, indirect membership, duplicate names and transition cleanup. The guidance should be operational rather than moralistic. AS-set entries are not bad. Cross-source recursion is not automatically wrong. The danger is unlabelled reliance. RIPE NCC can teach the market how to make AS-set paths inspectable without prescribing every filter policy.
Fourth, it can connect RPKI and IRR guidance without merging them conceptually. A clean evidence file should show current registry status, relevant RIPE routing records, AS-set posture, ROA status and known external residue. Operators should know what RPKI proves and what it does not. Holders should know that a valid ROA may not cure stale AS-set expansion. Filter builders should know that old IRR evidence should not be treated as an equal veto when current RIPE and RPKI signals align, unless there is a specific reason.
Fifth, it can keep cleanup tools procedural and narrow. Where RIPE-side records are stale or controlled by maintainers that no longer represent current authority, correction paths should be clear, auditable and proportionate. The registry should protect against abuse without turning routine cleanup into litigation. It should record and expose process enough to support trust, not enough to make every route a public trial.
Sixth, RIPE NCC can convene without commanding. It can encourage route servers, transit providers, cloud platforms and major filter-tool maintainers to publish source-handling practices. It can support best-practice documents that ask for actionable rejection reasons. It can help normalise evidence packs for transfers and acquisitions. Convening is useful because the problem spans many private systems. Command would be dangerous because routing autonomy is part of the Internet's architecture.
The final test is whether RIPE NCC lowers proof cost. A holder should find it easier to show current authority. A buyer should find it easier to identify residue. A route server should find it easier to explain rejection. A small network should find it easier to fix routine errors. A cloud platform should find it easier to distinguish stale routing-registry evidence from current authorisation. If those costs fall, the market becomes more liquid without giving the registry a new gate.
A reliable ledger and bounded evidence service
IRR database fragility is often described in technical language: sources, RPSL, AS-set expansion, mirrors, origin ASNs, filters, ROAs. The technical vocabulary is necessary, but the underlying issue is institutional. Scarce number resources need a low-cost way to be believed. Routing-registry records were created to make routing policy legible. In a fragmented environment, they can instead force every counterparty to decide which institution, source, copy or private file counts.
RIPE NCC's position is delicate because it sits near the ledger and near the routing evidence, but it is not the Internet's route acceptance authority. If it is too passive, stale private sources and opaque filters can allocate practical power over resources in its service region. If it is too assertive, it becomes a market-access authority and increases the political value of controlling the registry. The right posture is ledger discipline: make authoritative state clear, preserve source identity, improve freshness, expose conflicts, support cleanup and keep institutional ambition narrow.
The market will still be plural. Private networks will still choose their filters. Cloud platforms will still have risk rules. IXPs will still protect members. Third-party IRRs will still exist. Mirrors will still be used. RPKI will continue to grow without answering every policy question. That plurality is not a failure. It becomes a failure only when the costs are hidden and the weakest counterparty pays by default.
The next address deal that stalls on an old AS-set will not be solved by theory. It will be solved by knowing which source produced the stale path, who controls it, whether RIPE-side evidence and ROAs align, which private filter consumed the residue, and what cleanup task remains. That is what a functioning evidence market looks like: not perfect certainty, but traceable responsibility.
RIPE NCC should be judged by whether it makes that traceability easier. The registry should not turn narrow evidence work into route acceptance control, price regulation or broad commercial adjudication. It should be a dependable ledger and service layer whose records help markets settle routine trust questions without drama. In the economics of IRR fragility, that modest ambition is not small. It is the condition for liquidity.