AFRINIC and the economics of IRR database fragility

When several registries answer the same route

The route-server job runs before dawn because the exchange wants its filters ready before the business day begins. It pulls from several Internet Routing Registry sources, refreshes mirrored data, expands member AS-SETs, builds prefix lists and origin checks, and emits configuration that will decide which announcements the exchange passes. Most mornings are uneventful. This morning the job stops on an AFRINIC-administered IPv4 prefix whose story changes depending on which source is asked.

One IRR source has a route object for the prefix with an origin AS that belongs to a former upstream. Another has a newer object for a customer network that says it has moved to a regional data centre. A third source mirrors an older entry that still appears plausible because the maintainer name resembles the resource holder. An AS-SET supplied by the customer expands differently depending on the source order. In one expansion the prefix is covered through a reseller's customer cone. In another it disappears because a route-set references an AS-SET that exists in a different repository. A public RPKI check helps with part of the question but does not explain why the IRR views disagree or which operational relationship is current. The exchange engineer can reject the route, accept it, make a manual exception, ask for letters, or delay the ticket. None of those choices is free.

That is the practical scene behind Internet Routing Registry fragility. The problem is not only that a single route object may be wrong, stale or hard to correct. The broader problem is that routing policy data is distributed across multiple repositories with different histories, update rules, authentication practices, mirror schedules, cleanup habits and social reputations. A carrier or IXP rarely consumes "the IRR" as a single database. It consumes a selected set of sources, in a selected order, through tooling that makes assumptions about duplicates, recursion, route-set membership and source preference. When those assumptions collide with conflicting records, database design becomes an economic event.

The affected parties are wider than network engineers. A transit provider needs to know which source to trust before provisioning. A cloud provider needs confidence before advertising customer space. An IXP route server needs filters that protect participants without excluding legitimate local networks. A broker must explain why stale IRR records will not depress price or delay transfer. A buyer, lender or insurer needs to know whether operational acceptance will survive due diligence. A customer buying connectivity does not care about RPSL syntax, but it will feel the cost if routes are not accepted quickly.

AFRINIC is the useful stress test because its institutional environment makes the hidden cost visible. The region has faced a long governance crisis, litigation, receivership questions, election turbulence and public concern about the integrity of historical address records. IPv4 scarcity has made each routable block more economically consequential. In that setting, registry-adjacent routing data is not a clerical appendix. It becomes part of the market's reliance infrastructure. If the data is coherent, third parties can say yes at lower cost. If it is fragmented, every participant must decide how much legal, operational and reputational risk to absorb.

The right frame is not institutional loyalty. It is not that AFRINIC, or any other RIR, should be trusted because it claims a community mandate. Nor is it that private IRRs should be trusted because operators have used them for years. The question is harder: when several databases give plausible but contradictory answers about the routing policy around a scarce number resource, which answer should an upstream, exchange, cloud platform, broker, buyer, lender or customer rely on, and who pays when the answer is wrong?

RPSL made routing policy legible, not self-validating

The Internet Routing Registry system grew out of a reasonable operational need. BGP allows networks to announce routes, but it does not, by itself, provide a complete public explanation of what a network intends to originate, transit or accept. Routing policy is too important to be left only in private router configurations and e-mail threads. RPSL, defined in RFC 2622, gave operators a structured language for expressing that policy. It includes objects such as route, route6, aut-num, as-set, route-set and mntner. These are not legal instruments. They are database objects designed so that routing relationships can be described in a form software can query.

That distinction is often the first casualty of automation. A route object associates a prefix with an origin autonomous system. A route6 object, described in the multiprotocol extension of RFC 4012, performs the comparable role for IPv6. A mntner object identifies the maintainer that can authenticate changes to other objects. AS-SETs and route-sets allow operators to describe collections of networks or routes, often recursively. From these pieces, a network can generate filters for a customer or peer. The syntax is narrow, but the consequences are wide because the output becomes router policy.

The early promise was coordination. If operators published their intended routing policies in public or semi-public registries, other operators could make safer decisions. Filters could be generated instead of hand-built. Changes could be reviewed against a visible policy model. Mistakes would be easier to detect. Internet-wide coordination would have a common grammar. RFC 2725, written as security concerns around IRR grew, captured the shift: as IRR data became more useful for operations, its integrity and security requirements became stronger. A loosely maintained coordination database is one thing. A database that feeds filters is another.

RPSL did not make the data self-validating. It made the data legible. That difference matters in every fragmented IRR dispute. If a route object exists in a repository, the object can be parsed. It can be mirrored. It can be matched against an announcement. It can be pulled into a prefix list. But the existence of the object does not prove that the resource holder authorised it, that the origin AS is still current, that the maintainer still represents the relevant party, that a duplicate elsewhere is false, or that a route-set expansion across sources reflects present commercial relationships. The format makes a claim machine-readable. It does not make the claim true.

That limitation once mattered less because the stakes were lower and the operational culture was more relationship-driven. The modern market is less forgiving. IPv4 is scarce; automation is deeper; cloud onboarding, route servers, managed security services, remote peering and address transfers all depend on repeatable external evidence. A record that once helped engineers coordinate now influences whether capital, connectivity and customer relationships can move.

The institutional lesson is simple but uncomfortable. A registry database that affects filters cannot be governed as if it were only a convenient noticeboard. Yet it also should not be converted into a broad discretionary control point over market activity. The database's legitimacy comes from the narrowness and reliability of its ledger function. It should record, authenticate and expose operational declarations in ways that reduce uncertainty. It should not pretend that every routing-policy entry is a property judgment, a community plebiscite or an instrument of institutional sovereignty.

That is why fragmentation is so costly. If the same RPSL vocabulary appears in many repositories, each with a different authority model, then the market receives statements that look comparable but rest on different foundations. The route object in one source may be tied closely to an RIR holder record. The route object in another may have been created by a network operator years ago under a less restrictive maintainer practice. A mirrored object may lag the source or preserve a deleted view. A route-set may refer to objects that exist only if the tool queries the right repositories. The common grammar masks the institutional difference underneath.

Fragmentation turns a coordination tool into a market toll

Fragmentation is sometimes described as an annoyance for filter tooling. That is too mild. In a scarce-address market, fragmented IRR data is a toll system. It charges every party that must investigate, explain, reconcile, override, document or insure around contradictory records. The toll is not paid to a single collector. It is paid in labour, delay, risk discounts, failed onboarding, blocked peering, manual exceptions, legal review and mistrust between counterparties.

The first cost is search. An operator cannot simply ask whether a prefix has an IRR object. It must ask which sources its policy recognises, whether those sources are authoritative for the resource region, whether mirrored copies are current, whether duplicates should be collapsed or treated as conflict, and whether an object in a private or non-RIR source should be allowed to override a missing or stale entry in an RIR-linked source. A small network sees only a ticket. A large carrier sees a ruleset. Between the two sits a transaction cost that often decides whether the small network gets service quickly.

The second cost is explanation. When a customer says, "the route object is there", the upstream must ask where. If the object is in RADB but not in the relevant RIR IRR, is that enough? If it is in an AFRINIC source but a duplicate in another source points to a different origin, which object wins? If the customer has an AS-SET that expands through several repositories, does the upstream accept all sources or only those on a preferred list? If the customer's previous provider created objects in its own maintainer, must the customer delete them before a new provider will accept the route? Each question is reasonable. Together they make connectivity feel like litigation by another name.

The third cost is asymmetric competence. Large operators can maintain registry teams, build source-specific policies, run regular stale-object checks, monitor filter differences and know whom to contact. Smaller African ISPs, universities, public agencies and enterprises may not have that capacity. They may inherit old records from contractors. They may rely on upstreams to create objects. They may not know that a duplicate in a distant IRR will affect a route server in a different market. Fragmentation therefore favours actors with enough scale to manage ambiguity. It punishes those for whom Internet reachability should be ordinary infrastructure.

The fourth cost is bargaining power. If a buyer of IPv4 space discovers that the block has conflicting IRR entries, it may demand a discount or escrow holdback. If a lender sees that a borrower's address-dependent service depends on manual exceptions at carriers, it may treat the asset as less reliable collateral. If a cloud provider requires cleanup before onboarding, the holder may lose migration time or negotiate from weakness. Fragmented records do not have to be malicious to change price. They only have to make the asset harder to rely on.

The fifth cost is security. Stale duplicates can preserve old origin claims. Weakly authenticated sources can give apparent legitimacy to routes that should be challenged. Over-broad AS-SETs can pull in downstreams that no longer belong. Mirror lag can make a corrected record appear unresolved. If operators react by ignoring IRR data altogether, they lose a useful defensive layer. If they react by trusting every source indiscriminately, they widen the attack surface. If they react by trusting only a narrow source list, legitimate networks with incomplete records may be excluded. Fragmentation forces security policy into a choice among imperfect harms.

The sixth cost is institutional trust. In a stable registry environment, operators tolerate some mess because they know how correction works. Under stress, each ambiguity is read more darkly: stale object, weak record control, clerical gap, holder lockout, or bypass of the regional ledger? AFRINIC's recent history makes those questions harder to dismiss. The data problem becomes a governance problem because third parties do not separate databases from the institutions that maintain or fail to maintain them.

Fragmentation therefore changes the economic meaning of an IRR record. In a unified and well-governed environment, the record lowers the cost of routing trust. In a fragmented environment, the record can shift the cost outward. The route server, upstream, cloud platform, broker and buyer become unpaid adjudicators of database conflict. They are not well placed to do that job, but the routing system gives them no escape. Packets need a decision.

Source selection is an economic decision disguised as engineering

RFC 7454, the BGP Operations and Security document, treats source selection as a practical concern for operators. It discusses prefix filtering, customer filters derived from routing registries, AS-SET recursion, the need to refresh filters and the difficulty of choosing which IRR sources to use. The text is operational, but the economic implication is large: a source-selection rule is a trust policy. It decides which database claims are cheap enough to rely on and which claims require manual escalation or rejection.

Consider a carrier that accepts AFRINIC, RIPE, APNIC, ARIN and RADB objects when building filters. That policy maximises inclusiveness. It reduces support tickets from customers whose data lives in older or non-regional sources. It also increases exposure to stale duplicates, weaker authorisation histories and cross-source recursion surprises. Now consider a carrier that prefers only the relevant RIR source for each prefix and ignores private IRRs where an RIR IRR exists. That policy may improve authority alignment, but it can break legitimate customers whose records were historically maintained elsewhere or whose provider-created objects live outside the regional source. A third carrier may use a source preference order, accepting the first matching object. That rule is efficient until the preferred source is stale and a less preferred source is current.

These choices look technical because they are encoded in scripts. They are economic because they allocate the cost of uncertainty. A strict source policy makes customers clean their records before receiving service. That may improve the database, but it shifts labour to the customer and may exclude smaller networks. A loose policy gets routes accepted faster, but it shifts risk to the carrier's network and its peers. A manual-exception policy preserves flexibility, but it creates insider advantage and support bottlenecks. There is no neutral source policy. There are only different ways to allocate cost.

For AFRINIC-administered prefixes, source selection is unusually sensitive because the region's records may carry multiple histories at once. A prefix may have an old route object in a commercial IRR because an upstream created it long before the holder used AFRINIC's own IRR tools. It may have an AFRINIC-linked object created during a later cleanup. It may have route-set references that assume RIPE-style tooling because a European transit provider maintained the customer's policy. It may have private IRR entries used by a cloud or DDoS provider. Each source can be plausible from the perspective of the party that created it. Plausibility is not the same as current authority.

Conflicting source preference also affects competition among providers. If a dominant upstream's policy accepts a broader set of sources, it may onboard customers more quickly than a smaller provider with stricter filters. If a cloud platform demands one kind of cleanup and a transit provider demands another, the customer may choose the path of least administrative friction rather than the best technical service. If an IXP route server uses conservative source rules, members with messy records may avoid multilateral peering and remain dependent on transit. Database policy then shapes market structure indirectly.

Source selection can also become a hidden form of jurisdictional choice. A route object for an AFRINIC-administered prefix in a non-AFRINIC repository may be easier to create or preserve than one tied to AFRINIC holder records. An operator that accepts that object is not formally transferring authority away from AFRINIC, but it is deciding that a non-AFRINIC source can support operational reliance. In normal cases that may be harmless. In contested cases it matters. The market may route according to the database that is easiest to use, not the database that best reflects the resource ledger.

The solution is not to demand one universal source list. Operators have different risk tolerances, customer bases and legal environments. The solution is transparency and narrower expectations. Carriers and route-server operators should publish how they use sources, how they handle duplicates, how often they refresh mirrors, how they treat conflicts between RIR and non-RIR data, and what evidence is needed for exceptions. Registries should publish enough metadata to let operators distinguish source authority rather than guessing. Customers should be able to learn in advance whether their IRR posture will pass a given network's filters. A hidden source-selection rule is a hidden market rule.

In AFRINIC's case, the institutional priority should be to make the AFRINIC-linked source predictable enough that operators have less reason to shop across databases for the answer they prefer. That does not mean making AFRINIC a market governor. It means strengthening the ledger function so that the regional source becomes a low-cost reference point. Protect the ledger, not the gatekeeper: the registry's value lies in making reliance cheaper, not in turning source preference into discretionary power.

Mirror lag and stale duplicates create false continuity

IRR data often travels through mirrors. Mirroring is useful because operators need local, fast and resilient access to registry information. It also creates a new class of fragility. A mirror can lag behind the authoritative source. It can preserve a view after a correction. It can fail silently. It can update one source while another remains stale. It can give automation the impression that a record still exists or still has a certain origin when the underlying repository has moved on.

Mirror lag is easy to underestimate because most lag is harmless. If a filter refresh is a few hours behind a routine route-set update, nothing dramatic happens. The problem is not average delay. It is delay during contested or economically meaningful changes. A holder deletes a stale object after leaving a former provider. The old provider's route-set still references the object through a mirror. An IXP route server refreshes from a lagging copy and continues to accept a route that the holder believes has been withdrawn. Or a customer creates a new object for a migration, but the transit provider's chosen mirror has not caught up, so the ticket stalls. The difference between a current and stale view becomes a business interruption.

Stale duplicates are more durable than mirror lag. A duplicate object can remain in another source long after the original commercial relationship ended. The former upstream may have created it for a customer and never cleaned it up. The customer may not know it exists. The maintainer may be unreachable. The source may have weak incentives to remove it because the object is not tied to that source's resource ledger. Years later, automated filters still see a plausible prefix-origin claim. If the current holder wants to move providers, it may have to explain why the old object should not govern acceptance. If a bad actor wants cover, the old object may provide just enough ambiguity to slow rejection.

False continuity is the economic danger. A stale object makes a past relationship look present. A mirrored object makes a corrected view look unresolved. A recursive AS-SET that includes an old downstream makes a former customer look like part of the current cone. The database does not need to say "this is authoritative". It only needs to be consumed by enough tools to create reliance. In a market where speed matters, apparent continuity is valuable. It lets a party say, "the data has always looked this way", even when the data's survival is a housekeeping failure.

AFRINIC's context increases the price of false continuity. Historical record-integrity concerns mean that dormant or stale data is not merely clutter. It can become an evidentiary shadow around scarce IPv4 space. A buyer reviewing an AFRINIC-region block may ask whether old IRR objects survive in non-regional sources. A cloud provider may ask whether a previous origin still appears anywhere it consumes. A broker may need to clear old route-set references before closing. An upstream may refuse to accept a new origin until the old one is removed. Each step is rational, but together they turn fragmented database cleanup into a market precondition.

Stale duplicates also create perverse incentives. A party that benefits from ambiguity may have little reason to remove old data. A former provider may not prioritise cleanup for a lost customer. A reseller may prefer broad AS-SETs because they make onboarding easier. A weak source may prefer volume and convenience over rigorous authority checks. A strict source may remove records but have no power over copies elsewhere. The result is a negative externality: the cost of stale data is borne by the current holder, the new provider and the networks that must filter safely, not necessarily by the party that left the stale record behind.

The practical response should be lifecycle discipline. Records used for routing filters need timestamps, source provenance, deletion visibility, mirroring status and conflict indicators that tools can understand. Operators need stale-object reports that show when a prefix-origin pair appears in multiple sources with different origins or maintainers. Registries and major IRR operators should make cleanup easier for holders who can show current authority, while preserving enough audit history to prevent stealth rewriting. Route-server software should expose conflicts rather than hiding them behind first-match rules. None of this requires turning IRR into a property court. It requires admitting that stale data is not neutral when filters consume it.

There is a cultural point as well. Engineers often tolerate untidy registries because the Internet has always run on a mixture of formal data and informal workarounds. That tolerance was useful in a growing network. It is less useful when scarce IPv4 blocks, cloud onboarding and financial diligence depend on records that outsiders cannot easily interpret. In that environment, a stale duplicate is not just an old object. It is a claim on someone else's cost of trust.

Authentication without authorization does not settle trust

IRR security discussions often begin with authentication. Did the user control the maintainer credential? Was the password, PGP key, portal account or other method valid? Was the update submitted through the proper channel? Those questions matter. A database that cannot authenticate updates is not reliable enough for filter generation. But authentication is not authorization. RFC 2725 drew attention to that separation more than two decades ago, and the distinction remains central to fragmented IRR economics.

Authentication proves control of a credential. Authorization asks whether the credential holder had the right to make this particular routing-policy statement for this particular resource at this particular time. A former contractor may still control a maintainer. A transit provider may have been authorised to create a route object for a customer during service but not to preserve it after termination. A reseller may have authority to include a downstream in an AS-SET for one product but not to authorise a new origin AS. A corporate mailbox may exist after the employee who used it has left. A registry account may be technically valid while the underlying corporate authority is contested. Strong login controls reduce impersonation; they do not answer mandate.

Fragmentation multiplies the problem because each source may draw the authentication-authorization line differently. One repository may tie route-object creation closely to a resource holder or a hierarchical authorisation model. Another may allow creation based on maintainer control and origin-AS confirmation. A third may preserve old objects under legacy practices. A fourth may allow provider maintainers to create customer objects for operational convenience. When filters consume all of them as comparable RPSL data, the market loses sight of the different authority assumptions behind the records.

For AFRINIC-region prefixes, the distinction is not theoretical. Governance stress, litigation and record-integrity concerns make mandate questions more likely to arise. Who may act for a company in receivership, liquidation or board dispute? Who may update records during a court-supervised period? What happens when a historical allocation is tied to a public institution whose current network operations have been outsourced? How should a registry or operator treat a maintainer controlled by a service provider that no longer has the customer? These are authorization questions. A valid maintainer password cannot answer them alone.

The economics of this distinction are severe because markets like credentials. Credentials are fast. They fit into software. They allow tickets to close. Authorization is slower. It involves contracts, letters, corporate authority, registry records, historical context and sometimes law. A market under pressure will be tempted to accept authentication as a substitute for authorization because delay is expensive. That temptation creates an attack surface for whoever can preserve or obtain credentials without current authority. It also creates a barrier for legitimate holders who lack old credentials but can prove current entitlement.

The reverse error is also costly. If every IRR update requires full re-proof of resource authority, routine routing changes become too expensive. Small operators will avoid updating records. Providers will keep broad AS-SETs to reduce friction. Customers will rely on private letters and manual exceptions. Filters will become less accurate because the cost of accurate publication is too high. The objective is not maximal documentation. It is proportional authorization: more evidence for changes that alter risk or economic meaning, less friction for stable routine maintenance, fast correction where stale authority is evident, and clear notice where parties may be affected.

In practice, this means IRR sources should expose authority context, not only object content. A route object created under direct resource-holder authentication should be distinguishable from one created by a provider maintainer. A record tied to origin-AS confirmation should be distinguishable from a historical legacy object. A disputed or recently corrected object should carry status visible enough for operators to treat it carefully. Private evidence need not be published. But the database should not force every downstream user to infer authority from object syntax and maintainer names.

This is where the principle of narrow continuity matters. Registries should act as continuity utilities, not discretionary governors of every market use. They should keep the ledger reliable enough that third parties can interpret operational declarations. They should resist mandate laundering, where a broad invocation of community or stewardship turns technical coordination into institutional control over commercial outcomes. But they should also resist the opposite failure, where weak authentication hygiene allows old credentials and fragmented sources to govern present reachability. A narrow utility still needs strong procedure. It just uses procedure to protect reliance, not to accumulate discretionary power.

AS-SET recursion makes small errors travel far

AS-SETs are one of the most useful and dangerous parts of the IRR ecosystem. They allow a network to publish a set of ASNs that should be treated as part of its customer cone or routing policy. A transit provider can ask a customer for an AS-SET, expand it recursively, find the ASNs inside, then build filters for prefixes associated with those ASNs. Without this machinery, customer filter maintenance would be far more manual. With it, a single route-server or carrier can process many routing relationships automatically.

The danger is recursion. An AS-SET can include other AS-SETs. Those AS-SETs can live in different sources. They can include stale customer ASNs, downstream resellers, route-sets, or objects maintained under different authority standards. Expansion can be source-dependent. A tool that searches all sources may produce a larger set than a tool that restricts to preferred sources. A tool that stops at the first match may treat one database as decisive. A tool that fails closed may reject legitimate customers. A tool that fails open may accept routes through a chain nobody has recently audited. RFC 7454's caution about AS-SET recursion and IRR-derived filters is not an academic footnote. It is the operational point at which database fragmentation becomes router configuration.

In an AFRINIC-region case, the recursion problem can be disguised by ordinary commercial layering. A small ISP buys transit from a regional carrier. The carrier's AS-SET includes a reseller. The reseller includes customer ASNs. Some of those customers have prefixes from AFRINIC, some from other regions, some leased or delegated, some moved to cloud or DDoS providers. The objects were created over many years by different maintainers. When an IXP route server expands the top-level AS-SET, it may import a whole history of commercial relationships, not merely the current policy of the member. If the expansion is too broad, stale customers may remain routable. If it is too narrow, legitimate downstreams may vanish.

The economic effect is scale. A single stale route object affects one prefix-origin claim. A stale AS-SET member can affect many prefixes. A broad route-set can affect all prefixes associated with several ASNs. A recursive object in a trusted source can import less trusted data from another source. The error's radius grows with each layer of indirection. That makes AS-SET hygiene a market issue. The cost of an inaccurate set is borne not only by the maintainer, but by every upstream, route server, customer and peer that depends on its expansion.

Recursion also creates opacity. A customer may not know why an upstream's filter includes or excludes a route. The answer may be buried in a source-selection rule several levels deep. The support ticket may say "IRR mismatch" when the real issue is that the customer's AS is missing from a downstream set, or that a duplicate AS-SET in another source is being preferred, or that an old reseller entry is still expanding. The parties argue about the visible prefix while the cause sits in a hidden chain of RPSL objects.

For cloud providers and large content networks, the AS-SET problem intersects with onboarding scale. They need to verify many customers and avoid becoming origin points for questionable space. Strict AS-SET handling reduces abuse risk but increases customer friction. Loose handling improves onboarding speed but can import stale or overbroad policy. For brokers and buyers, AS-SET sprawl is due diligence noise. A block may look clean in holder records but appear in route-sets associated with old providers, resellers or customers. Before money moves, someone must determine whether those references are operationally meaningful, stale, or harmful.

The right policy is not to abandon AS-SETs. They remain practical and widely used. The policy is to treat recursive expansion as a reliance chain with visible weak links. Tools should report source paths, duplicate set names, cross-source references, expansion age, unusual growth and conflicts with known holder or origin data. Operators should avoid accepting arbitrary recursion across all sources without considering authority. Registries should help holders find where their prefixes and ASNs appear in sets they do not control. Major IXPs and carriers should publish how they handle cross-source recursion. The more a market relies on automation, the more automation must explain its assumptions.

For AFRINIC, AS-SET recursion has a regional-development dimension. Local peering and regional transit become cheaper when filters can be built predictably. If small networks cannot make their AS-SETs work across exchanges and upstreams, they may remain dependent on a few providers that already understand the rituals. If stale or overbroad sets create security concerns, route-server operators may tighten rules in ways that exclude the same small networks. Good AS-SET governance is therefore not only a security convenience. It is part of lowering the cost of participation in the routing economy.

AFRINIC turns database ambiguity into institutional risk

Every RIR faces fragmented IRR data. AFRINIC is not unique because it has route objects, stale records or operators who disagree about source policy. It is distinctive because database ambiguity sits on top of institutional stress that has already made counterparties sensitive to continuity. A governance crisis changes how ordinary technical defects are priced. In a calm institution, a stale IRR duplicate may be treated as housekeeping. In a stressed institution, the same duplicate may be interpreted as evidence that the ledger cannot police its edges.

AFRINIC's recent history includes litigation, disputed governance, receivership-related uncertainty, election turbulence, an annulled 2025 election after reported irregularity concerns, and later efforts to restore board function. It also includes public concern about historical IPv4 record integrity and address misappropriation. Those facts should not be used to condemn every record or every operator in the region. They do not prove that a given IRR object is false. But they do change the cost of proof. A third party looking at an AFRINIC-administered prefix may ask more questions because the institution around the ledger has been visibly strained.

That is where fragmented IRR data becomes institutional risk. If a prefix has one origin in an AFRINIC-linked source, another in a commercial IRR, and a stale reference in an AS-SET maintained by a former provider, the technical conflict is also a governance signal. It says the market cannot easily see which institution, which source and which authority chain should settle the operational claim. In a region where addresses are scarce and the registry has been under pressure, that uncertainty attracts risk premiums.

The danger is not only bad actors. Legitimate networks suffer from the same discount. A public university with old records may be treated as suspect when it changes providers. A small ISP may lose a transit opportunity because its AS-SET expands inconsistently. A government agency may face weeks of review because historical contacts no longer answer. A data centre may struggle to bring customer space into a local exchange because another source still points to an international carrier. These are not necessarily failures of AFRINIC staff or of any one IRR operator. They are failures of a fragmented reliance system to make ordinary legitimacy cheap.

Institutional stress also encourages mandate expansion. A registry under criticism may be tempted to prove vigilance by asserting broader control over routing data, address use or market behaviour. Community-sovereignty language can make that expansion sound natural: because the registry serves a region, it should decide more questions in the region's name. But technical coordination does not become legitimate merely by invoking community. If the registry becomes a discretionary market governor, it raises the stakes of capture, litigation and political conflict. If it retreats into passive record-keeping while fragmented data governs reachability, it fails the market in another way. The narrow path is stronger ledger reliability without broader gatekeeping.

That path requires recognising the separate layers. AFRINIC's number-resource registry is the durable ledger. IRR data is routing-policy publication adjacent to that ledger. RPKI and ROAs provide cryptographic route-origin evidence through a different mechanism. BGP announcements show observed routing, not authority. Contracts and court orders may decide rights among parties, but they need translation into operational signals. Confusing these layers produces overreach or neglect. Keeping them separate allows each to do its job.

For example, if a disputed AFRINIC-region prefix has conflicting IRR entries, the registry should not have to decide every commercial dispute before any operational record can change. But it should provide clear procedures for source authority, notices, status labels, conflict reporting and correction. If a holder shows that a stale object in an AFRINIC-controlled source no longer reflects its delegation, the correction path should be fast and auditable. If a duplicate persists elsewhere, operators should have enough source metadata to know that the AFRINIC source has a different authority posture. If a court order affects who may act for the holder, the registry should map that order to the ledger carefully rather than turning route filters into ad hoc legal instruments.

The institutional aim is continuity. Networks should not have to wait for perfect governance calm before their routing data becomes usable. Nor should governance turbulence be allowed to turn ambiguous IRR records into private leverage. A registry that is narrow, procedural and transparent lowers the value of institutional capture. The less discretion attached to database ambiguity, the less prize there is in controlling the institution.

IPv4 scarcity turns ambiguity into a premium

IPv4 scarcity is the force that converts IRR fragility from an engineering nuisance into an economic problem. When addresses were abundant, a messy block could sometimes be replaced, renumbered away from, or ignored. Exhaustion changed that. A routable IPv4 block now carries customer dependencies, reputation history, firewall allowlists, geolocation assumptions, reverse DNS expectations, cloud mappings and asset value. The ability to get that block accepted by upstreams, IXPs and cloud platforms is part of what the block is worth.

An address block is not valuable merely because it appears in a registry. It is valuable because counterparties believe it can be used. Usability depends on a stack of evidence: registry holder records, contractual authority, routing history, IRR objects, AS-SETs, RPKI status, abuse reputation, reverse DNS, cloud onboarding approvals and carrier filters. Fragmented IRR data sits in the middle of that stack. It is close enough to operations to affect reachability and close enough to the registry to influence perceptions of legitimacy. When it conflicts, the block becomes less liquid.

A buyer sees this as cleanup risk. If it acquires the block, will old route objects remain? Will a former origin still appear in filters? Will the seller be able to delete stale duplicates from sources it does not control? Will cloud providers accept the new origin quickly? Will a lender financing the deal view the routing posture as stable? Each uncertain answer can change price, escrow terms or closing timeline. The market does not need to believe that IRR records are title documents. It only needs to believe that bad IRR records can delay value.

A broker sees it as execution risk. Brokers sell confidence as much as they sell introductions. A block with clean registry data but messy IRR history requires more explanation. If the broker cannot show that the prefix will be accepted by major transit providers and platforms, the buyer may discount it. If the broker relies on a stale object to show routability, the buyer may later discover that operational acceptance was based on fragile evidence. Fragmented IRR data turns brokerage into a form of routing due diligence.

A lender sees it as collateral uncertainty. Address-dependent businesses may not pledge IPv4 blocks directly in a simple way, but lenders still care about whether the network assets supporting cash flow are stable. If a company's ability to serve customers depends on prefixes that require manual route exceptions, the asset is weaker. If conflicting IRR records could allow an old provider or claimant to create confusion, the risk is higher. If the registry environment is stressed, the lender may ask for more controls. Ambiguous routing data becomes a financing cost.

A customer sees it as service reliability. Enterprises, public agencies and cloud users do not want to learn the difference between RADB, AFRINIC, AS-SET recursion and RPKI. They want their provider's network to work. When a migration fails because a route server rejects a prefix, the customer experiences delay and mistrust. The provider may blame the registry, the old provider, the new upstream or a database source. The customer hears only that the address asset was harder to use than promised.

Scarcity intensifies the distributional issue. Wealthier networks can buy expertise. Smaller networks may pay through delay. African operators trying to build local interconnection may face skepticism from global platforms that are accustomed to stricter documentation. Public-sector networks with old allocations may struggle to modernise because old records do not match current procurement structures. Universities and research networks may inherit records from a more informal era. The market premium for clean IRR data is therefore not only a reward for good hygiene. It is also a penalty on historical complexity.

The policy conclusion should be modest. AFRINIC should not make itself the arbiter of every transfer price, lease, pledge or cloud onboarding decision. That would turn a registry into a market supervisor. But it should understand that registry-adjacent routing data affects those decisions. If the regional source is predictable, if stale records can be found and corrected, if source authority is visible, and if operators can rely on clear procedures, the scarcity premium attached to ambiguity falls. Good IRR governance makes IPv4 markets less feudal. Bad IRR governance lets those with private knowledge extract value from everyone else's uncertainty.

RPKI helps, but it does not dissolve IRR dependency

RPKI and Route Origin Authorisations are often presented as the cleaner alternative to IRR. They are cleaner for a specific question. A ROA allows a resource holder, within the resource-certificate system, to state which AS may originate a prefix up to a defined maximum length. Networks performing route-origin validation can classify announcements as valid, invalid or not found. That is a powerful improvement over unauthenticated or loosely authenticated text records. It reduces one class of uncertainty around origin authority.

But RPKI does not dissolve the IRR problem. Operators still use IRR data for customer filters, AS-SET expansion, route-set policy, maximum-prefix expectations and routing-policy documentation. A ROA can say that an AS is authorised to originate a prefix. It does not describe the full customer cone behind a transit AS. It does not clean stale AS-SETs. It does not remove duplicate route objects from private IRRs. It does not explain why one repository says a former upstream still originates the block. It does not tell a broker whether old IRR references will delay a buyer's carrier onboarding. It does not decide whether a provider-created object should be deleted after contract termination.

RPKI is therefore a comparator and partial alternative, not the centre of the source-fragmentation problem. It can provide stronger evidence for prefix-origin claims. It can help operators reject announcements inconsistent with ROAs. It can reduce reliance on weak IRR data for a subset of decisions. Yet the routing economy remains plural. Some networks enforce ROV strictly. Some monitor. Some use IRR filters more heavily than RPKI. Some require both. Some accept RPKI for origin but still require AS-SETs for customer cone filtering. The market is not governed by one validation switch.

In AFRINIC's case, RPKI's value may be especially high because institutional stress makes machine-verifiable origin evidence attractive. A ROA can reassure an upstream that a holder has published a current origin authorisation. It can help a cloud provider distinguish a legitimate new origin from a stale IRR object. It can give a buyer a cleaner diligence item. But it does not answer every source-fragmentation question. A prefix can have a valid ROA and still appear in old AS-SETs. A route server can use IRR-derived filters that reject the route before RPKI even matters. An upstream can require IRR registration for provisioning even if RPKI is valid. Operational cultures change slowly.

There is also a political economy of substitution. If a registry or standards community says, "use RPKI and ignore IRR", it may underestimate existing operational dependencies. If operators say, "IRR works well enough", they may preserve weak authority chains. The realistic path is layering. RPKI should reduce the burden placed on IRR for origin validation. IRR should remain useful for routing policy and customer-cone expression. Where the two conflict, operators should have clear policies for which signal governs which decision. A valid ROA should not automatically cleanse every stale AS-SET. A stale IRR object should not automatically defeat strong current origin evidence. Each signal has a job.

This layered approach also avoids turning RPKI into an overbroad property instrument. A ROA is not a deed, just as a route object is not a deed. It is a cryptographic routing authorisation with defined operational meaning. The temptation in a scarce market is to let whichever artifact is strongest become the general answer to all disputes. That would be a mistake. RPKI can reduce route-origin ambiguity, but contracts, registry records, corporate authority, court orders, customer delegations and IRR cleanup still matter. The fact that one layer is stronger does not eliminate the need for coherence across layers.

For route-server and transit automation, the practical improvement is conflict-aware policy. A system should be able to say: the ROA validates this origin, the AFRINIC-linked IRR source supports it, a non-regional IRR has a stale duplicate, and an AS-SET in another source still references the former provider. That is a better market signal than a binary accept or reject. It lets the operator accept the route while opening a cleanup ticket, or reject only if the conflict reaches a defined risk threshold. The goal is not more data for its own sake. The goal is cheaper, more consistent judgement.

RPKI's rise should therefore make IRR governance more disciplined, not irrelevant. As stronger origin evidence becomes available, the remaining IRR data should be used for what it does best and cleaned where it causes confusion. AFRINIC's challenge is to support that transition without using it to expand discretion. Stronger routing security should protect the ledger's reliability. It should not give the ledger operator a larger mandate to govern market relationships by implication.

The trust question is different for each counterparty

The phrase "which database can be trusted?" sounds singular. In practice, trust depends on the counterparty and the decision. An upstream, an IXP, a cloud provider, a broker, a buyer, a lender and a customer all ask different questions of IRR data. Fragmentation is costly because the same conflict must be translated into each decision context.

An upstream asks whether it can safely accept a customer's announcement. It cares about preventing hijacks, avoiding route leaks, satisfying internal policy, limiting support burden and provisioning revenue. It may accept a mix of IRR and RPKI evidence if the customer relationship is strong. It may be stricter for new or small customers. For the upstream, database trust is a customer-risk filter. If sources conflict, the conservative answer may be to delay service until the customer cleans up records. The cost falls on the customer.

An IXP route server asks a more communal question. It must protect many participants at once. A bad route can propagate through multilateral peering. A rejected route can reduce the value of the exchange for a legitimate member. The route server is often more rules-driven because it cannot privately negotiate every case without undermining predictability. For the IXP, database trust is a shared risk policy. Source fragmentation can either lower local peering value or increase the risk accepted by all members.

A cloud provider asks whether it can advertise customer space at scale without becoming a laundering channel for questionable prefixes. It needs standardised onboarding. It may prefer strong registry and RPKI evidence, but it still encounters IRR records during due diligence and operational filtering. For the cloud, database trust is part of platform risk. A messy AFRINIC-region prefix may not be rejected because of prejudice; it may be delayed because the platform cannot resolve contradictions cheaply at scale. The economic effect on the holder is the same.

A broker asks whether the address block can be sold, leased or introduced without surprises. It cares about confidence, price and closing timeline. Fragmented IRR data is a defect to be disclosed, cleaned or discounted. For the broker, database trust is marketability. Stale duplicates and conflicting origins reduce the promise that the buyer can use the block quickly. The broker may not control any database, but it must sell around the databases' defects.

A buyer asks whether it will receive an asset that works operationally after closing. Registry transfer alone is not enough if old route objects, AS-SET references or source conflicts will block deployment. The buyer may demand remediation before payment or hold back funds until carriers accept the new origin. For the buyer, database trust is post-closing usability. Ambiguity becomes a price term.

A lender asks whether address-dependent revenue is resilient. It may not understand every RPSL object, but its technical adviser will translate database conflict into operational risk. If a borrower's prefixes depend on manual carrier exceptions or unresolved registry disputes, the lender sees fragility. For the lender, database trust is cash-flow support. It affects credit even when the loan is not secured directly by addresses.

A customer asks the simplest question: will service work? It may not know which database a route server used. It only sees that a migration stalls, a prefix is rejected, or a provider cannot explain why acceptance differs across networks. For the customer, database trust is service credibility. When providers hide behind "IRR issues" without clear explanation, customers learn that the market's invisible plumbing is unreliable.

These differences matter for AFRINIC because a registry-centred answer alone will not satisfy every reliance need. The registry can make its source cleaner, provide correction paths, publish conflict metadata and improve continuity under stress. Each counterparty will still choose how to use the data. The aim is not uniform trust but coherent facts: what the source proves, what it does not prove, how conflicts are labelled, how stale data is corrected and how third parties can make policy without guessing. Trust is not commanded. It is made cheaper.

A narrow standard for AFRINIC-region reliance

A practical standard for AFRINIC-region IRR reliance should begin with humility about what any one artifact proves. A route object proves that a prefix-origin statement exists in a source under that source's rules. A route6 object does the same for IPv6. A mntner proves who can authenticate certain database changes, not who holds every underlying mandate. An AS-SET describes intended routing relationships but may import stale or cross-source data. A ROA provides stronger cryptographic origin evidence, but not a full map of customer cones, commercial authority or database cleanup. Observed BGP shows what is happening, not necessarily what is authorised.

From that humility follows a hierarchy. For AFRINIC-administered resources, the AFRINIC-linked registry and routing-policy source should carry high evidentiary weight when it is current, procedurally clean and transparent. Non-AFRINIC IRR entries should remain usable, but operators should not pretend that every RPSL object rests on the same authority foundation. RPKI should strengthen origin assurance. AS-SET expansion should be treated as a chain whose sources, ages and cross-source references matter. Manual exceptions should be temporary and logged. Stale duplicates should be visible and correctable.

The tempting alternative is centralisation: make one source decisive and require all market actors to defer. That would answer fragmentation by turning a ledger into a gatekeeper. AFRINIC should avoid that path. Its value is not in approving every transfer, lease, cloud onboarding or provider change. Its value is in protecting a narrow continuity ledger so that others can make their own routing and commercial decisions cheaply. Mandate language should not launder a technical coordination role into discretionary market control.

Narrowness does not mean weakness. A reliable source can still have strong authentication, proportional authorization checks, clear correction paths, conflict labels, public metrics and continuity procedures. Routine updates by stable maintainers should be easy. Changes that alter origin AS, remove a former provider, add broad customer cones, affect scarce IPv4 blocks, or arise during corporate or governance disputes should require more evidence and notice. The test is proportionality: too little evidence invites abuse; too much evidence freezes ordinary operations.

Notice should be part of that proportionality. If a change would displace an existing origin or remove an object used by filters, affected contacts should be notified where feasible: resource holder, existing maintainer, proposed origin, current origin and relevant operational contacts. Notice should not become a veto. It is a way to surface errors before they become outages. Where urgency requires emergency action, the action should be temporary, logged and reviewed.

Metrics would make the standard credible. AFRINIC and major operators should be able to measure how often AFRINIC-administered prefixes have conflicting route or route6 objects across sources, how often AS-SET expansions differ by source order, how old stale duplicates are, how fresh mirrors are, how long corrections take and how many customers require manual exceptions. These numbers need not expose private customer files. They would tell the market whether fragmentation is an anecdote, a chronic tax or an improving condition.

The same discipline should apply to tooling. Filter systems should expose source paths: which source, object, AS-SET chain and recursion rule produced acceptance or rejection. Holders should be able to discover where their prefixes and ASNs appear across major IRR sources and route-sets. Route servers should report rejection categories that are intelligible to members. Historical records should be preserved for audit, but current-state guidance should be clear enough for operators to use. The goal is not a perfect database. It is a database environment in which uncertainty is labelled, bounded and cheap to reduce.

This standard would make life easier for the route-server engineer facing the dawn filter job. If several sources gave contradictory answers, the tooling would show freshness, authority posture, source path and conflict age. A valid ROA would be weighed for origin assurance but not used to ignore stale AS-SETs. The AFRINIC-linked source would be trusted because its procedures were visible, not because the institution demanded deference. External sources would be considered with their limits. The customer would receive a clear cleanup path rather than a mysterious rejection. Judgement would still be required, but it would be cheaper.

The cost of not fixing fragmentation

If IRR fragmentation remains unmanaged, the market will still find ways to route. The Internet is good at routing around institutional weakness. That resilience should not be mistaken for health. The workaround path is predictable: large operators build private trust systems, platforms impose stricter onboarding, small networks rely on incumbents, brokers price cleanup risk, route servers tighten policies, and customers learn that address-dependent services in some regions require more explanation. Packets may still flow, but participation becomes more expensive and less equal.

For AFRINIC, that outcome would be damaging because the region needs lower coordination costs, not higher ones. Local interconnection, cloud localisation, public-sector digital services, university networks, regional content delivery and small-provider competition all depend on predictable routing acceptance. If every migration or onboarding can be slowed by contradictory database sources, the region pays a quiet tax. The tax appears as delayed projects, higher transit dependence, weaker bargaining positions, lower asset values and greater reliance on intermediaries outside the region.

Security would not necessarily improve. Overly strict policies may reduce some bad routes, but they also push legitimate operators into manual exceptions. Overly loose policies keep stale authority alive. Private workarounds make the system less transparent. The best security outcome comes from coherent evidence: current holder-linked data, clean AS-SETs, RPKI where appropriate, visible source conflict and fast correction. Fragmentation without management produces neither openness nor security. It produces selective opacity.

The institutional cost would be equally serious. A registry recovering from governance turmoil needs to show that its basic utility functions are reliable. IRR coherence is one such function because it sits close to daily operations. If AFRINIC can make routing-policy data cleaner, more transparent and easier to correct, it will strengthen confidence in the ledger without asking the market for blind trust. If it cannot, counterparties will create their own reliance systems. Once those systems harden, the regional registry's public function becomes less central and private gatekeepers become more powerful.

The market cost will rise as IPv4 scarcity persists. Scarcity raises the value of every ambiguity that can affect use: a stale route object, a missing AS-SET entry, a mirror lag, a source preference or a governance dispute. Fragmented IRR data turns small technical defects into economic options held by whoever can exploit or resolve them.

The answer is not a dramatic new sovereignty claim over routing. It is a disciplined reduction of ambiguity. AFRINIC should be a narrow continuity utility for the resources it administers, with routing-policy support that is reliable enough for third parties to use and limited enough not to become market command. Operators should publish how they consume sources and handle conflicts. Major IRR sources should improve stale-object discovery and authority context. IXPs and carriers should make route-server and customer-filter decisions explainable. Buyers, brokers and lenders should treat IRR posture as diligence, not folklore.

The route-server job at dawn should not have to decide the institutional future of African Internet numbering. It should have to decide whether a route is safe to accept under a clear policy. That is already hard enough. Fragmented IRR data makes it harder by presenting several plausible pasts as if they were equal presents. In a market built on scarce numbers and voluntary interconnection, that confusion has a price.

AFRINIC's opportunity is to reduce that price. Not by becoming a gatekeeper over every commercial use of IPv4. Not by asking operators to ignore non-regional sources. Not by pretending that RPKI eliminates routing-policy databases. The opportunity is narrower and more valuable: make the AFRINIC-linked ledger and routing-policy source dependable, expose conflicts, preserve history, speed correction, separate authentication from authorization, and help operators see which database claim rests on which institutional foundation. If that happens, IRR data returns to its proper economic role. It becomes a way to make trust cheaper, rather than a reason every network must buy its own private map of doubt.