Summary

  • Carrier-grade NAT is usually described as address conservation, but its economic effect is broader: it turns public IPv4 identity into a shared credential and moves costs into logs, ports, support, abuse handling, platform risk scoring and lawful-request precision.
  • In the APNIC region, where IPv4 exhaustion arrived early and demand keeps growing across mobile, fintech, cloud, gaming and public-service access, the hidden tax is not paid by a single party. Operators carry logging and compliance cost; users carry false positives and reduced optionality; platforms carry attribution uncertainty; public authorities carry weaker evidence unless requests include port and timestamp detail.
  • APNIC should not be treated as the entity responsible for fixing CGNAT or deciding application policy. Its proper role is narrower but still important: maintain a reliable uniqueness ledger, reduce uncertainty around transfers and records, and avoid governance choices that force more operators into shared-address dependence than the market requires.

The ticket arrives without drama. A bank's fraud system has blocked a login from a public IPv4 address after a burst of failed attempts. A gaming platform has rate-limited the same address. A content service has placed it into a higher-risk bucket because too many accounts appear to be switching devices from one location. A law-enforcement request asks the access provider which customer used that address at a particular time. The customer support team can see the problem immediately: the address is not one customer.

It is one outward-facing address for many subscribers behind carrier-grade NAT. The provider can answer the request only if it has the right translation logs, time synchronization, retention policy, port information and subscriber mapping. The bank can clear the legitimate customer only if its risk system understands that a large number of unrelated users may share one public identifier. The gaming platform can remove the block only if it has a way to distinguish the user who cheated, botted or abused the service from every other user on the same address. The customer can do almost nothing except complain to the ISP, wait, reboot the router, buy a premium plan, move to another provider or accept the fact that "your IP address looks suspicious" has become part of ordinary Internet life.

This is the hidden economy of carrier-grade NAT. It is not simply a technical workaround. It is a method for allocating the cost of IPv4 scarcity.

Carrier-grade NAT, or CGNAT, allows a service provider to place many customers behind a smaller pool of public IPv4 addresses. The technique is familiar enough that it can sound mundane. A home router already translates private addresses in a household into one public address. CGNAT repeats that idea inside the provider network. One more translation layer appears between the customer's premises and the public Internet. In standards language, the Internet had to make room for this reality. RFC 6598 reserved the 100.64.0.0/10 shared address block for provider CGN deployments, explicitly because ordinary private address space created collision problems in provider networks and public IPv4 space was in short supply.

That engineering move solved one problem by creating a bundle of others. RFC 6269, the IETF memo on issues with IP address sharing, is striking because it does not treat address sharing as a free lunch. It identifies application failure, extra monitoring complexity, security issues, geolocation problems, blacklisting consequences, authentication weakness and traceability costs. RFC 6888 then turns those consequences into operational requirements for carrier-grade NATs: ports have to be managed; mappings may need logs; a subscriber may have to be identified by external address, port and timestamp; and huge log volumes can become a real burden. RFC 7422 is even more candid. It notes that per-connection logging is not scalable in many residential broadband networks and proposes deterministic mapping partly to reduce the logging load while preserving traceability.

The APNIC region is not incidental to this story. APNIC reached the final stage of its IPv4 free-pool exhaustion in April 2011. Its post-exhaustion materials now describe a region in which members can still receive limited IPv4 space, but the final 103/8 pool is capped at a total maximum delegation of a /23, or 512 addresses, per member from that pool. That is not a platform for one-public-address-per-customer growth. It is a record of scarcity at the registry layer, followed by a market, transfer and conservation environment in which many networks must decide whether to buy, lease, transfer, conserve, share or re-architect.

The important point is not that APNIC caused CGNAT. The important point is that APNIC sits at the ledger layer above a region where CGNAT becomes one of the market's default reactions to public-address scarcity. Once a public address can no longer be assumed for each customer, the address changes character. It stops being a simple reachability identifier and becomes a shared credential. The public Internet sees the address; the provider sees the private subscriber; the platform sees behavior that may belong to one person, one household, one cafe, one building, one mobile sector, or thousands of unrelated sessions. The distance between those views is where the hidden tax is paid.

The public address becomes a shared reputation instrument

The first incidence of CGNAT is reputation. A public IPv4 address is not merely a routeable number. It is also a memory object. Mail systems, fraud systems, abuse desks, content platforms, gaming services, ticketing sites, financial applications, ad networks, security vendors and law-enforcement intake systems all attach meaning to observed addresses. Some of that meaning is explicit: blacklists, reputation databases, rate limits, geolocation tables, fraud-risk models and account-protection thresholds. Some is informal: a support analyst notices the same address in many complaints; a merchant processor associates the address with account takeover attempts; a game publisher sees a cluster of cheating reports.

When the address belongs to one server or one enterprise circuit, that memory can be useful. It is still imperfect, but at least the connection between observed behavior and accountable operator is relatively direct. Under CGNAT, the memory becomes blurry. One user's malware can poison the address seen by another user's bank. A bot account can trigger a CAPTCHA or login challenge for a household that has never touched the service before. A spam incident can damage the address pool used by a small broadband provider, and the remediation burden falls on the provider's abuse desk even if the offending customer churns away.

This is not hypothetical edge-case theory. The IETF's address-sharing analysis says plainly that abuse reports based only on an IPv4 address and time are not enough to identify a subscriber when multiple subscribers share that address. It also warns that IP-based penalty boxes and blacklists can produce collateral damage when the address is shared. Cloudflare's 2025 discussion of CGNAT detection makes the same point from the platform side: if hundreds or thousands of clients appear from one IP, an IP-based security system may block or throttle many legitimate users because of one user's behavior. M3AAWG's technology summary similarly notes that a group of ISP customers can share a pool of external addresses and that the ISP must keep detailed translation logs to diagnose abuse.

The hidden tax here is paid in several currencies. The operator pays in reputation-management labour. The user pays in friction: blocked logins, extra verification, support calls, reduced trust and sometimes subscription downgrade because the service looks lower quality than it is. The platform pays in a more expensive anti-abuse model, because an IP address has lost some of its evidentiary value. If the platform does not adapt, innocent users are punished. If it does adapt, it must invest in alternative signals, device models, account history, behavioral analytics, privacy-sensitive risk design and appeal paths. Either way, the cost has moved. CGNAT saves public addresses, but the saving is partly funded by everyone who now must repair the meaning of a public address.

In Asia Pacific this matters because the region is economically uneven and demand is large. GSMA Intelligence estimated that mobile connectivity contributed $950 billion to Asia Pacific's economy in 2024 and could rise to $1.4 trillion by 2030. The region contains dense high-income markets, island networks, emerging urban corridors, low-ARPU rural systems, fintech-heavy economies, gaming-heavy consumer markets and public-service digitization programs. A shared address behind a large operator in one setting may create a manageable nuisance. A shared address behind a fragile local provider, a school connectivity program, a remittance corridor or a small-market fintech user base can become a real acceptance problem. The same technical workaround has very different economic incidence depending on who can absorb the secondary costs.

Ports become the rationed identity layer

The second incidence is ports. A CGNAT system does not merely share an address. It shares the finite transport-port space attached to that address. The external address and port together become the practical public identity of a flow. That is why source port, timestamp and protocol matter so much in logging and lawful requests. The address alone no longer identifies the customer. The port is part of the answer.

This turns a previously obscure technical field into an economic rationing surface. RFC 6888 describes external ports as a shared resource and says efficient port management directly affects subscriber connection quality. It also requires configurable per-subscriber limits, partly so one subscriber cannot consume too much of the shared NAT resource. That is a technical fairness rule, but it is also a price signal in disguise. If a user, household, small business or cafe needs many simultaneous flows, the provider must decide how many ports are fair, how much state to hold, when to recycle mappings, how to handle port exhaustion, and what to do when applications behave badly.

The result is a quiet service-tiering problem. A customer with a dedicated public IPv4 address has one kind of optionality. They may run a server, accept inbound connections, host a camera system, use peer-to-peer applications, play games with fewer NAT complications, or satisfy business software that assumes a stable address. A customer behind CGNAT has another kind of optionality. Some uses still work well. Browsing, messaging, streaming and ordinary mobile-app traffic can be fine most of the time. But "most of the time" is not the same as "full optionality." The customer may be unable to accept inbound traffic, may hit platform suspicion, may need workarounds for gaming or peer-to-peer functions, may have less reliable geolocation, and may be told to pay extra for a static public IP if one is available.

The access provider can present this as normal retail segmentation. Basic plan: shared public identity. Premium plan: public address. Business plan: static address and better abuse handling. There is nothing inherently wrong with differentiated service. But the economics should be named. CGNAT converts public IPv4 identity from a default attribute of connectivity into a scarce add-on. The tax is hidden because it is not always billed as "CGNAT tax." It appears as a support ticket, a paid static address, a failed application, a gaming complaint, a fraud-model false positive, a lost customer, a slower lawful-response queue, or a platform block that nobody can price cleanly.

This is where the article must be kept distinct from the broader dual-stack cost debate. Dual-stack cost incidence asks who pays to run IPv4 and IPv6 together. CGNAT hidden-tax incidence asks who pays when one public IPv4 address must stand in for many parties. The two are related, but not identical. Dual-stack is a two-network operating burden. CGNAT is an identity-compression burden. One lives in routing, procurement, compatibility and engineering duplication. The other lives in ports, logs, reputation, support, legal traceability and acceptance by outside platforms.

The logging bill is not just storage

The most visible internal cost of CGNAT is logging. The simplest abuse report says: this public IPv4 address did something at this time. Before address sharing, that might often be enough to begin attribution. Under CGNAT, the provider needs at least a finer tuple: public address, source port, protocol, timestamp and a way to map those values back to the subscriber or internal address active at that moment. If the remote service did not record the source port, or if the time zones differ, or if clocks were not synchronized, or if logs expired, the answer becomes uncertain.

The cost is not just disk space. It is system design. Translation devices have to generate logs accurately without dropping traffic or creating unacceptable latency. Logs have to be collected, compressed, indexed, retained and protected. Time has to be synchronized across devices. Retention has to satisfy local law without creating unnecessary privacy exposure. Staff have to be trained to answer abuse complaints and lawful requests in a way that is fast, defensible and proportionate. A request that lacks a source port may have to be returned for more information. A request that covers too wide a time window may implicate many subscribers. A request that arrives after retention expires may be impossible to answer. Each failure creates institutional friction.

The cost also changes with architecture. Per-session logging gives detailed traceability but can create enormous volume. Deterministic port-block assignment reduces logging, but it allocates port ranges in ways that may reduce utilization or flexibility. RFC 7422 exists because this trade-off is not academic: residential broadband at scale may not be able to log every connection cheaply. RFC 6888 describes the same tension: port allocation should maximize utilization, minimize log volume and make port guessing hard, but optimizing one requirement may compromise another. CGNAT is therefore not one cost. It is a family of trade-offs among public-address conservation, port utilization, abuse traceability, privacy, security and quality of experience.

This is why "just log it" is not an answer. Logging is a continuing operating system, not a checkbox. A small ISP in the APNIC region may have to buy CGNAT equipment, log collectors, storage, lawful-intercept support, monitoring, redundancy and staff time in currencies stronger than its revenue base. A large mobile operator can amortize those costs across millions of customers. A small fixed-wireless operator, an island ISP, a local broadband cooperative or a growth-stage urban provider cannot. The same CGNAT requirement can be a manageable engineering line item for one network and a material burden for another.

The lawful-request dimension intensifies the problem because it converts technical ambiguity into institutional risk. Law-enforcement bodies do not always understand the difference between public IP attribution and subscriber attribution behind NAT. Europol has warned that CGN technologies create attribution difficulties because many users can share one IP address. In a mature request environment, investigators provide source port and precise timestamp. In a weaker environment, the provider may receive only an address and a broad time. The provider then faces an uncomfortable choice: disclose too many possible subscribers, refuse or narrow the request, spend staff time educating the requester, or risk being seen as uncooperative.

This cost is rarely visible to customers. They see monthly broadband price and speed. They do not see the hidden compliance factory required to make shared public identity legible to authorities and platforms. Yet the cost comes out of the same operator margin that funds coverage, repair, customer service and network upgrades. In lower-margin markets, the hidden tax is not morally neutral. Money spent making address sharing legally usable is money not spent on something else.

Platform acceptance becomes a market access problem

CGNAT also affects access to platforms, and platform acceptance is now part of economic life. A bank login, a government portal, a cloud console, a game server, a marketplace seller account, a ride-hailing driver app, a remittance service and a video platform are not luxuries at the edge of connectivity. They are increasingly the reasons people buy connectivity. If shared public identity causes those services to distrust users, the network's product quality declines even when speed tests look fine.

The platform side faces its own cost. An IP address used to be a crude but useful signal. It still is, but CGNAT reduces its precision. A fraud team may see hundreds of accounts from one address and have to decide whether that is a dormitory, a carrier NAT, an emulator farm, a click operation, a call center, a cafe, a mobile gateway or an attack. A game publisher may see many concurrent sessions and wonder whether it is seeing a cybercafe or a bot cluster. A bank may see an address switch and wonder whether the customer is traveling, using mobile data, behind CGNAT, or compromised. A streaming service may see many households behind one address and confuse ordinary access-network design with account sharing or VPN behavior.

If the platform blocks too aggressively, it harms legitimate users and creates complaints for the ISP. If it relaxes controls too far, it increases fraud and abuse. If it builds better CGNAT detection, it spends engineering money. If it demands more data from operators, it raises privacy and compliance questions. The result is a multi-party cost negotiation that is rarely explicit. The platform wants attribution precision. The access provider wants address efficiency. The user wants service acceptance. Public authorities want traceability. Privacy law wants minimization. IPv4 scarcity sits underneath all of it.

This is why the hidden tax should be described as incidence rather than blame. It is not enough to say CGNAT is bad, or that operators are wrong to use it. For many networks, CGNAT is a rational response to public-address scarcity and customer price sensitivity. If the alternative is no service, slower growth, unaffordable public-address purchases or a service footprint that excludes low-revenue users, CGNAT can be the least bad option. The economic question is narrower and more useful: who pays for the side effects, and are those costs being recognized in policy, pricing and registry governance?

In a transparent market, a public IPv4 address, a shared CGNAT slot, a deterministic port block, a static business IP and an IPv6-native service would each have visible cost and capability differences. Customers could understand what they are buying. Operators could invest in the right mix. Platforms could classify shared-address traffic without punishing it by default. Public authorities could request the right tuple. Registries could focus on record accuracy and transfer certainty instead of moralizing conservation. The present market is less transparent. CGNAT's costs are diffused across complaints, false positives and operational friction.

APNIC's ledger role is narrow, but the narrow role matters

APNIC is not an application regulator. It does not decide whether a bank should accept a login, whether a gaming platform should lift a ban, whether a video service should treat a shared address as account sharing, or whether a national authority's lawful request is sufficiently precise. It should not be asked to police CGNAT deployment, punish address sharing, determine customer geography, approve business models or impose broad social goals on scarce address use. A registry that becomes an enforcer turns the address book into leverage, and that is exactly the wrong direction for critical infrastructure.

But APNIC's narrow role still matters because the hidden tax is partly a consequence of how hard it is to obtain and move public IPv4 identity. A clean registry record lowers uncertainty. A predictable transfer path lowers transaction cost. Accurate contact data improves escalation. Routing and reverse-DNS records reduce collateral reputation damage. Clear proof of control supports counterparties. Efficient inter-RIR and intra-region transfer records reduce the need for desperate sharing. A registry that keeps the ledger thin, accurate and predictable does not abolish CGNAT, but it reduces the excess burden caused by avoidable uncertainty.

The opposite is also true. If registry governance makes transfers slow, discretionary, expensive or politically loaded, more networks will stretch limited addresses through CGNAT for longer. If members fear that using leased space, transferred space or business-model-specific address arrangements will draw arbitrary scrutiny, they will keep address sharing inside their own networks rather than expose themselves to market transactions. If the registry's language treats scarcity as a reason for more institutional control rather than more precise recordkeeping, it pushes cost back onto operators and users. The hidden tax grows when the ledger becomes a gate.

The right boundary is simple. APNIC should protect uniqueness, accuracy and continuity. It should record who has the resource, how transfers are recognized, what contacts are accountable, and what security or routing records support reliance. It should not decide whether a provider's choice to use, buy, sell, lease or conserve addresses is morally preferred, except where the decision affects uniqueness, fraud, accuracy or documented dispute status. CGNAT is a service-layer architecture. Registry policy should not micromanage it. Yet registry friction should not make CGNAT the only affordable option for networks that would otherwise acquire public identity on transparent terms.

This boundary also helps separate APNIC from the platforms that consume address reputation. A content provider's anti-abuse system may need to treat CGNAT differently, but it should not expect APNIC to certify the morality of each address-sharing design. A law-enforcement unit may need better request templates, but it should not expect the registry to replace provider logs. A user may need a static public address, but the registry should not become the retail complaint desk. The ledger has a duty to be correct and reliable. It does not have a mandate to solve every downstream externality created by IPv4 scarcity.

The Asia-Pacific tax is uneven

The APNIC region makes CGNAT economics unusually uneven because the region is not one market. It includes countries with high IPv6 adoption and mature mobile networks, economies where public-sector digitization depends heavily on mobile access, island systems with costly backhaul, low-income markets with imported equipment costs, dense cities where one public address can represent enormous user volume, and small networks that must buy or lease IPv4 in a market influenced by global cloud and telecom demand.

The same shared-address ratio can therefore mean different things. In a dense mobile market with sophisticated logging and platform relationships, CGNAT may be a managed part of the access fabric. Users may experience occasional friction, but the operator has the scale to run logs, answer requests and coordinate with major platforms. In a smaller market, the operator may have the same technical need but far less institutional support. A platform block may take days to resolve because there is no privileged escalation channel. A lawful request may consume senior engineering time because the legal and technical teams are thin. A bank false positive may lead customers to blame the ISP even when the bank's model is the immediate cause.

The tax is also uneven across users. Residential users may tolerate shared addressing if the price is low and common applications work. Gamers may notice immediately. Home-office workers may notice when VPNs, remote access or security tools behave badly. Small businesses may notice when a payment provider or marketplace flags the shared address. Developers may notice when cloud consoles, package repositories or API services throttle the address. Public-service users may notice when a government portal assumes the address is a location or identity marker. One public IP can serve many people, but not all people have the same tolerance for ambiguity.

That unevenness creates hidden cross-subsidy. Customers who do not need public identity benefit from lower access costs. Customers who do need it pay in upgrades, static-address fees or lost functionality. Platforms subsidize the access network by building more nuanced detection. Operators subsidize platforms by doing support and reputation repair when platform models punish shared addresses. Public authorities subsidize both when requests become harder to execute. The cost is distributed, but distributed does not mean absent.

This is the economic incidence APNIC policy debates should be able to see. Scarcity does not disappear because the address is shared. It changes form. Instead of paying for more public addresses, the market pays through complexity. Instead of a public-address price appearing on a balance sheet, costs appear in call-center minutes, storage, legal review, abuse tickets, platform engineering, failed sessions and lost optionality. A hidden tax is still a tax if it changes behavior and consumes resources.

The user experience is the accounting system nobody wants

The harshest CGNAT accounting often appears in user experience. A user does not say, "I am suffering from externality misallocation under shared IPv4 identity." They say the bank app does not work. They say the game says their connection is restricted. They say a website thinks they are in the wrong city. They say the streaming service keeps asking for verification. They say the government portal failed. They say the ISP is bad.

This is economically important because access providers sell perceived reliability, not only raw transport. If CGNAT causes a failure outside the provider's own network, the provider still absorbs part of the blame. Support teams must explain what a shared public IP is to customers who did not ask to learn network architecture. The explanation rarely satisfies. From the user's perspective, they paid for Internet access and an important service denied them. Whether the denial came from a platform's IP-based risk model, a stale reputation list, a law-enforcement block, a port limitation or a NAT traversal failure does not matter much.

The support queue therefore becomes a ledger of hidden incidence. Each ticket carries information about where the cost landed. If a user pays for a public IP, the cost lands in the user's bill. If the provider remaps the customer to a cleaner address pool, the cost lands in operational management. If the platform whitelists a NAT range, the cost lands in platform engineering and trust policy. If nobody resolves it, the cost lands in churn, lost productivity or exclusion from a service.

For APNIC-region operators, this is not merely a technical operations concern. It affects market structure. Larger providers can afford better CGNAT systems, better logs, better platform escalation, more public IPv4 inventory, better support scripts and dedicated compliance staff. Smaller providers may use simpler equipment, smaller logs, weaker support capacity and fewer relationships. That can reinforce incumbent advantage even when the registry rules are formally neutral. Public IPv4 scarcity plus CGNAT externalities can make scale more valuable, not because larger networks are always technically better, but because they can absorb the hidden tax more efficiently.

The consequence is subtle. A new entrant may be able to buy transit, deploy radios, lease backhaul and sign customers, but still struggle with address reputation, static-IP demand, lawful-request process and platform acceptance. The barrier is not just "find IPv4." It is "find enough clean public identity, or build enough shared-identity machinery, to make customers accepted by the outside Internet." That is a harder and less visible requirement.

Good CGNAT design reduces harm but does not erase incidence

There are better and worse ways to run CGNAT. Operators can use adequate port budgets, deterministic mappings, clear customer communication, accurate logs, synchronized clocks, careful retention, address-pool reputation monitoring, abuse-desk procedures, static-IP upgrade paths, IPv6 deployment where useful, platform escalation contacts and documented lawful-request formats. They can avoid overloading public addresses beyond what applications tolerate. They can reserve cleaner pools for customers with higher acceptance needs. They can teach support teams to recognize shared-address false positives quickly.

These practices matter. They reduce harm and should be encouraged as operational discipline. But they do not eliminate the underlying economics. A port budget is still a budget. Logs are still logs. Support remains support. Reputation remains shared. A platform's better CGNAT detection is still a cost of platform adaptation. A static-IP upsell still means public identity has become a premium feature. The better-run network makes the tax less painful; it does not make the tax vanish.

This is why a pure troubleshooting guide would miss the point. The question is not how a customer can determine whether they are behind CGNAT, or whether a gamer should ask for a static IP, or which NAT traversal method works best. Those are practical questions, but they sit downstream. The upstream question is why the cost exists and who carries it. CGNAT is a price mechanism wearing the clothes of a technical workaround. It prices public IPv4 scarcity by reducing identity quality instead of by charging every user for a unique address.

That may be efficient for many consumer markets. It may also be fair if users know what they are buying and can buy a public address when they need one. But it becomes problematic when the cost is hidden, when users are blamed for platform failures they cannot control, when operators lack reasonable access to public-address supply, when lawful-request systems do not include ports, when platforms punish shared addresses too broadly, and when registry policy adds friction to transfers that could otherwise reduce dependence on sharing.

Good policy therefore begins with visibility. Operators should measure CGNAT support tickets separately from generic connectivity tickets. Platforms should detect and treat shared-address traffic with care. Public authorities should use request formats that include address, port, timestamp, protocol and time zone. Customers who need stable public identity should be offered clear options. Registry policy discussions should treat IPv4 transfer friction, leasing uncertainty and public-address scarcity as inputs into CGNAT cost, not as separate worlds.

The ledger-not-gatekeeper principle applied to CGNAT

The ledger-not-gatekeeper principle is useful here because it disciplines both overreach and neglect. A registry overreaches if it tries to command service architecture, moralize address use, punish operators through record control or decide what kind of customer deserves public identity. But a registry neglects its role if inaccurate records, slow transfers, unclear contact data, weak proof of control or discretionary uncertainty make public-address markets harder to use than they need to be.

For CGNAT, the narrow registry contribution is not a CGNAT rulebook. It is a better address market environment. If an operator can acquire, transfer, lease or document public IPv4 resources with predictable record treatment, it has more options. If records are accurate, counterparties can assess reputation and control. If transfer procedures are predictable, address holders can move space toward higher-valued use. If disputes are recorded without freezing ordinary operations unnecessarily, reliance improves. If APNIC remains a reliable ledger rather than a gatekeeper, operators can make service-layer choices under clearer economic conditions.

This matters because CGNAT can become a trap when public-address alternatives are too uncertain. A provider may know that more public IPv4 would reduce support and platform friction, but still avoid transactions because transfers are slow, prices are opaque, documentation is burdensome, or policy risk is hard to price. In that case, CGNAT is not chosen solely because it is efficient. It is chosen because the public-address market is harder to navigate than the shared-address machine. The hidden tax then becomes a symptom of market friction.

There is a second discipline: APNIC should not use CGNAT's side effects as an argument for more centralized control. It would be tempting for any registry to say that because address sharing creates abuse and traceability problems, the registry needs broader enforcement power. That conclusion does not follow. Abuse handling belongs with operators, platforms, customers and lawful authorities that hold the relevant evidence and legal mandate. Registry overreach would add another control point without adding the operational knowledge needed to solve the problem. The correct response to CGNAT externalities is thinner, cleaner coordination plus better service-layer practice, not a thicker registry state.

The same logic applies to IPv6. IPv6 can reduce pressure on shared IPv4 where it is actually used end to end, and many operators deploy it for good reasons. But IPv6 does not remove the need to account for CGNAT costs while IPv4 remains necessary for reachability. A public article about CGNAT should not become protocol advocacy. It should ask how the existing address economy allocates costs today. If IPv6 traffic reduces the number of IPv4 sessions per subscriber, it can reduce CGNAT load. If major services still require IPv4 reachability, the shared-address tax remains. Operators live in that present tense.

What should be measured

A serious APNIC-region discussion of CGNAT should measure more than address savings. Address savings are easy to count: fewer public IPv4 addresses serve more subscribers. The harder and more important question is what was spent to obtain those savings.

The first metric is log cost per subscriber. This includes device logging capacity, collectors, storage, indexing, retention, deletion, access controls, audit trails and staff time for requests. The second is abuse-response cost: number of complaints, fraction requiring port-level disambiguation, time to resolution, false-positive rate and platform escalations. The third is reputation cost: addresses listed on blocklists, time to delisting, customer impact and pool rotation overhead. The fourth is support cost: tickets mentioning blocked logins, gaming NAT type, static IP requests, remote-access failure, geolocation errors and platform bans. The fifth is lawful-request quality: percentage of requests that include source port, protocol, precise timestamp and time zone. The sixth is optionality cost: revenue or churn associated with customers who need public identity but cannot obtain it easily.

These metrics would make the hidden tax visible. They would also show where the burden lands. If logging dominates, the operator needs better architecture or lawful-request templates. If platform false positives dominate, the operator needs escalation and the platform needs better shared-address treatment. If static-IP demand dominates, address scarcity and transfer-market access are the issue. If gaming complaints dominate, port behavior and customer-plan communication matter. If lawful requests lack ports, public-authority education is the bottleneck. Without measurement, every actor can blame every other actor and the tax remains hidden.

Measurement also helps avoid a false moral debate. CGNAT is neither a villain nor a miracle. It is a rationing technology. Rationing technologies can be useful. They can also hide costs and shift them to parties with less bargaining power. The question is whether the rationing is explicit, proportionate and reversible. A consumer who knowingly buys a low-cost shared-address plan and can upgrade when needed is in a different position from a small business that discovers only after signing a contract that critical services will not accept its public identity. A platform that can distinguish CGNAT from abuse is in a different position from one that blocks entire address pools. A provider with clean transfer access is in a different position from one trapped behind policy friction.

For APNIC governance, the lesson is not that every member must receive enough IPv4 for every customer. That world is gone. The lesson is that registry policy should not pretend that address sharing is costless. Conservation language can make CGNAT sound like a public good: use fewer addresses, serve more customers. Sometimes that is true. But if conservation pushes costs into less visible forms, policy should account for those costs. A ledger that recognizes real market and operational incidence is more legitimate than one that praises conservation while ignoring who handles the fallout.

The hidden tax and the value of public identity

CGNAT reveals something the old abundance era obscured: public IPv4 identity has value beyond packet forwarding. It carries reputation, optionality, traceability, inbound reachability, platform acceptance and institutional legibility. When public identity is compressed, those attributes are compressed too. The economic value of a dedicated public address is not only that packets can reach it. It is that the outside world can treat it as a more precise reference point.

This does not mean every user needs a dedicated address. Many do not. It means the market should stop pretending the difference is trivial. A shared address is a lower-cost identity product with different externalities. A dedicated address is a higher-optionality identity product with different costs. A leased address, transferred address, static business address or IPv6-native service each carries a different risk and acceptance profile. Once that is acknowledged, operators and customers can make better choices.

Hiding the difference helps incumbents and large platforms more than users. A large operator can manage the ambiguity internally. A large platform can build better risk systems. A small operator, a small business and an individual customer have less leverage. They discover the cost when something breaks. That is why a calm economic description is more useful than slogans. The issue is not whether CGNAT should exist. The issue is whether shared public identity is priced and governed honestly.

APNIC's role is to make the upstream address environment more honest, not to overrule service design. Its post-exhaustion reality is already an exhibit: the region cannot rely on free-pool abundance. That makes transfers, leases, accurate records, contactability, routing evidence and operational continuity more important, not less. If the registry remains a thin and reliable ledger, public identity can move toward networks and customers that value it most. If it becomes a permission structure, scarcity costs will be expressed through more CGNAT, more support burden and more platform friction.

The bank ticket at the start of this article is therefore not a customer-service anecdote. It is a small balance sheet entry in the post-exhaustion Internet. Someone saved a public IPv4 address. Someone else built logs to prove who used it. Someone else built a risk model to decide whether to trust it. Someone waited in a support queue. Someone wrote a lawful request that either included the port and timestamp or did not. Someone paid for a static IP. Someone churned. Someone was blocked by mistake. The public address was conserved, but the cost did not disappear.

That is the economics of carrier-grade NAT as hidden tax. It is a tax on precision when public identity is shared. It is paid by operators in infrastructure and staff time, by platforms in more complex trust systems, by authorities in evidentiary care, and by users in lost optionality. In the APNIC region, where growth, scarcity and market diversity meet earlier and harder than in many narratives of the Internet, that tax deserves to be visible. The narrow ledger cannot abolish it. But a narrow, predictable and market-aware ledger can keep from making it worse.

Sources and Further Reading