The request reaches the abuse desk at the worst possible hour, when one thin report can become the whole room. A foreign service has reported account takeover traffic from one public IPv4 address. A bank has sent a lawful request about a transaction that appears to come from the same address. A game provider has blacklisted that address after automated logins. A residential customer, who has never heard the term carrier-grade NAT, is waiting in the support queue because his console says the network is "strict" and will not join a match. The public address is real. The users behind it are many. The decisive facts are not the address alone, but the source port, the timestamp, the time standard, the translation gateway, the pool, the retention period, the account record and the staff member allowed to query the log.
That is where the hidden tax appears. It is not the registry fee. It is not the quoted price of a public address in a transfer or leasing market. It is the operating bill created when IPv4 scarcity forces a network to put many subscribers behind fewer public identifiers. Carrier-grade NAT conserves public IPv4, and in post-exhaustion markets it is often unavoidable. But it does not abolish scarcity. It changes the form in which scarcity is paid.
The tax is paid in translation platforms, redundancy, logging systems, storage, time synchronisation, access controls, legal review, privacy governance, abuse desks, reputation repair, help-desk training, enterprise exceptions, static-address tiers, broken games, unstable VPN sessions, unreachable cameras, payment systems that misread shared identity, and customers who blame the access provider for failures created by an address economy they cannot see. The tax is hidden because it rarely appears as an address line item. It lands in security, compliance, customer care, engineering, product management and reputational risk.
AFRINIC is a useful setting for this argument because the African and Indian Ocean registry region combines large connectivity needs, uneven public IPv4 holdings, serious IPv6 ambitions and a registry layer whose recent history cannot be treated as administrative wallpaper. AFRINIC is the Regional Internet Registry serving Africa and parts of the Indian Ocean region. Its own exhaustion material records that IPv4 Exhaustion Soft Landing Phase 2 began on 13 January 2020, with Phase 2 requests constrained between a /24 minimum and a /22 maximum per allocation or assignment. A /22 is small against the address needs of growing access networks, public services, payment ecosystems and enterprise customers. That fact does not explain every CGNAT deployment in the region, but it defines the scarcity regime in which operators plan.
The recent institutional context also matters, but it must be handled carefully. Public reporting has described alleged African IPv4 address misappropriation, the Cloud Innovation dispute, account freezes, Mauritius litigation, receivership, election disputes, later board recovery reporting and ICANN intervention in a winding-up context. Some of those accounts involve contested claims, party statements and unresolved legal positions. They should not be read as final findings on every dispute. For CGNAT economics, the narrower point is enough: when the registry layer is legally or politically uncertain during the same period in which IPv4 has become scarce and valuable, operators plan more defensively. They conserve harder, promise less, log more, separate customer classes more sharply and keep more public address capacity for exceptions.
The argument here is narrow. CGNAT is not a moral failure, and it is not a cheap substitute for sound scarcity policy. It is a conservation machine with an economic surface of its own. The more public IPv4 becomes scarce, valuable, contested and institutionally uncertain, the more networks ration it through translation. The more they ration through translation, the more costs move into places that address policy debates often fail to measure.
The invoice starts with a missing port number
The public internet still begins many investigations with an IPv4 address. Abuse reports, fraud reviews, payment disputes, account-recovery cases, lawful requests, content-platform blocks and enterprise security tickets often start with a simple question: what used this address at this time? In a one-customer-one-address arrangement, the question may still be imperfect, but it is at least legible. In a CGNAT estate, the same public address may represent many subscribers during the same minute. The missing field is usually the source port.
The port is not a specialist's footnote. It is the difference between a useful lead and a room full of unrelated customers. If the complainant provides only an address and a vague timestamp, the operator may be unable to identify the subscriber with confidence. If the timestamp is in local time while the logs are in UTC, if daylight-saving assumptions have been copied from another jurisdiction, if the clock on one translation gateway drifted, if the gateway failed over without clean correlation, or if the log rotated before the request arrived, the operator has conserved an address but weakened attribution.
That weakness has a price. The abuse desk may ask the complainant for more information. The legal team may narrow or refuse a request. The bank may add friction to a customer account. The remote service may keep the address blocked. The help desk may tell innocent users to reboot a router, change a password or buy a static public address, even when the real problem is that many unrelated flows shared one public identifier. Each step consumes labour and trust.
The hidden tax begins because the address bill and the operational bill are separated. A policy that limits new public IPv4 allocation can be described as conservation. An operator that deploys CGNAT can be described as efficient. Both descriptions may be true. But efficiency at the address ledger has moved work into the attribution ledger. The question for institutional economics is not whether the work is technically possible. It is who pays, who sees the cost, and who has reason to reduce it.
In AFRINIC's region, the answer will vary by network type and customer mix. A national carrier may have dedicated security operations, lawful-access intake, centralised logging and trained support teams. A regional access provider may face the same evidence demands with less staff capacity. A fixed-wireless network may receive remote-camera, gaming and VPN complaints. A hosting provider may avoid shared translation for customers whose product is inbound reachability. A government or education network may need documented public egress for audit reasons. The tax is not identical across networks, but the mechanism is common: scarce public identity is pooled, and pooled identity must then be explained.
The port number is therefore the smallest visible piece of a larger institutional bill. It tells the outside world that the public address is no longer a sufficient identifier. It also tells the operator that every conservation decision creates a new evidence dependency. A public address saved at the planning table can become a port dispute at the abuse desk. The registry does not see that dispute in its ordinary allocation statistics, but the network pays it.
CGNAT turns scarcity into an operations business
Carrier-grade NAT is often introduced as a technical workaround for IPv4 exhaustion. That description is too small. A CGNAT deployment is an operations business inside the network. It decides which internal addresses reach the public internet through which public pools, under which port policies, with which session persistence, redundancy, logging, exceptions and support obligations. It is a scarcity rationing system that happens to be implemented in packet-processing equipment.
The business has capital costs. Translation gateways must be bought, licensed, operated or built. They must be sized for busy-hour traffic, not for comfortable averages. They must fail over without turning one device fault into a national service problem. They need monitoring, security patching, capacity planning, vendor support, DDoS planning, spare capacity and staff who understand the failure modes. The operator may save public IPv4, but it buys statefulness at scale.
It also has working-capital costs. Logs must be retained long enough to answer lawful and abuse requests, but not so indiscriminately that the operator creates unnecessary privacy exposure. Storage must be reliable. Queries must be auditable. Access must be limited. Time sources must be disciplined. Customer provisioning data must match translation records. If an operator serves multiple jurisdictions, it must understand which authority can request what, which customer data may be disclosed, which retention period applies and which internal approvals are required.
Then come commercial costs. CGNAT changes the product catalogue. Basic broadband can be sold behind shared public egress. Customers who need inbound reachability may need a public IPv4 add-on. Some business customers may require static addresses, documented egress ranges, managed VPNs, reverse-DNS handling or separate pools. A feature that once felt like an assumed part of internet access becomes a differentiated product. The same address scarcity that is invisible in the retail headline becomes visible as tiering, caveats and exceptions.
This is not irrational. Scarce inputs are rationed. The problem is opacity. If the scarcity cost is represented only as "we need IPv6" or "operators should conserve", the operational substitution is missed. CGNAT lets the network continue to grow, but it also turns public IPv4 scarcity into a system of queues, exceptions and explanations. Those queues may be fair or unfair. Either way, they exist.
AFRINIC's role is indirect. It does not design an operator's translation gateways. It does not write the support script for a game console. But AFRINIC maintains part of the public evidence that determines how scarce address resources are recognised, updated, delegated, transferred and trusted. In a post-exhaustion regime, a registry that keeps the ledger boring helps operators plan the translation business with fewer defensive buffers. A registry that becomes unpredictable increases the incentive to hoard public addresses, over-share active pools, shorten promises or avoid product commitments that depend on public identity.
The operational business created by CGNAT therefore sits between engineering and institution. A gateway vendor can sell throughput. A lawyer can write a retention policy. A support manager can write a script. A registry can keep the public record accurate. None of those functions alone captures the economic whole. The hidden tax is the fact that the whole must exist at all.
Phase 2 made conservation unavoidable, not free
AFRINIC's public exhaustion material records that the region entered IPv4 Exhaustion Soft Landing Phase 2 on 13 January 2020. In Phase 2, the minimum allocation or assignment is a /24 and the maximum is a /22 per allocation or assignment. Whatever one thinks of the soft-landing design, the economic message is plain. Large fresh IPv4 allocations are no longer the normal answer to growth.
A /22 contains 1,024 IPv4 addresses before reservations, infrastructure needs, routing practice and product segmentation. For a network adding tens of thousands or millions of customer sessions over time, such space is not expansion capital in the old sense. It is a scarce supplement, a reserve, a way to support essential public-facing needs or a small bridge. The main growth path must rely on conservation, upstream arrangements, transfers, leases, IPv6, product redesign or some combination of those.
CGNAT therefore becomes ordinary production. It is not only a panic response by networks that failed to prepare. It is a rational adaptation to a finite public address pool in a market where many customer systems still expect IPv4 compatibility. A network can be technically serious and still need translation. It can deploy IPv6 and still require public IPv4 egress for banks, public services, games, payment terminals, enterprise partners, cameras, VPNs and old devices.
The policy mistake is to treat conservation as if it were free because packets still pass. The packet may pass while the invoice moves elsewhere. Phase 2 can slow depletion and reduce waste, yet still increase operating complexity. A registry can say it is protecting the remaining pool for fair access, while operators pay in NAT platforms, customer segmentation, evidence management and exception handling. A customer can receive a cheaper broadband plan because public addresses are shared, while losing the ability to host, connect, game, tunnel or authenticate cleanly in some settings.
Those are distributional choices, not merely technical outcomes. Who receives scarce public IPv4 directly? Who buys or leases it? Who depends on upstream space? Who hides behind shared translation? Which customers receive public-address exceptions? Which complaints are treated as normal support and which become paid upgrades? The answers shape competition and customer experience without always being described as address allocation.
Phase 2 also interacts with institutional trust. If a network believes future access to recognised public IPv4 is predictable, it can ration openly. If it fears disputes, delays or uncertain record status, it will ration defensively. Defensive rationing is expensive. It encourages idle reserves, vague customer promises, short contract terms, denser sharing and higher margins on public-address products. Scarcity policy then creates a second scarcity: confidence.
The Phase 2 number matters because it forces managers to compare address increments with non-address budgets. If a new access product or enterprise service cannot be supported by a fresh public block, the budget debate moves elsewhere. Does the company buy another translation chassis? Does it license more logging capacity? Does it reserve cleaner addresses for payment, enterprise and public-service traffic? Does it put ordinary households into denser sharing? Does it create a public-IP add-on and accept the support burden of explaining why a once-assumed feature has become premium?
Those are economic substitutions, not mere engineering preferences. A clean scarcity regime would make them visible. A muddled regime makes them look like unrelated operating decisions. The NAT appliance appears in one budget. Storage appears in another. Legal handling appears in another. Static-address revenue appears somewhere else. Customer dissatisfaction is visible only after the customer calls or leaves. A /22 maximum allocation does not cause every one of those choices by itself, but it is one formal fact that tells operators the old allocation era has ended.
Ports, pools and reputation are the rationed units
The public IPv4 address is the visible scarce resource, but the source port is often the smaller unit of CGNAT economics. One address offers a finite set of usable transport ports. In practice, capacity is reduced by protocol behaviour, reserved ranges, allocation methods, session timeouts, endpoint filtering, abuse controls, heavy users and application assumptions. The operator is not merely sharing addresses. It is allocating port opportunity under uncertainty.
Port scarcity first appears as quality variation. A light web user may never notice. A household with many devices, a gamer, a remote worker with several VPN sessions, a developer pulling containers, a small office using collaboration tools, a camera system with persistent sessions or a merchant terminal expecting predictable connectivity may notice quickly. Some applications open many short-lived connections. Some expect inbound reachability. Some fail gracefully. Some fail in ways that look random to the customer.
The operator can respond by changing port limits, using paired address pooling, adjusting timeouts, separating heavier users, adding public addresses, offering static public IPv4 or moving traffic to IPv6 where the counterparties support it. Each response has a cost. Generous port allocation improves experience but consumes scarce public-pool capacity. Tight limits conserve capacity but increase support cases. Sophisticated allocation reduces breakage but requires equipment, expertise and monitoring. Static-address add-ons generate revenue but raise fairness and disclosure questions.
Port scarcity also creates reputational coupling. If one public address carries many customers, behaviour by one customer can affect others. A spam burst, credential attack, malware infection, aggressive crawler or compromised camera can trigger blocks that hit innocent users sharing the same egress. The operator may be able to identify and discipline the source internally, but external systems often act first at the public address level. Customers sharing the address pay a reputational tax before the operator can unwind it.
That tax is hard to price because it is probabilistic. It appears as intermittent login challenges, platform blocks, payment friction, customer irritation, enterprise hesitation and cautious abuse handling by upstreams or remote services. It does not look like a simple outage. It looks like a decline in the reliability of being recognised by the rest of the internet.
This is why remaining public IPv4 cannot be treated as an undifferentiated pool. Some addresses have cleaner reputation, better geolocation, more stable reverse DNS, known enterprise use or better separation from high-risk traffic. Scarcity makes those qualities valuable. CGNAT multiplies the value because one tainted public address can carry many innocent users into someone else's risk model.
For AFRINIC, the lesson is not to specify port policies. A registry should not become a NAT architect. The lesson is that public-address scarcity has downstream externalities. If policy treats one address as one address, while operations experience it as a bundle of ports, logs, reputation and exceptions, the policy will underestimate the cost of conservation.
The reputational part is especially important for operators with thin public pools. A provider with little spare capacity may have fewer ways to rotate away from a tainted egress address or to reserve clean addresses for customers with stricter requirements. The customer does not see a shortage of port opportunity or clean reputation; the customer sees a blocked game, a failed payment, a rejected login or an allowlist problem. The hidden tax is paid in the gap between those two descriptions.
Attribution becomes an evidence factory
CGNAT breaks the casual habit of equating a public IPv4 address with a subscriber. It does not make attribution impossible. It makes attribution an evidence factory. The factory needs external address, external port, timestamp, protocol, translation gateway, internal address, subscriber or circuit identifier, time synchronisation, retention policy, query authority and audit trail. It also needs staff who know when the answer is strong and when it is not.
The first pressure comes from abuse. Complaints about spam, scanning, phishing, credential attacks, scraping, botnet traffic or copyright enforcement may identify only the public address. Better reporters include source port, exact timestamp, protocol and context. Many do not. The operator must decide how much effort to spend on incomplete reports. Too little effort damages reputation. Too much effort consumes staff time and may create privacy risk if weak reports trigger excessive lookup.
The second pressure comes from commercial disputes. A marketplace may suspend a merchant account. A payment provider may flag transactions. A game publisher may ban an address range. A streaming service may misplace a user. A cloud service may rate-limit API calls. The customer sees an access problem; the operator sees a shared-identity problem. The evidence needed to persuade the remote service may be different from the evidence needed for internal attribution.
The third pressure comes from lawful requests. Here the stakes are higher. The operator must protect customers from overbroad demands while complying with valid law. CGNAT makes sloppy requests more dangerous because the wrong port or wrong time can point to the wrong person. A request that would have been adequate in a one-address-per-customer setting may be inadequate in a shared-address setting. The operator has to educate counterparties without appearing obstructive.
The evidence factory is expensive because it must be both available and constrained. Logs that cannot be queried are useless. Logs that anyone can query are dangerous. Logs retained too briefly may fail legitimate investigations. Logs retained without discipline may create a surveillance liability. Logs not tied to reliable time are weak. Logs not tied to customer provisioning records may be ambiguous. Logs not protected from tampering may be challenged.
The public registry record is only the first page of this factory. It should tell the outside world which network is responsible for a public resource and how to reach it. If that record is stale or disputed, the factory starts with friction. If the record is accurate, it does not solve attribution, but it sends the request to the right door. In a CGNAT world, sending requests to the right door is already economically significant.
The quality of incoming evidence also changes operator incentives. A platform that sends address, source port, destination, exact UTC timestamp and log context helps the operator act quickly. A platform that sends only an address and a day produces cost without precision. Repeated low-quality reports can train operators to discount complaints, while repeated public blocks can train platforms to treat whole address ranges as suspect. Both behaviours are rational responses to bad evidence. Both make shared-address operations more expensive than necessary.
This is why a serious post-exhaustion culture should talk about evidence standards as much as allocation limits. Public networks cannot be expected to identify customers from fields they never receive. Lawful authorities and large services should understand that port and time precision are not optional courtesy fields in a CGNAT environment. They are the minimum data needed to avoid punishing the wrong user. A registry that maintains good public contacts can help route evidence, but the wider ecosystem must learn how shared identity works.
Lawful access and privacy sit on the same log line
The same CGNAT log line can be read in opposite ways. To a lawful authority investigating a crime, it is the path from a public address to a subscriber. To a privacy officer, it is sensitive infrastructure data that can expose behaviour if mishandled. To a network engineer, it is a troubleshooting artifact. To a CFO, it is storage and compliance cost. To a customer, it is invisible until something goes wrong.
That is the institutional problem CGNAT creates. Address conservation pushes more people behind fewer public identifiers, which increases the evidentiary value of translation logs. The more valuable the logs become, the more carefully they must be governed. The operator is asked to be efficient, compliant and privacy-preserving at the same time. None of those duties is optional.
Retention periods show the trade-off. If logs are retained for too short a period, valid requests arrive too late. If they are retained for too long, the operator accumulates risk. If the retention period differs by service tier, customer type or jurisdiction, support and legal teams must understand the differences. If logs are compressed, indexed or archived badly, retrieval may be slow or incomplete. If logs are stored with too much destination detail, the privacy stakes rise. If logs are too sparse, attribution may fail.
Access control is another example. A small number of authorised staff should be able to query logs for defined purposes. Their actions should be recorded. Emergency access should exist but be reviewed. Bulk export should be rare. Requests should be classified. The legal basis should be documented. Customer-notification rules, where applicable, should be understood. These are not exotic requirements for a large carrier, but they become heavy for networks that adopted CGNAT because public IPv4 was scarce, not because they wanted to build a compliance department.
The hidden tax is therefore institutional capacity. A network using CGNAT at scale must behave like a disciplined evidence custodian. It may not receive extra margin for doing so. Retail customers compare broadband prices and speeds, not log-governance maturity. Enterprise customers may ask harder questions, but often only after an incident. Regulators may impose obligations without understanding the address-sharing architecture. Courts may receive IP evidence without appreciating the need for ports and precise time.
Scarcity policy should acknowledge this chain. When public IPv4 access is constrained, networks share. When networks share, attribution moves from simple public records to complex logs. When attribution moves to logs, lawful-access and privacy costs increase. A registry cannot manage those costs for operators, but it can stop pretending that conservation is only a matter of fair allocation. It is also a matter of operational externalities.
The tension is not solved by keeping fewer logs or by keeping everything forever. It is solved by discipline: clear retention, precise requests, limited access, tamper-resistant systems, trained staff and honest product language. Every one of those controls costs money. The policy debate sees a public address conserved; the operator sees a regulated evidence system that must now exist because the address was conserved through sharing.
Abuse desks pay for the behaviour of strangers
An abuse desk in a CGNAT environment handles other people's ambiguity. A complaint may be sent by a service that sees only one public address. It may be sent by an anti-abuse feed that has already scored the address as risky. It may be sent by another operator that does not provide ports. It may be sent by a victim who copied logs from a firewall. It may be automated, malformed, duplicated or emotionally written. The desk must triage all of it.
The economic asymmetry is sharp. The remote service can block the public address quickly. The operator must investigate slowly. If the operator ignores weak complaints, its ranges may suffer. If it investigates every weak complaint, it spends labour on reports that may not identify a customer. If it disciplines the wrong customer, it creates legal and reputational risk. If it cannot explain the case to the complainant, the address reputation may remain damaged.
Shared public identity also changes the language of responsibility. A complaint about one address may be a complaint about one infected device, one compromised customer router, one abusive user, one malware family, one reseller, one enterprise NAT behind the operator's NAT, or a false positive by the complainant. The public address alone cannot distinguish those possibilities. The operator must convert external accusation into internal evidence.
That conversion becomes more expensive as sharing ratios rise. Higher ratios do not automatically mean bad practice. They may reflect customer behaviour, IPv6 offload, port management and public address scarcity. But higher ratios raise the number of innocent users exposed to a public-address block and the amount of internal evidence needed to isolate a source. If public IPv4 is difficult to obtain or uncertain to hold, operators may accept denser sharing than they would otherwise choose.
Abuse handling also interacts with registry records. AFRINIC's policy manual includes abuse-contact provisions in the registry context, and AFRINIC provides WHOIS and RDAP services that help identify responsible resource holders. Those public contacts matter more when CGNAT makes address-level complaints less precise. A good registry contact does not tell the complainant which subscriber caused the traffic. It prevents the complaint from wandering through stale or wrong contact paths before the operator can even start.
The reported African IPv4 address misappropriation cases show why contact and record integrity matter. KrebsOnSecurity and MyBroadband reported allegations around manipulated or improper registration records and address ranges with substantial market value. AFRINIC and other parties responded in different ways over time, and the public record contains investigation, denial, litigation and correction contexts rather than one simple story. The point for CGNAT economics is not to relitigate every allegation. It is that address records carry market and operational value. If records are wrong or can be made wrong, abuse handling becomes more expensive, and shared-address operations become harder to defend.
This is the abuse-desk version of the hidden tax. The network pays for outside systems that still treat an address as a single identity. The desk pays again when those outside systems send evidence that cannot support action. The customer pays when a shared address is blocked before the operator has time to prove who did what. The registry pays reputationally when its records fail to route complaints to the right responsible party. None of these costs is visible in the simple count of addresses conserved.
Customers discover the tax when applications fail
Most customers do not complain about CGNAT as a concept. They complain about symptoms. A console cannot host a game. A remote camera cannot be reached from outside. A home worker's VPN disconnects. A small business cannot receive inbound connections. A bank login triggers extra checks. A payment terminal appears from an unexpected location. A website says too many users are coming from the same address. A smart-home service works for months and then fails after a firmware update.
The support desk receives these failures as separate products. Gaming, VPN, camera, payment, remote desktop, peer-to-peer, hosting, geolocation, streaming, fraud detection and email reputation may each have a different script. Underneath, many share the same root: the customer does not have unique public IPv4 identity or predictable inbound reachability. The public address is shared, the port mapping is transient, the remote service is suspicious, or the customer is behind multiple layers of translation.
AFRINIC's policy manual itself recognises the broad technical point in its description of private IPv4 address space: private addresses cannot be reached from the internet unless enabled through NAT, and some internet services may not work properly under NAT. That is a modest sentence in a policy manual, but in customer service it becomes a large practical truth. At scale, "some services may not work properly" becomes a support category, a product tier and a source of churn.
The operator can educate, but education is costly. "You are behind CGNAT" is not a satisfying answer to a customer who bought broadband to use applications. "Buy a static public IP" may be correct, but it can sound like an upsell for something the customer assumed was included. "Use IPv6" may be technically elegant, but only if the application, device, remote network and customer knowledge support it. "Contact the remote service" may be true and useless.
The result is a support externality. The registry conserves scarce public addresses. The operator deploys NAT. The remote application fails to adapt. The customer calls the operator. The operator becomes the face of a multi-actor compatibility problem.
This externality is not evenly distributed. Customers with money can buy static public IPv4, business service, managed VPN, hosted relay, enterprise support or a different provider. Customers on low-cost plans receive scripts, workarounds and limits. Small businesses often sit awkwardly between the two: sophisticated enough to need reachability, too small to have network staff, and price-sensitive enough to resist enterprise products.
That segmentation is part of the hidden tax. It turns public identity into a class marker. Basic connectivity remains available, but certain uses become paid exceptions. Some of those exceptions are economically justified. Public IPv4 is scarce, and a customer who needs it for revenue-generating work should expect to pay more than a casual web user. The fairness problem arises when the scarcity is obscured, when support scripts blame customers, or when public debates pretend that CGNAT fully substitutes for address availability.
AFRINIC should not decide which gamers, camera owners or small businesses deserve public IPv4. It should keep the resource ledger accurate enough that operators can build transparent products around scarcity. The operator should then make the trade-off clear: shared IPv4 for ordinary use, paid public identity where needed, IPv6 wherever it genuinely solves the use case, and honest support language when it does not.
Enterprise exceptions reveal public IPv4 as a premium feature
Enterprise customers expose the price of public identity because they write requirements down. A retailer may need payment terminals to appear from documented egress addresses. A logistics firm may want remote access to depots and vehicles. A hospital vendor may insist on allowlisted endpoints. A bank branch may require traceable address behaviour. A government agency may need evidence for audits. A broadcaster may need field equipment reachable under time pressure. A hotel may need public IPv4 for cameras, point-of-sale systems or guest-network exceptions.
CGNAT can support many enterprise products if designed carefully, but it cannot make public identity infinite. The operator must decide which customers receive static public IPv4, which receive private connectivity, which receive managed VPNs, which receive IPv6-first designs, and which remain behind shared egress. Those decisions become pricing decisions. Public IPv4 moves into the premium tier.
The premium tier is not merely rent extraction. It funds scarce inventory, better logging, support, cleaner pools, reverse-DNS maintenance, abuse response and contractual certainty. If the price is transparent and alternatives are real, the tier can allocate scarcity efficiently. But it also creates incentives to preserve ambiguity. A provider may market "business internet" without clearly stating whether the customer receives unique public IPv4. A reseller may depend on upstream address arrangements it does not control. A customer may discover the limitation only when a partner asks for an allowlist or an incident report.
Enterprise exceptions also make registry certainty more valuable. A multi-year enterprise contract tied to public IPv4 depends on stable control of the underlying resource, clear contacts, working delegation, predictable transfer or lease evidence and the absence of avoidable disputes. If the address source is uncertain, the operator may shorten commitments, add caveats, charge more or reserve the cleanest space for the largest customers. Smaller enterprise customers then face a thinner product.
AFRINIC's post-exhaustion environment intensifies this because new space is constrained. A network that cannot rely on future allocations must husband public addresses for customers who pay for evidence. That may be rational, but it can also widen market gaps. Large incumbents with older holdings can offer richer public-address products. Providers with thinner inventory may lean more heavily on CGNAT and upstream arrangements. Customers who need public identity may follow the address inventory rather than the best access network.
This is where the hidden tax becomes a competition issue without changing the centre of the article. The cost is not simply that some customers pay for static IPv4. It is that public-address scarcity shapes which providers can credibly serve customers that require documented identity, inbound reachability or clean egress. A registry that remains a neutral, predictable ledger cannot erase historical inequality in address holdings. It can at least prevent uncertainty from adding another premium for firms without deep legacy inventory.
The premium feature should therefore be named rather than smuggled. If a plan includes shared egress, say so. If inbound reachability requires an add-on, say so. If an enterprise service includes static public IPv4, reverse DNS and documented logs, price it as an evidence product. The public address is not just a number. Under CGNAT economics, it is a bundle of trust, reachability, reputation and operational response.
Support scripts become a second address plan
In a mature CGNAT network, the support script becomes a second address plan. The first plan maps private, shared and public resources through gateways and pools. The second maps customer complaints to explanations, tests, escalation paths and paid exceptions. If the second plan is poor, the first plan looks unreliable even when the engineering is sound.
Consider a remote-camera complaint. The customer may say the camera worked with a previous provider and now cannot be reached. The agent must know whether the customer is behind CGNAT, whether the camera vendor offers relay service, whether IPv6 is enabled, whether a public IPv4 add-on exists, whether inbound ports are blocked, whether the customer router is double-translating, and whether the customer's plan permits hosting. Without that knowledge, the call becomes ritual: reboot, reset, blame the camera, escalate.
Gaming is similar. Strict NAT warnings are often reduced to consumer frustration, but they reveal address-sharing economics. Some games and consoles handle shared environments better than others. Some use relays, some need peer-to-peer reachability, some are sensitive to symmetric behaviour. The operator can tune, but not perfectly. A support script that explains the limitation and offers a defined path is cheaper than repeated confusion.
VPN and remote-work cases are harder because the customer may be technically competent enough to know something changed but not enough to see every layer. Corporate VPNs, IPsec, SSL VPNs, split tunnelling, multi-factor systems and endpoint security can all interact with NAT behaviour. If the employer's security system treats shared egress as suspicious, the residential ISP becomes the support counter for another organisation's risk model.
Payment and banking complaints carry more reputational risk. A merchant whose transactions fail may not accept "shared address reputation" as an answer. A bank that sees multiple accounts from one public address may increase friction. A customer who receives fraud challenges may assume the operator sold a defective service. The support team must handle the human side of a technical ambiguity.
The second address plan should therefore be explicit. Operators should classify which plans are behind CGNAT, which support inbound connections, which include static public IPv4, which support IPv6, which use shared public pools, and which are unsuitable for certain applications. That classification should be available to sales, support, enterprise account managers and abuse teams. It should not be hidden in engineering diagrams.
The institutional implication is modest but important. If registry scarcity pushes operators toward CGNAT, then product transparency becomes part of the public-interest outcome. A registry cannot write support scripts. But scarcity policy should be assessed partly by the support burden it creates and by whether operators have enough predictable address certainty to offer clear alternatives.
Support scripts are also where economics becomes language. The difference between "your camera is faulty" and "your plan uses shared IPv4, so inbound access needs a public address or a relay" is the difference between blame and disclosure. The difference between "try again later" and "the remote service has blocked a shared egress address; we are escalating reputation repair" is the difference between confusion and institutional competence. Hidden taxes are hardest to dispute when no one names them.
Measurement opacity hides the real incidence
The hidden CGNAT tax remains hidden because the usual measurements are too narrow. Address utilisation statistics may show conservation. IPv6 adoption statistics may show progress. Registry allocation records may show fairness by policy rule. None of these measurements tells the full story of how much scarcity costs inside operations.
The missing measurements are mundane. How many support tickets are caused by shared addressing? How many lawful requests arrive without source ports? How many abuse complaints lack usable timestamps? How many public addresses are blocked by remote services because of traffic from one user among many? How many customers buy static public IPv4 because an application fails behind CGNAT? How many enterprise sales are lost because the provider cannot offer documented public egress? How many engineering hours are spent adjusting port policies and explaining reputation issues? How many users churn after repeated false suspicion?
Operators may collect some of this data internally, but it is rarely part of public policy debate. It may be commercially sensitive. It may sit in different departments. Support sees symptoms, security sees complaints, legal sees requests, engineering sees gateway utilisation, product sees static-address revenue, finance sees capex and opex, and registry affairs sees address scarcity. No single ledger displays the tax.
This fragmentation matters because it lets policy moralise without accounting. A rule can be defended as conservation while its costs are dispersed. A transition speech can point to IPv6 while the help desk handles IPv4 compatibility. A registry can claim that small allocations are enough for efficient operators while enterprise teams ration public addresses among customers. A government can demand low prices and lawful traceability without paying for the systems that make shared-address traceability reliable.
Measurement does not require exposing customer data. Operators and registries could discuss aggregate categories: share of broadband lines behind CGNAT, support-ticket categories related to shared addressing, port-inclusive versus port-missing abuse reports, average response time for lawful requests requiring NAT logs, static-public-IP demand by customer class, IPv6 traffic share, and public-address exceptions for enterprise or public-service use. Even rough measurement would improve the debate.
For AFRINIC, this kind of evidence would support a better post-exhaustion conversation. The registry should not ask operators to reveal sensitive NAT maps. It can, however, recognise that IPv4 scarcity has operational incidence beyond allocation size. If members report that CGNAT is absorbing scarcity through rising support and compliance costs, that is not an argument against conservation. It is an argument for transparent transfer and leasing paths where policy allows them, reliable records, strong evidence standards and faster IPv6 progress where it genuinely reduces load.
The absence of measurement benefits incumbents and slogan-makers. Incumbents with address reserves can avoid some CGNAT pain while describing scarcity as manageable. Slogan-makers can invoke transition without counting coexistence. More exposed networks pay in silence. A serious scarcity policy should want the tax visible.
Consumer regulators would also benefit from better measurement. A broadband plan behind CGNAT is not automatically inferior, and forcing every low-cost plan to include unique public IPv4 would be economically absurd. But consumers should not be misled about applications that require inbound reachability or stable public identity. A market can tolerate different tiers if the tiers are named honestly. It becomes distorted when one provider hides the limitation, another discloses it, and customers cannot compare offers until a camera, VPN or payment device fails.
Public-sector buyers face the same problem at institutional scale. A school network, clinic, municipal office or local contractor may buy the cheapest service that passes a bandwidth checklist, only to discover later that audit, remote-support or partner-access requirements imply a different address product. The procurement failure is then blamed on the provider or the application, while the real issue is that address-sharing assumptions were never measured.
Registry risk makes NAT planning more conservative
AFRINIC's recent history matters to CGNAT planning because uncertainty at the registry layer changes the value of public IPv4 reserves. The issue is not whether every operator is directly involved in litigation. Most are not. The issue is that registry trust influences how aggressively operators can use, lease, transfer, document and promise scarce resources.
Public reporting has described several layers of AFRINIC stress. Investigative accounts around 2019 alleged major African IPv4 address misappropriation involving manipulated or improper registration records. The Cloud Innovation dispute became a prolonged legal and institutional conflict around large IPv4 holdings, service agreements and registry authority, with claims contested in courts and public argument. In 2021, reporting described bank-account freezes affecting AFRINIC in the context of litigation. Mauritius court proceedings later shaped the institution's governance path. The NRO welcomed a court-appointed receivership in 2023 as a route toward functional governance and continuity. Reporting in 2025 described election disputes, proxy concerns, annulment and renewed efforts to seat a board. Reporting in 2026 described signs of board recovery, budget and strategy work, further litigation, ICANN intervention in a winding-up context and continuing legal conflict.
These accounts should be handled cautiously. Public reports and party claims are not final findings on every contested matter. The economic lesson does not require treating one side's claims as complete truth. It is enough to observe that AFRINIC's registry layer has been subject to unusual governance, legal and continuity stress during the same era in which IPv4 became more scarce and valuable.
That stress changes NAT planning in several ways. Operators may hold larger public-address buffers because they doubt timely access to future recognised space. They may be reluctant to make long-term enterprise promises using space whose transfer, lease or record status could be questioned. They may build heavier CGNAT sharing to preserve public addresses for exceptional uses. They may spend more time on legal review of address arrangements. They may price registry uncertainty into products that seem, to the customer, like simple connectivity.
None of these responses requires a registry outage. Packets can keep moving while business caution rises. A NAT gateway can keep translating while an enterprise contract receives extra caveats. A customer can keep browsing while an operator delays an expansion because public-address certainty is weak. The cost appears in risk management, not downtime.
This is where the ledger-versus-gatekeeper distinction becomes practical. If AFRINIC is understood as a narrow ledger, its recovery task is to make records accurate, services predictable, disputes bounded and routine changes boring. If it is understood as a broad gatekeeper over commercial address use, every scarcity workaround becomes politically charged. CGNAT planning then absorbs not only technical scarcity but institutional discretion.
Operators do not need a registry to bless every NAT design. They need the registry not to surprise them. Predictable scarcity is expensive but manageable. Unpredictable scarcity encourages defensive architecture.
The distinction is important because registry risk compounds with CGNAT density. If an operator trusts its public pools, it can run them closer to an efficient design point: enough sharing to conserve, enough separation to protect quality, enough reserve to serve high-value exceptions. If the same operator fears registry conflict, it may keep more addresses idle, put more customers behind fewer active egress addresses, or delay cleaning up a product tier because any change could expose a record dependency. The result can be paradoxical: uncertainty around public IPv4 can make the public IPv4 already held less efficiently used.
That is not an argument for weak records or relaxed correction of false claims. It is an argument for due process and narrow scope. When records are wrong, they should be corrected. When fraud is shown, it should be addressed. When authority is disputed, the dispute should be bounded. What operators cannot price is open-ended discretion over resources already embedded in customer services. CGNAT turns that uncertainty into thousands of small operational decisions.
The ledger should not become a product architect
The temptation after exhaustion is to treat every operational workaround as a policy signal. If an operator uses CGNAT, perhaps it does not need more public IPv4. If an enterprise pays for static addresses, perhaps the operator is monetising scarcity. If addresses are leased, perhaps the market is undermining regional development. If IPv6 grows, perhaps IPv4 disputes matter less. Each claim may contain a fragment of truth. Each becomes dangerous when a registry uses it to move from record-keeping into product judgement.
A registry can know whether a resource is registered, which entity is responsible, whether policy criteria have been met, whether contacts work, whether reverse delegation is valid, whether transfer or lease evidence is present under the applicable rules, and whether a record needs correction. It usually cannot know the true value of a public address inside a network's product architecture. It cannot rank the social value of one customer's static address against another customer's CGNAT pool. It cannot see every support ticket, fraud case, camera failure, enterprise review, game complaint or lawful request.
That ignorance is not a defect. It is the reason the registry role should remain narrow. A registry that admits what it cannot know can focus on the facts it must know. A registry that claims broader stewardship over commercial use will inevitably act with partial information and concentrated power.
CGNAT illustrates the point. The same public-address conservation strategy can be efficient in one context and harmful in another. A large access network with careful port allocation, disciplined logging and clear product tiers may use CGNAT well. A regional provider with weak support and poor logging may use CGNAT badly because it has no affordable alternative. A hosting provider may avoid CGNAT for most customers because inbound reachability is the product. A public-service network may require documented public egress for accountability reasons. A registry cannot convert those differences into a simple moral rule.
The better institutional principle is modest. Keep the ledger accurate. Keep evidence standards clear. Make transfer and leasing recognition predictable where policy allows. Preserve contactability, reverse DNS, IRR records, RPKI services and account updates as neutral infrastructure. Correct false records through due process. Publish aggregate operational metrics where appropriate. Support IPv6 adoption. Do not use scarcity to decide which operator products deserve to exist.
This principle also protects end users. When the registry remains a ledger, operators have incentives to state their products clearly and carry responsibility for their own NAT choices. When the registry becomes a gatekeeper, operators have incentives to obscure arrangements, avoid updates, lobby for favourable interpretations or shift blame upward. The customer receives less clarity either way, but gatekeeping makes the information problem worse.
The institutional economics are old. A bottleneck controller with limited liability and broad discretion can impose costs on parties that have already made sunk investments. IPv4 exhaustion makes the bottleneck more valuable. CGNAT is one way networks manage that bottleneck. The registry should reduce the bottleneck's uncertainty, not exploit it.
A cleaner scarcity economy would reduce the hidden tax
A scarcity economy that takes the CGNAT tax seriously does not need to abandon conservation. It needs to distinguish conservation from opacity. Public IPv4 is finite. Waste should not be rewarded. Fraudulent or false records should be corrected. IPv6 should advance. But conservation works better when operators can see legitimate paths for scarce address needs instead of being pushed into unmeasured operational workarounds.
The first requirement is record certainty. Resource holders should be able to rely on clear public records, stable contacts, predictable reverse-DNS handling, reliable RDAP and WHOIS outputs, and reviewable correction procedures. If a record is contested, the status should be bounded and understandable without turning unrelated operations into collateral damage. A CGNAT estate depends on public pools whose responsibility can be explained quickly; ambiguity at the public record slows every abuse, lawful and enterprise conversation.
The second requirement is modest, transparent market accommodation. Transfers and leasing are not magic answers, and they can be abused if evidence is weak. But in a post-exhaustion region, some movement of IPv4 capacity is economically necessary. If legitimate demand cannot be met through clear channels, it will move through informal channels, upstream dependency, private opacity or excessive CGNAT. A narrow registry should prefer visible, documented, accountable scarcity transfers to hidden workarounds.
The third requirement is proportionate evidence. Operators should be required to show control, responsibility and policy compliance where those facts matter. They should not be forced to pretend that every public-address use can be judged from a central development narrative. Evidence standards should prevent fraud and improve the ledger, not turn the registry into a product regulator.
The fourth requirement is IPv6 progress tied to actual compatibility relief. IPv6 reduces the CGNAT tax only when traffic, devices, applications and counterparties move enough to lower public IPv4 pressure. Training, measurement, reverse-DNS support, procurement guidance and public-sector adoption can help. Empty transition language cannot. If an operator still needs IPv4 for banks, government portals, games, cameras, VPNs and enterprise partners, the CGNAT tax remains real.
The fifth requirement is operational transparency. AFRINIC and its members could discuss aggregate CGNAT incidence without exposing sensitive data. How often do port-missing complaints arrive? How much static-public-IPv4 demand comes from small businesses? Which application classes drive support? How much IPv6 traffic actually bypasses translation? Which registry services most affect address-pool usability? These questions would make scarcity policy less theatrical and more useful.
The policy direction is therefore neither "give everyone large IPv4 blocks" nor "force everyone through NAT until IPv6 saves them." It is to make the scarcity economy legible. Scarcity that is visible can be priced, reduced and worked around honestly. Scarcity hidden in support queues becomes a tax without a budget line.
There is room for practical safeguards that do not require institutional grandstanding. A registry can publish clearer status categories for routine changes, disputed resources and completed transfers. It can keep evidence requirements consistent enough that members can prepare documents before a commercial deadline. It can avoid using account status or unrelated disputes to disturb reverse DNS, RPKI, RDAP, WHOIS or IRR record continuity except under narrow, reviewable conditions. It can separate emergency continuity from policy argument. It can report aggregate service times and dispute categories without exposing confidential member data.
These safeguards would not remove CGNAT. They would reduce the uncertainty premium around the public pools that make CGNAT tolerable. The operator would still need translation capacity, logs, support and customer segmentation. But it could spend less time defending the legitimacy of the public identity layer and more time improving the network. That is what a good registry does in a scarcity economy: it lowers the cost of relying on the record.
IPv6 helps most when IPv4 is priced honestly
IPv6 is the durable technical way out of public IPv4 scarcity, but it should not be used as an alibi for present costs. A network can support IPv6 seriously and still need CGNAT because parts of the internet, customer equipment, enterprise policy and public-sector infrastructure remain IPv4-dependent. The transition is not a switch. It is a long coexistence in which the old layer becomes more operationally expensive before it becomes less important.
Honest IPv4 pricing helps IPv6 because it reveals what should be modernised. If a customer sees that static public IPv4 is scarce and costly, it may have reason to accept IPv6-capable applications, managed access, better identity controls or updated equipment. If an operator can show that CGNAT support and logging costs are real, it can justify IPv6 investment internally. If public agencies understand that IPv4-only procurement pushes costs into operators and citizens, they can change requirements.
Dishonest pricing does the opposite. If CGNAT costs are buried in general support, no one knows what IPv4 dependence costs. If static public IPv4 is rationed through opaque relationships, customers do not see the transition signal. If registry uncertainty forces operators to hoard, IPv4 appears scarcer in practice than it needs to be. If policy debates moralise address markets, operators may be discouraged from turning scarce IPv4 into capital that funds modernisation.
IPv6 also changes the attribution problem, but not by eliminating responsibility. A well-designed IPv6 network can reduce the need for address sharing and port-based attribution. It can make customer reachability cleaner. It can reduce some NAT failure modes. But it also requires firewall discipline, prefix management, privacy-address understanding, security tooling, customer education and application readiness. It is not free. It is simply the scalable direction.
The right institutional stance is therefore two-handed. Preserve and clarify IPv4 records because the economy still uses them. Push IPv6 deployment because the future cannot depend on endless translation. Do not weaken IPv4 certainty to force IPv6. That strategy would increase hidden costs and distrust. Operators move faster when the old layer is stable enough to manage and expensive enough to improve upon.
AFRINIC can be useful here if it behaves as infrastructure rather than preacher. It can support training, measurement and registry services that make IPv6 adoption easier. It can keep IPv4 records dependable. It can publish facts about exhaustion and policy without pretending that Phase 2 removes operational demand. It can let operators and customers see the economic signal clearly: public IPv4 is scarce, CGNAT is a conservation tool with costs, and IPv6 is the only path that reduces the translation tax at scale.
This section should not be mistaken for a broad transition manifesto. The article's centre is narrower: CGNAT makes the current IPv4 dependency visible in ports, logs, abuse queues, support scripts and product exceptions. IPv6 matters here because it can reduce those specific burdens when it actually changes traffic and application behaviour. It does not matter as a slogan that lets institutions ignore today's hidden invoice.
The tax should be visible before it becomes permanent
The danger of hidden taxes is habituation. Once the support scripts exist, once lawful-request teams adapt, once enterprise static-address tiers become normal, once gaming complaints are categorised, once remote cameras are sold with workarounds, once abuse desks learn to ask for ports, once public-address add-ons become a revenue line, the cost becomes ordinary. Ordinary costs are harder to challenge. They look like the natural price of internet service rather than the outcome of address scarcity and institutional design.
CGNAT will remain necessary for a long time. The argument is not to remove it where it is doing useful conservation work. The argument is to stop treating it as proof that public IPv4 scarcity has been solved. Scarcity has been transformed. The transformation is paid by operators, customers, enterprises, support agents, security teams, legal departments and remote services that must interpret shared identity.
AFRINIC's post-exhaustion legitimacy should be judged partly by whether it reduces that hidden tax. The registry cannot give Africa and the Indian Ocean region an abundant IPv4 future. It cannot make every legacy application IPv6-ready. It cannot prevent every abuse report from being incomplete. It cannot decide every enterprise exception. But it can keep the ledger accurate, narrow and trusted. It can avoid discretionary product judgement. It can support visible, evidence-based scarcity channels. It can treat registry continuity as service to operators, not institutional prestige. It can make sure that public-record uncertainty does not add avoidable cost to every NAT pool.
That is a more demanding role than the language of neutrality sometimes suggests. Neutrality is not passivity. It requires secure records, clear process, bounded disputes, accountable correction, transparent contacts and restraint. In a region where public IPv4 is scarce and the registry itself has been contested, restraint is not weakness. It is cost control.
The night-shift abuse request is therefore not a narrow operational anecdote. It is the place where the economics of scarcity become visible. One public address, many sessions, one missing port, one uncertain timestamp, one service block, one customer complaint, one legal review, one support script. The registry invoice did not show the tax. The network paid it anyway.
If scarcity policy is serious, it should follow the money to that room. It should ask how many costs are being hidden by conservation language, how many can be reduced by clearer records, how many require honest public-address pricing, how many can be removed by IPv6, and how many are the avoidable result of treating a registry as a gatekeeper rather than a ledger. The answer will not make IPv4 abundant. It will make the economics of scarcity less dishonest.