The commercial risk inside a new African datacentre is often less visible than the switchgear, chillers, carrier meet-me rooms or tenant cages. It appears later, when a signed customer asks how many public IPv4 addresses can be turned up, whose records will identify them, whether reverse DNS can be changed during the migration window, and whether the registry evidence behind those addresses will be trusted by banks, abuse desks, routing teams and auditors.
That is a narrow problem, but it is not a small one. Colocation turns fixed capital into recurring revenue only when space, power and network identity arrive together. A rack that cannot support public endpoints, migration allowlists, clean abuse contacts and credible routing evidence is not fully monetised, even if the cabinet is powered and the cross-connect order is complete. The economics of the hall are therefore tied to the economics of address continuity.
AFRINIC sits close to this pressure point because it is the Regional Internet Registry for Africa and parts of the Indian Ocean. Its public materials say IPv4 Exhaustion Phase 2 began on January 13 2020, with tighter limits on ordinary IPv4 allocation. Since 2019, public reporting, court materials and registry communications have described contested address-record allegations, litigation involving Cloud Innovation, receivership, interrupted governance processes and recovery efforts. This article does not need to turn those disputes into a verdict. For datacentre economics, the practical issue is simpler: public address records have become commercial evidence, and any uncertainty around that evidence changes the cost of filling racks.
The market signal is no longer abstract. Teraco's own site describes eight locations, 650 clients, 27,000 interconnects and 228MW of IT load. Africa Data Centres says it operates across major African business hubs, with more than 50 carriers and major internet exchanges including JINX, CINX and KIXP present in its facilities. Digital Realty presents Johannesburg as Africa's leading datacentre market and lists 425-plus cloud and network service providers, 495-plus customers and three Johannesburg data centres. These are corporate claims, not neutral censuses, but they point to a denser colocation economy: enterprise disaster recovery, managed service providers, bare metal, content caches, tenant cages, cross-connect ecosystems, security services and local application hosting.
The focus here is that colocation economy. It is not the route-filter trust problem at peering committees, the geography of submarine-cable landings, or the public IPv4 price strategy of hyperscale cloud platforms. Those matters touch the same address layer, but they are not the main story. The main story is the customer order in the hall: racks, power, cooling, cross-connects, customer onboarding, tenant address pools, public endpoints, migration inventories, reverse DNS, abuse contacts, RDAP, RPKI and the question of whether AFRINIC-administered resources make local compute easier or harder to sell.
A datacentre hall exposes address scarcity at the point of sale
The visible constraints in a datacentre build are familiar. Developers secure land, power, backup generation, cooling design, permits, security, fibre routes and anchor tenants. Those inputs are expensive, but they are legible. A lender can review the power contract. An enterprise customer can inspect the cage. A facilities team can test cooling under load. A carrier can price a cross-connect. The physical project may be difficult, but its risks can be put into drawings, purchase orders and service-level commitments.
IPv4 scarcity arrives differently. It often appears after the sales conversation has already moved from interest to delivery. A bank signs for disaster-recovery space and then finds that partner allowlists, payment interfaces and security appliances still assume stable public IPv4. A managed-service provider takes several cabinets for regional customers and asks for address segmentation that will make abuse response and tenant attribution credible. A content platform wants local cache nodes but will not accept a range with poor reputation history. A bare-metal provider can rack servers faster than it can assemble enough clean public endpoints to make those servers sellable.
The result is a mismatch between physical readiness and commercial readiness. A cabinet can be energised, cooled and patched to a meet-me room while the customer's external identity remains unresolved. Migration runbooks depend on public addresses. Firewalls and partner systems need change windows. Monitoring and incident response need reverse DNS and contact records. Banks, payment processors and public-sector customers often ask who controls the address, what the public record says and whether the customer can move later without breaking its dependencies.
That mismatch changes the meaning of occupancy. In a lease model, space and power may be contracted before the tenant's service is taking production traffic. In practice, revenue quality improves only when the customer's workloads can be reached, trusted, monitored and defended. Public IPv4 is not consumed like electricity, but it is locked into the service. It behaves like operating inventory: scarce enough to require planning, visible enough to affect procurement, and sticky enough to influence renewals.
African demand makes the problem sharper because many buyers are not dedicated network operators. Regional software companies, payment processors, retailers, schools, clinics, media platforms, logistics firms, government contractors and local hosting companies often want a practical bundle. They need space or servers, transit, firewalls, public endpoints, backup connectivity, names, abuse contacts, migration support and enough continuity to change suppliers later. They are not buying address policy. They are buying the ability to go live without turning a datacentre move into a network-governance project.
That makes the operator an address-risk intermediary. It may use its own AFRINIC allocation, help a customer announce its own space, lease addresses, arrange reverse DNS, maintain RDAP and WHOIS contacts, support RPKI, update routing registry objects and document abuse procedures. Each task is small compared with megawatts of IT load. Together they decide how quickly the customer's order becomes live revenue. A hall with weak address arrangements resembles a factory with a missing input: the machinery exists, but throughput is constrained by something management cannot manufacture on demand.
Tenant cages make the point concrete. A customer may take a locked cage because it wants operational separation from neighbours, dedicated cabling, audited access and predictable change control. That separation is weakened if the public address layer is still shared, undocumented or dependent on a supplier the customer cannot assess. The customer may accept shared transit or managed security, but it still wants to know which public endpoints belong to which workload, which addresses can be reserved for failover, and whether a future move to another cage, hall or provider will require a public-identity reset. Physical isolation and network identity are sold together, even when the invoice lists them separately.
Public IPv4 behaves like working capital, not office stationery
The phrase "IP address" makes the resource sound smaller than it is. In colocation, a public address is part of the service setting in which servers become reachable and trustworthy. It can identify a website, API, mail host, VPN concentrator, DNS service, monitoring collector, customer portal, fraud endpoint or administrative interface. Even when a customer's internal systems are private or IPv6-capable, public IPv4 can remain embedded in partner contracts, old devices, enterprise allowlists, audit files and third-party security tools.
For a datacentre operator, that means address stock must be planned before every customer has arrived. A provider needs capacity for onboarding, churn, temporary migrations, failover, testing, emergency replacements and customers that require clean or dedicated ranges. It needs pools large enough to route sensibly and small enough to allocate commercially. It needs to avoid mixing tenants whose abuse profiles would contaminate one another. It also needs to decide whether addresses are included in the cabinet price, charged as a scarce add-on, passed through from the tenant, leased from a third party or reserved for premium managed services.
Those choices affect cash flow. If the operator acquires or leases addresses ahead of demand, capital is tied up before revenue is certain. If it waits until customers sign, activation slows and the sales pipeline becomes less reliable. If addresses are bundled too cheaply, scarce inventory leaks margin. If they are priced too harshly, customers redesign, move the workload to a different supplier or accept a provider-managed architecture they did not originally want. Address policy becomes a pricing system beside power density, remote hands, cross-connects and cage security.
The issue is especially sensitive in markets where customer habits are still forming. A mature enterprise may know whether it will bring its own address space or rely on the provider. A regional mid-market customer often discovers the problem during migration planning. The customer's procurement team may require local hosting but have no address inventory. Its security team may need public endpoints separated by function. Its auditors may ask for evidence of control. Its old hosting provider may control reverse DNS. Its application partners may reject a new address until reputation and contact records are cleaned up.
IPv6 is necessary, but it does not remove the commercial constraint. It helps new designs, internal systems, dual-stack services and long-term architecture. It does not instantly remove IPv4 from payment rails, enterprise networks, old customer devices, content distribution, fraud systems or partner allowlists. The datacentre buyer does not ask whether IPv6 is technically better. It asks whether a move into the hall can happen without losing reachability or reputation continuity. Often the answer still depends on public IPv4.
AFRINIC's economic role begins there. A trusted registry lowers the cost of holding address inventory because rights, contacts, delegations and routing evidence are easier to verify. A disputed or slow registry environment raises the cost because each block needs more checking, more legal language, more contingency planning and more customer reassurance. The same number of addresses can support less business if the evidence around those addresses is doubtful.
The African market signal has outgrown the old allocation story
African internet-resource debates have often started from under-allocation: too few local networks, too little domestic hosting, expensive international transit, limited local exchange ecosystems and heavy reliance on offshore platforms. That history is still relevant. It is not the whole market anymore. Several African metros now have enough carriers, enterprises, content platforms, cloud on-ramps, managed-service customers and regulated-data requirements for address demand to behave like a dense commercial market rather than a periodic administrative request.
Johannesburg is the clearest example because it combines carrier density, enterprise concentration and several major facilities. Nairobi and Lagos carry different but substantial demand: mobile-money and payments ecosystems, public-sector digitisation, regional application hosting, content distribution, cybersecurity, government contractors and disaster recovery for organisations that do not want resilience to sit entirely offshore. Cape Town adds enterprise and media demand. Smaller markets follow through banking, telecom consolidation, government digitisation and service providers building regional customer bases.
The corporate figures should be used carefully. Teraco, Africa Data Centres and Digital Realty are marketing their own platforms. Yet their published numbers are useful exhibits because they show how these companies want customers and investors to understand the market. They sell not merely square metres or power feeds, but proximity to counterparties: carriers, cloud nodes, exchanges, content providers, managed services, security firms and enterprises. That is a colocation marketplace, not a server room.
Dense marketplaces multiply address demand. A carrier attracts managed-service providers. A managed-service provider attracts smaller enterprises. An internet exchange attracts content caches and security services. A content cache improves the case for more local hosting. Disaster-recovery contracts require standby public endpoints that may be quiet most of the time but must work immediately during an outage. Bare-metal and hosting providers need addresses they can assign without weeks of negotiation. Each layer increases the value of address pools that are clean, divisible, documented and portable.
IX-adjacent demand is especially important, but for a different reason from the peering-policy problem. A tenant may want to sit near an exchange, a carrier ecosystem or a cache cluster because that proximity reduces latency, support delays and transit cost. The customer's order still lands as a datacentre product: cabinet space, cross-connects, port options, power density, remote hands and public endpoints. The address question is not whether a route server will accept a prefix under a particular filter. It is whether the tenant can turn proximity into a service without waiting for address inventory, reverse-DNS delegation or public contact evidence to catch up.
Conservation remains important, but it has diminishing commercial returns inside a customer marketplace. NAT, shared platforms, load balancers and private addressing can reduce visible address consumption. They can also create audit friction, reputation spillover, logging complexity and customer lock-in. A tenant paying for dedicated infrastructure may not want a shared public identity. A security company may not want many customers behind the same egress points. A bank may require a separation model that is easier to explain with dedicated addresses than with clever translation.
This is why AFRINIC scarcity is not only a policy-management issue. It shapes market formation. If usable addresses are available only through slow, uncertain or politically charged channels, the cost appears in delayed activation, expensive leases, larger legal reviews, cautious financing and greater advantage for incumbents with historic address inventory. A new entrant may build an excellent hall and still face a weaker address position than a competitor that accumulated resources earlier. Scarcity then influences competition inside the datacentre sector.
Soft Landing turned scarcity into an operational control
AFRINIC's IPv4 Exhaustion Phase 2 began on January 13 2020, according to the registry's announcement. That did not create scarcity; the direction of travel had been obvious for years. It did formalise a point at which ordinary allocation became smaller, more controlled and more explicitly tied to conservation. For datacentre operators, the timing matters because administrative scarcity usually appears before customers fully understand commercial scarcity.
At first, scarcity feels like paperwork. A request needs more justification. A block is smaller than the sales team expected. A tenant cannot be supported from a fresh allocation and must use provider space. A transfer becomes attractive. A lease is discussed. Engineers ask whether every public endpoint is necessary. Finance asks why address inventory is being treated like a capital asset. Lawyers ask whether a leased block can be relied upon. Customers ask why a domestic infrastructure move is constrained by numbering decisions that predate their business.
Over time, paperwork becomes price. Limited fresh supply pushes demand toward transfers, leasing, internal conservation and provider-owned pools. Transfer value becomes part of expansion economics. If a provider needs address inventory to support a new hall, the price and certainty of that inventory affect the hall's business case. If a tenant must obtain addresses before moving workloads, address-market timing affects the migration. If counterparties are unsure whether a block's records are clean, registry credibility becomes part of procurement.
Soft Landing also makes policy language more consequential. Terms such as conservation, fairness, need, anti-hoarding and regional development can describe legitimate public purposes. They can also convert a ledger function into discretionary control over commercial deployment. A neutral registry records uniqueness, keeps contacts current, supports delegation and preserves reviewable process. A gatekeeper decides which business models deserve continuity. The distinction may look theoretical in a policy meeting; it is concrete when a customer is waiting to activate services.
Datacentre demand exposes that line because the operator is not necessarily asking for special treatment. It needs reliable evidence that addresses used in a customer service can be routed, delegated, contacted, reviewed and, where appropriate, transferred or leased under clear conditions. If the registry treats public evidence as stable unless a specific and reviewable process says otherwise, the market can price scarcity. If the registry treats evidence as broadly revocable through uncertain discretion, scarcity becomes institutional risk.
The public controversies around AFRINIC should be handled with care. Allegations, litigation and governance disputes are not substitutes for findings in every case. Their economic meaning is narrower: they show that address records are now valuable enough to become the subject of serious legal and commercial conflict. A datacentre operator watching that history has to ask how registry decisions survive dispute, how quickly record uncertainty is resolved, and whether downstream customers can remain operational while contested matters are handled.
Customer onboarding is where registry evidence becomes revenue
Customer onboarding is the place where the registry layer becomes commercial. The buyer has signed, the cage or rack has been assigned, cross-connects are ordered, remote hands have instructions, firewalls and servers are arriving, and the migration window is on the calendar. At that point the address plan is no longer an abstract network topic. It is a checklist that decides whether the service can go live.
The checklist is broader than an allocation size. Who is the registered holder or user? Which organisation appears in RDAP or WHOIS? Are abuse contacts current and monitored? Who controls reverse DNS? Are route objects and RPKI records aligned with the planned announcements? Can the customer show auditors that the public endpoints match the supplier contract? Can a bank, partner or public-sector counterparty verify the claim without phoning three unrelated organisations? Can the provider document what happens if the customer leaves?
The migration inventory can be more revealing than the customer's architecture diagram. It lists old IP addresses, firewalls, partner allowlists, DNS records, certificates, payment callbacks, monitoring probes, mail reputations, geolocation corrections, abuse contacts and emergency access paths. Some entries are forgotten until a cutover fails. Others belong to counterparties that change slowly, such as banks, government systems or enterprise customers with quarterly change windows. A disciplined datacentre provider reviews that inventory before promising a go-live date. Address availability is therefore not a late network ticket; it is part of commercial readiness.
For many tenants, this evidence is part of risk review. Banks and payment companies care because addresses appear in allowlists and fraud controls. Security firms care because public identity affects incident response. Managed-service providers care because their customers expect attribution and portability. Content platforms care because caches depend on reputation and reachability. Public-sector buyers care because procurement files and security audits are conservative. A weak address record can delay an otherwise normal onboarding.
Good operators turn this into a product discipline. They maintain clean pools, standardise reverse DNS requests, document route-origin procedures, support customer-owned resources, keep abuse contacts usable, and provide migration playbooks. They distinguish between provider-assigned addresses, customer-owned addresses, leased ranges and temporary migration space. They explain whether addresses can move with the customer. They keep internal inventory good enough that a support engineer can answer a customer's evidence question during a change window.
That discipline also affects support cost. If the provider cannot quickly identify which tenant used an address during a particular time window, an abuse complaint becomes a hunt through ticket systems and spreadsheets. If reverse DNS changes are handled as exceptions, every migration consumes senior engineer time. If public contacts are stale, counterparties escalate to sales or legal teams. These are not spectacular failures, but they erode margin. A scarce address pool is profitable only when it is managed like production inventory, not like a drawer of leftover numbers.
Those practices still depend on a reliable registry environment. A provider can promise effort, but not always outcome, if public records are slow to change or contested. It can maintain an internal database, but counterparties will still read RDAP, WHOIS, reverse DNS and routing evidence. It can build a polished onboarding process, but the customer's bank may refuse to accept a range whose public contacts are stale or whose registration story is unclear.
For AFRINIC, the lesson is prosaic. The registry's most valuable contribution to datacentre growth may not be a slogan about digital transformation. It may be predictable record maintenance, clear status, reviewable decisions, stable delegations and evidence that outsiders can understand without insider knowledge. Each clean onboarding lowers the cost of local compute. Each ambiguous record inserts friction into the sales cycle.
When certainty weakens, the hall sells risk alongside space
A datacentre proposal usually sells certainty: power availability, cooling design, access control, cross-connect options, remote hands, compliance, resilience and support. Address uncertainty undermines that offer because it forces the provider to sell risk as well. The customer is no longer only choosing rack units and kilowatts. It is choosing the provider's ability to manage an external evidence layer.
The risk can appear in ordinary contract language. A provider may cap responsibility for address availability. A customer may demand warranties around continued use. A managed-service provider may seek compensation if a block cannot be renewed. A security customer may require dedicated ranges and current abuse contacts. A disaster-recovery customer may insist that standby public endpoints be tested and documented. Each clause adds negotiation time and legal cost.
Sales teams feel the risk in pipeline quality. A lead may look promising until the address plan is reviewed. A customer may accept the cage price but resist a separate IPv4 fee. A migration may be delayed because the previous provider controls reverse DNS. A tenant may ask for portability that the operator cannot guarantee. A public-sector buyer may require evidence the provider is not ready to produce. Scarcity becomes a drag on conversion, not just a cost after the sale.
Operations teams feel it after go-live. Abuse reports must reach the correct party. Reputation problems have to be isolated by tenant. Reverse DNS must be corrected without days of ticket escalation. RPKI and routing records must match the service design. Public contacts must not embarrass a regulated customer. If a provider cannot show discipline at this layer, customers may interpret the failure as a broader sign of operational weakness, even when the physical facility performs well.
Investors read the same risk differently. They may not inspect every address record, but they care whether address-dependent revenue is durable. A hall with strong customer contracts, clean address inventory and predictable registry processes can treat its address layer as ordinary operational risk. A hall dependent on opaque leases, disputed records or uncertain recognition may deserve a discount. The difference is not theoretical if occupancy and recurring revenue are being used to finance expansion.
AFRINIC cannot remove IPv4 scarcity. It can reduce the portion of scarcity that comes from institutional uncertainty. Clear records allow operators to price addresses openly, design customer products and explain risk. Ambiguous records force them to carry a registry-risk premium that customers may not see until a migration fails.
Transfer and leasing costs become a shadow rent on African compute
Address transfers and leases are not side issues for datacentres. They are part of the supply chain that lets scarce public endpoints meet customer demand. When fresh allocation is limited, operators and tenants look to historic holders, brokers, lessors, transfers, internal reclamation and customer-owned resources. Every additional cost in that chain becomes a shadow rent on compute hosted in the region.
The shadow rent is not only the nominal price of an address. It includes diligence, contract review, reputation checking, reverse-DNS control, renewal risk, routing authorisation, abuse responsibility and the contingency plan if a block becomes unavailable. A clean, well documented range may cost more upfront but less in operational risk. A cheap range with uncertain history may slow onboarding, complicate abuse response and scare regulated customers. A provider that does not distinguish the two may win a sale and inherit a dispute.
For new datacentre entrants, the shadow rent can be strategically important. Incumbents with historic address inventory can absorb or monetise scarcity. They may offer tenant pools faster, reserve clean ranges for higher-value customers and use address continuity as part of retention. A new operator may have stronger facilities but weaker address stock. It then has to lease, buy, partner or push customers toward their own resources. The physical competition is therefore affected by an invisible inventory position.
The effect reaches mid-market customers. Large banks, carriers and multinational enterprises may have staff to manage transfers or bring their own resources. A regional hosting company, school platform, software provider or payment startup may not. It may depend on the datacentre operator to explain address choices. If the operator passes through uncertainty, the customer sees higher prices, slower go-live dates or reduced portability. If the operator hides uncertainty, the customer discovers it later during abuse handling, renewal or exit.
Policy debates sometimes treat market pricing as the enemy of fairness. In practice, opacity is often worse. A transparent address cost can be budgeted. A hidden dependency cannot. If scarcity is real, operators and customers need to know what they are buying: provider space, customer-owned space, leased space, transferred space, temporary migration space or non-portable managed-service identity. Clear AFRINIC records do not make addresses abundant. They make the scarcity more honest.
The question for the registry is not whether every commercial arrangement is ideal. It is whether public evidence lets responsible parties be identified and commitments be reviewed. Transfers and leases can support growth when records are accurate, contacts are current and routing authority is clear. They become corrosive when documentation is weak, disputes are opaque and downstream customers cannot tell whether the addresses behind their production services are durable.
Address identity continuity matters more than nominal ownership
Customers often speak about "owning" addresses when they really mean preserving identity. A payment processor wants partner allowlists to survive a move. A streaming platform wants caches and APIs to keep stable public endpoints. A government contractor wants procurement and security records to remain coherent. A managed-service provider wants tenant separation and exit options. A disaster-recovery customer wants standby resources that can be activated under pressure. The commercial value lies in continuity.
Nominal ownership does not always deliver that continuity. A customer may have its own resources but lack current contacts, reverse-DNS control or routing expertise. A provider may have clean internal inventory and strong processes, making provider-assigned addresses safer for a particular tenant than a poorly maintained customer block. A leased range may be adequate for a temporary migration but unsuitable for a long-term regulated workload. A transferred block may look independent but carry reputation or documentation problems. The practical question is what public identity can survive normal business events.
Those events are predictable. Customers merge, rebrand, change providers, move between halls, add disaster-recovery sites, switch security vendors, onboard new banking partners, respond to incidents and adjust architectures. Each event touches the address layer. If identity continuity is weak, the customer may stay with a provider for the wrong reason: not because the service is best, but because changing public endpoints is painful. That is lock-in by scarcity and evidence friction.
Datacentre operators can reduce that friction by making continuity explicit. A contract can state whether addresses are portable. An onboarding pack can show which records will identify the customer. A migration plan can separate temporary from permanent endpoints. A managed-service product can include reverse DNS, abuse contacts and RPKI assistance. A bare-metal offer can disclose the address model rather than treating it as a hidden support detail. These measures turn address identity into a product promise instead of an afterthought.
AFRINIC's record quality determines how far those promises can travel. If RDAP, WHOIS, reverse DNS, routing registry and RPKI evidence can be kept coherent, counterparties can understand the continuity story. If registry evidence is stale or subject to uncertain recognition, the provider's promise becomes private reassurance rather than public proof. Private reassurance is weaker because banks, carriers, partners and abuse desks will still check the public record.
This is why a neutral registry is pro-competition. It does not favour one operator by allocating privilege; it lowers the cost for customers to move, verify and compare. It lets datacentres compete on power, cooling, service, proximity, support and reliability rather than on privileged access to historical address stock or insider knowledge of registry practice.
Mid-market tenants carry the heaviest address friction
The largest customers can buy advice. They have network engineers, procurement teams, external counsel, cloud architects and security staff. They can negotiate transfers, manage letters of authorisation, maintain RPKI, push vendors to update allowlists and run phased migrations. They may still pay more under scarcity, but they can turn the problem into a managed project.
Mid-market tenants experience the same problem as confusion. A regional application company may know that it needs public endpoints but not whether it should bring addresses, use provider space or lease a block. A local hosting company may need hundreds of small allocations for customers but lack the legal capacity to assess every lessor. A payment startup may know that banks need allowlists but not how registry records will be interpreted. A school platform or logistics firm may discover during migration that old suppliers control reverse DNS or that abuse contacts point to the wrong organisation.
That is where the datacentre operator's address discipline becomes a customer-protection function. The operator can translate registry evidence into a simple decision: this option is portable, this one is cheaper but tied to our service, this one is leased and has renewal risk, this one requires your own network team, this one will delay onboarding. The customer can then choose knowingly. Without that translation, the customer may buy a low-price package and inherit a hidden dependency.
MSPs and hosting providers are especially exposed because they sit between the datacentre and many smaller end customers. They need tenant pools, abuse segregation, reverse DNS processes, reputation management and sometimes dedicated addresses for customers with compliance requirements. If their upstream address arrangement is fragile, the fragility is multiplied across many small businesses. The immediate dispute may involve one prefix, but the service impact spreads through dozens or hundreds of customers.
Their customer mix is also messy. One MSP may host accountants, clinics, ecommerce merchants, regional NGOs, school portals and small public-sector projects in the same facility. Some tenants only need web hosting. Others need VPN endpoints, mail reputation, payment integrations or public APIs. The MSP has to allocate scarce addresses in a way that does not punish every low-risk customer for one noisy neighbour, while still giving higher-assurance customers separation they can explain to auditors. A clean registry story helps the MSP turn that messy demand into tiers. A vague story leaves it arguing about exceptions.
Bare-metal providers face a different version. Their product depends on speed. A customer expects a server to be provisioned quickly with usable public identity. If every order triggers manual address checks or scarce-inventory decisions, the bare-metal product loses one of its main advantages. Public IPv4 scarcity can push the provider toward higher prices, smaller default allocations, strict justification, NAT-heavy designs or regional inventory limits. Those choices shape which workloads stay local.
For policy, the mid-market tenant is the practical test. A rule that sounds fair in a registry forum may still raise the cost of ordinary customers obtaining reliable public identity. A conservation measure that leaves customers in opaque leases may not help them. An enforcement posture that creates public uncertainty without fast resolution may punish tenants who had no part in the underlying dispute. The market is healthiest when smaller customers can buy continuity without becoming address-policy specialists.
Reverse DNS, RDAP, abuse contacts and RPKI now act like credit files
Registry and routing records once looked like technical metadata to many business buyers. In a dense datacentre market, they act more like credit files. They are consulted by parties that do not know the customer personally but need to decide whether to route, whitelist, accept, finance, investigate or migrate a service. Their value comes from the confidence they create for strangers.
Reverse DNS is the most familiar example. It affects mail delivery, security investigation, operational clarity and customer perception. A tenant moving into a new hall may need reverse DNS changes aligned with a migration window. If delegation is uncertain, or if the controlling party is slow, the migration suffers. If reverse DNS points to an unrelated organisation, the customer may look careless before the first application packet is judged.
RDAP and WHOIS serve another function. They show who is associated with a resource and how contact can be made. Abuse desks, banks, partners, security vendors and procurement teams may all read that record. A regulated tenant whose public addresses point to an old holder or unrelated contact can face delays that have nothing to do with the quality of the datacentre. Clean contact evidence becomes part of product quality.
Abuse contacts are not only a compliance formality. In a colocation environment, poor abuse handling can spread reputational cost across tenants and providers. If a customer can be reached quickly and responsibility is clear, an incident may be contained. If contacts are stale or ambiguous, networks may block, rate-limit, escalate or distrust a range. The address pool then loses value for everyone who depends on it.
RPKI and routing registry records add evidence around route origination. They do not solve every routing problem, and this article is not about peering-route trust as a primary subject. In customer onboarding, however, route-origin evidence helps technical teams show that the public route matches the commercial claim. It allows a datacentre provider to say that the address story is not merely in a contract; it is visible in the operational record.
The same evidence matters after the first month. A customer may add a second rack, move a firewall pair, shift a cache, split production from disaster recovery or ask for a new block for a sensitive project. Each change reuses the same public record. If the record is clean, the change feels routine. If the record is ambiguous, every change reopens diligence. The cost compounds because datacentre relationships are not one-time sales; they are recurring operational partnerships with constant small adjustments.
Together, these records affect financing and service valuation. Investors may not inspect every RDAP object, but they will care whether the process behind address-dependent revenue is reliable. Customers may not understand RPKI syntax, but they understand delayed migrations, blocked mail, failed allowlists and unresolved abuse tickets. AFRINIC's day-to-day evidence quality therefore has an economic value beyond registry membership. It helps convert technical resources into bankable recurring revenue.
Scarcity changes build-versus-buy decisions at the rack edge
Address scarcity reaches into architecture. Customers that once expected dedicated public addresses for many services may be pushed toward shared gateways, NAT, load balancers, proxies, private connectivity, IPv6-first services or managed platforms. Some of those choices are efficient. Scarcity can remove waste. It can also push designs that look economical on paper and fragile in operations.
A managed-service provider can conserve addresses by placing many tenants behind shared infrastructure. That may work for low-risk hosting. It can be poor for customers that need strict logging, dedicated reputation or audit separation. A security provider can share egress, but incident response becomes harder when many customers use the same public endpoints. A disaster-recovery provider can minimise standby addresses, but failover becomes more complex if public endpoints must be created or remapped during the outage. A bare-metal provider can charge extra for dedicated IPv4, but the product may become less competitive against regions where addresses are easier to package.
The edge of the rack is where these decisions become visible. Does the customer get a dedicated firewall interface or a shared one? Are services mapped one-to-one or through translation? Can addresses move if the customer changes halls? Is reverse DNS under the customer's name or the provider's? Can logs support abuse attribution? Will the design pass a bank audit? Can the provider migrate the customer between sites without changing public identity? IPv4 scarcity turns each question into a commercial trade-off.
The build-versus-buy decision is also affected. A company may choose colocation because it wants control, dedicated equipment, compliance comfort or predictable performance. If address scarcity forces it into provider-managed shared layers, the distinction between colocation and platform service narrows. That can be acceptable if the customer wants abstraction. It can weaken the value proposition if the customer came to colocation to preserve independence from a platform's network identity.
Operators can respond with address-aware products. They can offer portability tiers, dedicated pools, IPv6 transition support, reputation-clean packages, reverse-DNS management, RPKI assistance, customer-owned resource onboarding and migration planning. Those services can create revenue. They also require precision. If the operator oversells portability or hides lease dependency, the product becomes a future dispute.
Disaster recovery shows the tension. The customer may pay for capacity that is mostly idle because it wants assurance under stress. That assurance is undermined if public endpoints, DNS, firewall rules and partner allowlists cannot be activated in the same window as compute and storage. A provider may be tempted to conserve scarce IPv4 by assigning addresses only during failover. That can work for some services, but it is a poor substitute for tested standby identity where payments, emergency communications, health services or public-sector systems are involved. Address scarcity therefore changes the price of resilience, not only the price of ordinary hosting.
A predictable AFRINIC environment makes these products easier to design honestly. Customers can see whether they are buying provider-assigned space, customer-owned space, leased space, transferred space, temporary migration space or non-portable managed identity. An uncertain environment encourages vague promises. Vague promises can fill racks in the short term and damage trust when a customer tries to move.
Leasing can support growth, but opacity turns it into hidden fragility
IPv4 leasing is a practical response to scarcity. It lets operators match address supply to demand without buying permanent inventory for every temporary project, migration, startup, testing environment or early-stage service provider. In capital-constrained markets, leasing can make local datacentre demand appear sooner than it otherwise would. The problem is not leasing as such. The problem is opacity around who controls records, how long the arrangement lasts and what happens to customers if the lease is disrupted.
A tenant may believe it has bought a stable hosting service while the provider relies on a short-term address arrangement. If renewal fails, reverse DNS is withheld, abuse contacts are disputed or the lessor's standing changes, the tenant may suffer even though it never negotiated the lease. The hidden dependency becomes visible only during incident response, migration or renewal. By then, the tenant's public endpoints may be embedded in partner systems.
Opaque leasing can distort competition. A provider using cheap but uncertain address space may underprice a provider that buys cleaner inventory or maintains stronger controls. Customers choose the cheaper offer because the risk is not visible. Later, if records cannot be changed or addresses are withdrawn, the customer pays through disruption. The market then rewards hidden leverage instead of operational quality.
The safer position is evidence discipline. The public record should make the responsible party, operational contact and routing basis clear enough for counterparties to act. The customer should know whether its service depends on addresses it can carry, addresses controlled by its provider or addresses leased from a third party. The provider should know whether reverse DNS, abuse contacts and route evidence can be maintained throughout the service term.
AFRINIC can help by keeping recognition processes predictable without pretending every lease is a permanent transfer. It can support accurate contacts, route evidence and responsibility for abuse while retaining the ability to correct false claims. What it should avoid is creating such uncertainty around visible address use that leasing retreats into private arrangements no customer can evaluate.
For African datacentres, the leasing question is tied to customer diversity. Smaller MSPs, hosting companies and regional software providers may need leased space to compete. If registry uncertainty makes leasing unreliable, they become more dependent on larger operators. If leasing is allowed but poorly evidenced, their customers inherit risks they cannot price. Growth can tolerate scarce inventory better than it can tolerate invisible dependency.
Address disputes can freeze otherwise productive capital
A datacentre project turns capital into capacity before it turns capacity into revenue. Buildings are financed, equipment is ordered, power and cooling are built, staff are hired, carriers are brought in and anchor customers are courted before the hall is full. Anything that freezes customer activation therefore freezes productive capital. Address disputes are dangerous because they can do that while leaving the physical asset intact.
Consider a regional application company that has taken several racks for production and disaster recovery. The provider plans to use a particular address block. If the block's records are challenged, if reverse DNS cannot be changed, or if counterparties hesitate to accept the route evidence, the customer cannot simply swap in another scarce block without cost. Firewalls, certificates, monitoring, partner allowlists, payment interfaces and documentation may need revision. The migration window slips. The racks are occupied but not fully productive.
At scale, this becomes a coordination failure. The region may have invested in power, fibre, buildings and skilled staff, yet address uncertainty prevents the infrastructure from being fully used. Each participant can act rationally: the registry protects the record, the provider protects its contract, the customer protects uptime, the carrier protects routing policy, the investor protects capital. The combined result can still be underused capacity.
The AFRINIC controversies since 2019 illustrate the risk without resolving every contested claim. Public reporting and legal materials have described address-record allegations, disputes involving major address holders, court proceedings, receivership, interrupted elections and recovery efforts. The relevant point is not to decide each dispute in a datacentre article. It is that registry records now sit close enough to commercial value that legal and governance disruption can affect operational planning far beyond the immediate parties.
Continuity during dispute is therefore an economic function. A registry should be able to preserve accurate public evidence while contested matters are handled. It should distinguish preventing fraudulent change from freezing legitimate production use. It should minimise collateral harm to downstream customers that rely on addresses for live services. It should provide enough status clarity for counterparties to act without rumours. A dispute process can be legally active and still operationally vague; that vagueness is costly before any final decision.
For investors, the question is resilience. Buildings can be insured. Generators can be tested. Cooling redundancy can be engineered. Public record credibility is harder to insure after the fact. The better mitigation is institutional design: bounded authority, clear records, reviewable decisions and a culture that treats continuity as part of the registry's duty to the market it serves.
The danger is permission politics disguised as development policy
Every infrastructure institution develops public-purpose language. In address governance, the vocabulary includes stewardship, conservation, fairness, need, anti-abuse, community and regional development. These concepts have legitimate uses. They can also blur the line between maintaining a neutral evidence layer and deciding which commercial activities deserve address continuity.
Datacentre demand increases the temptation. When IPv4 addresses are scarce and valuable, every recognition decision looks distributive. Some may argue that addresses used by colocation, hosting, leasing platforms, content caches or cross-border services are less deserving than addresses used by access networks or public institutions. Others may treat market price as the only honest allocation method. Both positions can become slogans. The practical test is more precise: does the registry action improve the accuracy, uniqueness and continuity of the record, or does it turn scarcity politics into discretionary permission?
Permission politics does not require overt expropriation. It can appear through slow approvals, unclear criteria, broad interpretations of need, reluctance to recognise transfers, pressure against disfavoured address uses or uncertainty about whether records survive governance turbulence. Each mechanism may be defended as policy. The commercial effect is to make datacentre capital wait for permission rather than rely on evidence.
That is dangerous for local hosting because datacentre assets are immobile. Once a hall is built, it cannot be moved to a friendlier registry environment. If address recognition becomes unpredictable, investors must accept lower utilisation, hold more buffer inventory, depend on larger partners or avoid the market. Customers may keep sensitive workloads offshore even when they prefer local latency or domestic hosting. Foreign platforms with existing address resources may gain leverage over local entrants.
This is not an argument for registry passivity. False records, hijacking, stale contacts, abuse evasion and fraudulent claims damage honest operators. A registry that cannot correct them is not neutral; it is weak. The distinction is between specific, evidenced, reviewable correction and a general authority to approve or disapprove the business model attached to an address.
The datacentre sector needs that distinction because its uses of addresses are varied. A colocation operator may assign addresses to enterprise tenants. An MSP may sub-allocate to many small customers. A content cache may need stable local endpoints. A disaster-recovery provider may reserve capacity for rare but critical events. A security company may need dedicated addresses for sensors and portals. A bare-metal host may treat addresses as product inventory. These uses should be judged by record accuracy, contact responsibility, routing authorisation and customer disclosure, not by a simple moral ranking of business models.
The African colocation premium will be set by certainty
The next phase of African datacentre growth will not be decided by address policy alone. Power constraints, currency risk, regulation, carrier density, enterprise demand, cooling economics and land availability will all matter. Within the address layer, however, the decisive question is whether customers treat AFRINIC-region public IPv4 as a reliable input or as a risk requiring discount, premium or avoidance.
That premium will be negotiated in ordinary commercial moments. A bank asks whether its disaster-recovery site can keep stable endpoints. A hosting company decides whether to accept a short lease. A content platform checks whether reputation systems will treat a range as clean. An MSP decides whether it can promise tenant portability. A bare-metal provider sets default allocation sizes. A security firm asks who will receive abuse reports. None of these decisions is dramatic. Together they decide whether the hall converts demand into durable services.
If certainty improves, the premium can become productive. Operators can charge explicitly for scarce IPv4, clean reputation, portability support, reverse DNS management and routing assistance. Customers can compare offers. Investors can model address costs as part of service design. Leasing and transfers can function with clearer documentation. IPv6 adoption can proceed as a rational architecture choice rather than as an emergency escape from institutional ambiguity. Scarcity remains, but it is priced and governed.
If certainty weakens, the premium becomes defensive. Operators hold more buffer inventory than needed. Customers demand warranties that providers struggle to give. Smaller service providers become dependent on larger address holders. Leasing becomes more private. Transfers carry larger legal discounts. Some workloads remain offshore. Public controversies produce caution beyond the parties directly involved. The sector still grows, but growth is more concentrated and more expensive.
The difference will be determined less by speeches than by mundane evidence: whether RDAP and WHOIS records are current, whether reverse DNS delegations are predictable, whether abuse contacts work, whether RPKI and route records can be maintained, whether transfers are recognised without unnecessary drama, whether disputes preserve operational continuity and whether the registry resists turning scarcity into broad commercial permission.
The market signals from Teraco, Africa Data Centres and Digital Realty show that African colocation is no longer too small for this question. Carrier counts, customer counts, interconnect figures, multi-city footprints and IT-load claims may be marketing, but they reflect a denser service chain. In a thin market, a weak record irritates a few operators. In a dense market, the same weakness can slow many customers at once.
AFRINIC is therefore a test case for how datacentre growth changes registry economics. The older question was how to allocate scarce addresses fairly. The newer question is how to preserve address identity continuity for a market in which addresses are embedded in capital investment, customer migration, service reputation, MSP offerings, bare-metal inventory, disaster recovery and local-compute strategy. A registry that answers as a neutral ledger helps African datacentres turn demand into durable infrastructure. A registry that answers as a gatekeeper makes every new hall carry an invisible surcharge.
The operator fitting out the hall does not need a theory of internet governance. It needs to know whether the next customer can be turned up cleanly. It needs address records that survive ordinary business events, dispute processes that do not paralyse production services and a regional registry whose authority is strong because it is bounded. If AFRINIC can supply that certainty, datacentre address demand becomes a manageable cost of growth. If it cannot, IPv4 scarcity will do more than raise prices. It will help decide who can fill the racks.