APNIC and the economics of dual-stack cost incidence

Summary

Dual-stack cost incidence is not the same question as IPv6 adoption. The adoption question asks whether networks can carry IPv6; the incidence question asks who keeps paying when IPv4 compatibility and IPv6 reachability must both remain available.
In the APNIC region, the bill is divided unevenly among access operators, cloud providers, hosting firms, enterprise buyers, public-sector procurement teams, support desks and end users because income levels, market structure, NIR relationships, IPv4 inventory and IPv6 readiness vary widely across Asia-Pacific.
APNIC's legitimate role is narrow but valuable: maintain reliable records, transfer visibility, routing-adjacent evidence and continuity signals that lower uncertainty. It cannot decide who should absorb help-desk labour, firewall duplication, public IPv4 premiums, cloud NAT charges, procurement exceptions or customer migration costs.

The invoice appears before the transition ends

The most honest way to see dual-stack is not to open a standards document. It is to open a network budget. On one line sits the IPv6 programme: address planning, CPE readiness, peering, software, monitoring, staff training and enterprise testing. On another line sits the IPv4 continuity programme: public address inventory, transfers, leasing, CGNAT capacity, reputation repair, support scripts, reverse-DNS hygiene, RPKI and route records, fraud handling, customer exceptions and cloud public-IP add-ons. Neither line cancels the other. The second does not disappear because the first exists. The first does not become cheap because the second is valuable. The operator pays both.

That is the economic centre of dual-stack cost incidence. The question is not whether IPv6 works. It works. Nor is the question whether IPv4 is finite. It is. The question is how a market assigns the cost of maintaining two forms of reachability when one protocol family is abundant but not universally sufficient, while the other is scarce but still commercially decisive. In a neat engineering story, IPv6 adoption should shrink the IPv4 bill. In actual commerce, IPv6 often adds a second operating surface before it removes the first. The cost therefore lands wherever bargaining power is weakest.

Asia-Pacific makes this visible because it is not one market. APNIC's service region contains wealthy, cloud-dense economies, large mobile-first markets, small island networks, low-ARPU access providers, national Internet registry arrangements, large incumbent address holders, fast-growing platforms and public sectors that still buy connectivity through conservative procurement requirements. A carrier in Tokyo, a hosting firm in Singapore, a mobile network in India, a rural provider in Indonesia, a government supplier in the Pacific and a cloud customer in Australia can all be described as living in the same regional registry environment. They do not face the same incidence of coexistence costs.

The useful public question is therefore accounting, not evangelism. Who can pass the cost through? Who must absorb it? Who turns coexistence into a priced feature? Who hides it inside bundles? Who pays in downtime, support labour or poorer service rather than in a visible invoice? And where does APNIC reduce uncertainty without pretending to be the market's tax office, migration director or capital allocator?

APNIC's region turns coexistence into a distributional problem

APNIC is the regional number registry for Asia-Pacific. That fact is often treated as administrative background. For dual-stack economics, it matters because the region contains some of the world's most uneven combinations of address scarcity, growth, purchasing power and operational maturity. The same scarcity event does not produce the same bill in every economy. The same IPv6 deployment statistic does not reveal who bears the cost of compatibility.

APNIC reached the final stage of its IPv4 free-pool regime in 2011, when the old allocation-era bargain effectively ended and scarcity became the permanent condition for new demand. Since then, IPv4 availability has depended increasingly on holdings, transfers, leasing, reclamation, NIR practice, corporate inheritance and market willingness to pay. IPv6 adoption has grown materially in parts of the region. India, Malaysia, Vietnam, Japan, Taiwan and several other economies have shown serious IPv6 capability by public measurement. Yet the coexistence bill remains because high IPv6 capability is not the same thing as universal IPv6-only substitutability.

This distinction matters most in procurement. A network can be technically IPv6 capable and still need IPv4 to win a business contract, serve a bank application, pass a public-sector review, support legacy CPE, carry traffic to a customer portal, satisfy a cloud allowlist, preserve email reputation, handle abuse complaints or interoperate with a vendor appliance. The compatibility requirement is not always visible to the end user. It appears as an exception in a firewall rule, a "public IP required" line in a tender, a support ticket about a payment gateway, an enterprise customer demanding static reachability, or a mobile customer discovering that an application behaves differently behind shared IPv4.

Incidence follows from those frictions. Where customers can insist on IPv4 compatibility without paying for it directly, the operator absorbs the cost. Where cloud platforms can unbundle public IPv4, the customer pays. Where hosting firms compete on headline monthly prices, the public IP charge may be hidden until renewal, setup or upgrade. Where public bodies demand compatibility but award contracts on low headline price, suppliers carry the margin squeeze. Where end users have little choice, they pay through worse quality, shared-address friction or support delays rather than through a line item.

The region's diversity also changes the politics of blame. In a high-income enterprise market, dual-stack cost can look like a routine IT transition budget. In a low-income access market, it can look like a hard-currency equipment purchase, a training burden and a CGNAT support tax imposed on thin monthly revenue. In a small island network, it can be tied to upstream concentration and disaster recovery. In a fast-growing mobile market, it can become a race between subscriber growth and public-address scarcity. A single APNIC policy or message cannot flatten these conditions into one moral story.

Dual-stack is two accountability chains, not merely two address families

The phrase "dual-stack" is technically tidy. It suggests a host or network running IPv4 and IPv6 together. The economic reality is less tidy because each stack carries a different accountability chain.

IPv6 adds address abundance but also requires operational confidence. Operators must know which customers receive IPv6, which devices support it, which peering sessions carry it, which monitoring systems detect its failures, which security policies apply, which applications prefer it, and which breakages are caused by it. IPv4, meanwhile, carries scarcity, price and legacy reachability. Operators must know which public addresses are assigned, leased or transferred; which customers sit behind shared exits; which logs can map sessions to users; which addresses carry reputation problems; which blocks have clean routing history; which reverse-DNS records matter; and which contracts depend on public reachability.

Those chains are not symmetrical. An IPv6 failure may be invisible if the application falls back to IPv4. An IPv4 failure may immediately break a bank integration, gaming session, VPN, allowlist, payment flow, inbound mail path or enterprise remote-access tool. An IPv6 address is usually not scarce capital. An IPv4 address increasingly is. The first may be judged as network modernisation; the second is judged as operating asset continuity. That difference changes internal politics. Engineering may want simpler IPv6 expansion. Sales may promise IPv4 compatibility. Finance may see public IPv4 as a scarce asset. Support may see shared-address pain. Security may see logging exposure. Procurement may see vendor compatibility. Legal may see attribution risk.

Dual-stack therefore creates internal cost fights. The access division wants to avoid buying more public IPv4. The enterprise division wants clean dedicated addresses for contracts. The security team wants logs rich enough to answer abuse and lawful requests. The cloud team wants architecture that avoids needless public IP charges. The support team wants fewer edge cases. The finance team wants scarce addresses treated as capital, not as disposable plumbing. The public-policy team wants to be seen as pro-IPv6 without promising a cutover that customers will not tolerate.

APNIC's registry role intersects with this conflict only at certain points. It can help the market know who is registered as the holder of a resource, how transfers are recorded, what contact or routing evidence exists, and where number-resource continuity depends on registry-state accuracy. That is important. But APNIC cannot make the internal accounting choice for a carrier, cloud platform, bank supplier or small ISP. A registry record can reduce uncertainty around scarce assets; it cannot allocate the cost of two help-desk playbooks or duplicated firewall policy.

This is why incidence is the better lens than transition. Transition language asks when the old world ends. Incidence asks who pays while it does not end.

Access operators pay first because customers cannot be switched off

Access networks are the first-loss bearers of dual-stack coexistence. They have the customer relationship, the complaint queue and the obligation to make ordinary services work. When an application fails, most users do not diagnose address-family selection, NAT behaviour or remote server compatibility. They call the provider. The access operator must explain, fix, route around or absorb.

That creates a simple commercial asymmetry. The customer expects the Internet, not a protocol lesson. If IPv6 is present but a service still depends on IPv4, the access provider must preserve IPv4 compatibility. If IPv4 is scarce, the provider must ration it through CGNAT, transfers, leasing, static-address premiums or careful inventory use. If CGNAT creates a problem, the support desk hears about it. If a customer needs a public IPv4 for cameras, remote work, payment equipment, gaming, a small server, a VPN or a legacy business service, the provider must decide whether to charge, refuse, subsidise or hide the cost in the bundle.

In APNIC economies with high mobile growth, this first-loss position is amplified. Mobile access often scales faster than public IPv4 supply. Shared IPv4 becomes normal. IPv6 can reduce pressure where content and applications support it, but the operator still needs IPv4 exits for the rest. A mobile subscriber who uses mostly IPv6-enabled content may still encounter a support-heavy edge case when an app, enterprise resource, merchant terminal or authentication service expects IPv4 behaviour. The minority case can dominate support cost because it is harder to diagnose and explain.

Fixed broadband providers face a different version of the same problem. Residential customers may not pay separately for public IPv4 until they need inbound reachability. Small businesses often discover the requirement through security cameras, point-of-sale systems, accounting software, VPNs, telephony, email reputation or remote management. A provider that charges clearly for a static public IPv4 risks customer anger. A provider that gives it away consumes scarce inventory. A provider that refuses it pushes customers toward workarounds or higher-tier competitors. Each option assigns the cost differently.

Low-ARPU markets make the accounting harsher. The price of equipment, software, support labour and public IPv4 may be linked to foreign currency or global markets, while customer revenue is local and thin. A duplicate stack that looks manageable in a wealthy metro network can become a material burden where monthly access prices leave little margin. IPv6 may be necessary, but it does not pay the invoice by itself. The cost lands on the provider until the provider can pass it to users, suppliers, public buyers or investors.

This is why "just deploy IPv6" is incomplete as economic advice. The provider may already be deploying it. The bill remains because the commercial product is not "IPv6 access". The product is reachability to the customers, services and institutions that still treat IPv4 compatibility as part of normal Internet access.

Cloud and hosting turn compatibility into priced optionality

Cloud and hosting markets reveal another form of cost incidence: optionality. A public IPv4 address was once treated by many customers as an ordinary part of a server, load balancer or virtual machine. As scarcity became more explicit, large platforms began pricing public IPv4 more visibly or designing architectures that encourage private addressing, NAT gateways, IPv6-only subnets, load balancers and managed front doors. The result is not simply a technical redesign. It is a shift in who pays for compatibility.

The large platform has bargaining power. It can say that public IPv4 is scarce, that public addresses are chargeable, that IPv6 is available, that private networking is preferred, and that customers should architect accordingly. Some customers can adapt. Others cannot. A small SaaS provider serving conservative enterprise customers may need static IPv4 reachability for allowlists. A payment or security product may need predictable source addresses. A government supplier may need compatibility with older systems. A managed-service firm may need IPv4 because its customers' customers still require it. The cloud platform converts scarcity into a menu of priced choices. The customer discovers incidence through architecture bills.

Hosting firms sit in a tighter bind. Many compete on visible monthly prices. A dedicated IPv4 address can be a major share of the economics of a very cheap VPS. If the host includes it, margin falls. If it charges separately, the offer looks less cheap. If it shares addresses or uses NAT, customer expectations may break. If it pushes IPv6-only hosting, demand may be limited by customer reachability, tooling and comfort. The host may therefore become a retail translator of global address scarcity: it buys or leases scarce compatibility at market prices and sells it into a customer base trained to see it as a minor feature.

Asia-Pacific adds platform geography to this problem. A start-up in one economy may host in another, buy transit from a third, serve users in several more, and depend on a global cloud whose pricing and network architecture are set elsewhere. The APNIC registry layer records number resources in the region, but compatibility costs are not confined neatly inside the region. A Singapore cloud region, an Indian mobile user, a Japanese enterprise allowlist and an Australian public-sector supplier may all appear in the same service chain. Whoever has the strongest platform position can shift the public IPv4 bill downstream.

IPv6 can lower some costs when traffic stays inside IPv6-capable content networks, mobile networks and cloud paths. Yet the cloud customer does not pay for the average case alone. It pays for the exception that must not fail. A business cannot tell a bank, regulator, enterprise client or procurement platform that a legacy integration should modernise before the contract starts. It buys compatibility. That purchase may be a public IPv4 address, a NAT gateway, a load balancer, a dual-stack firewall, a consultant's time, or a more expensive platform tier. The economic item is the same: optionality under scarcity.

Procurement quietly writes the compatibility standard

Procurement is one of the least dramatic but most powerful channels of dual-stack cost incidence. Large customers rarely announce that they are preserving IPv4 scarcity. They write requirements. A tender asks for compatibility with existing systems. A security review asks for static public addresses. An enterprise architecture team asks for IPv4 source ranges. A public body asks for support across all users. A bank asks suppliers to maintain allowlisted endpoints. A vendor appliance ships with partial IPv6 support but complete IPv4 assumptions. The supplier then carries the cost of satisfying the requirement set.

This makes procurement a hidden transition regulator. If buyers require IPv6 but still insist on IPv4 compatibility, suppliers must run both. If buyers demand low prices while keeping old compatibility requirements, suppliers absorb the duplicate cost. If buyers treat public IPv4 as a standard feature, suppliers must decide whether to reveal scarcity or hide it. If buyers punish visible add-ons, the cost moves into margin. The purchasing document becomes an incidence instrument.

Public-sector procurement is especially important in Asia-Pacific because governments, state-owned enterprises, universities, hospitals, transport authorities and public-service suppliers often anchor demand. Some public bodies may support IPv6 policy in principle while still depending on legacy applications, old security appliances, conservative risk committees or outsourced systems that expect IPv4. Their suppliers cannot force a clean cutover. They bid for the contract as it exists. The public buyer receives continuity; the supplier pays for coexistence unless it can price the risk into the bid.

Enterprise procurement creates similar effects. A multinational may ask branches across APNIC economies to meet global connectivity standards. The central policy may include IPv6 readiness, but the local implementation may still need IPv4 for legacy industrial systems, vendor portals, remote access, DNS, email reputation, content filtering, logs or compliance. Local network providers and integrators carry the complexity. If they are small, they may lack the bargaining power to charge fully for it.

The point is not that procurement teams are wrong to demand compatibility. Their job is to reduce operational risk. The point is that compatibility is not free. When the cost is not made visible, it is assigned by bargaining power. Large buyers can push it to suppliers. Large suppliers can push it to subcontractors. Platforms can push it to customers. Small operators may push it to users through poorer support or limited product features. The final distribution is not engineered by protocol design. It is produced by contracts.

APNIC cannot rewrite those contracts. What it can do is keep the underlying number-resource state legible enough that procurement does not become more uncertain than necessary. Accurate registry records, transfer clarity, contact reachability, routing-adjacent evidence and continuity discipline reduce one part of the risk premium. They do not erase the procurement layer's ability to move costs onto weaker parties.

Support desks pay in ambiguity

Many dual-stack costs are not capital expenditure. They are ambiguity. A support desk must decide whether a customer's problem is Wi-Fi, DNS, IPv6 preference, IPv4 CGNAT, remote server geolocation, application design, firewall policy, CPE firmware, stale reverse DNS, abuse reputation, MTU, routing, cloud security groups or an enterprise allowlist. Every extra possibility lengthens diagnosis. The cost appears as longer calls, better staff training, escalation queues, churn risk and frustrated customers.

This is a real economic burden because support labour is not infinitely elastic. In high-income markets it is expensive. In low-income markets it is scarce relative to revenue. In multilingual markets it is harder to script. In small networks one senior engineer may be the escalation path for routing, firewall, customer equipment and abuse complaints at the same time. Dual-stack makes the failure tree wider.

IPv4 scarcity adds its own ambiguity. A customer behind CGNAT may see authentication failures, blocked ports, gaming issues, remote-access problems, geolocation errors or reputation problems caused by someone else sharing the same public exit. The support desk must explain shared public identity without making the customer feel downgraded. If the fix is a paid public IPv4, the provider has converted a technical diagnosis into an upsell. If the provider gives a public IPv4 for free, it consumes scarce inventory. If it refuses, the customer may leave. Again, incidence follows bargaining power.

IPv6 can also create support ambiguity. A site may work over IPv4 but fail over IPv6 because of remote misconfiguration, path issues, firewall gaps or application assumptions. The customer experiences one broken service. The provider sees a distributed responsibility problem. If the provider disables IPv6 to reduce tickets, it slows adoption. If it keeps IPv6 enabled, it pays the support cost. If it tells customers that remote services are at fault, it may sound evasive. The economic incentive is therefore not simply pro- or anti-IPv6. It is a search for the lowest support-cost equilibrium.

This is one reason dual-stack remains durable. The technology can be clean in diagrams while messy in customer service. A public claim of IPv6 progress does not tell us whether support costs have fallen, whether IPv4 exceptions have shrunk, whether customers understand shared-address limits, or whether staff can diagnose both families without expensive escalation. The incidence is hidden in queue time.

APNIC's relevance here is indirect. Registry accuracy can help with certain kinds of diagnosis: who holds a block, what contacts exist, whether routing-adjacent records are coherent, whether reverse-DNS delegation is plausible, whether transfers left residue. But many support burdens sit below or above the registry layer. A registry cannot know which customer's camera refuses IPv6, which payment vendor still requires static IPv4, or which cloud firewall rule was copied from an old template. Thin coordination means helping where public records matter and not pretending to own the rest.

Security and compliance make the second stack durable

Security teams are often treated as obstacles to transition. In reality, they are cost accountants. They know that every new path requires policy, monitoring, evidence and incident response. Dual-stack doubles some of those surfaces, but not always symmetrically. The result is a durable second stack because no responsible security team wants to remove a control before the dependency map is complete.

A firewall rule set may need IPv4 and IPv6 equivalents. A security information and event management system may need to parse both. Abuse handling may need logs that distinguish public IPv4 exits, private customer identities, IPv6 prefixes and time windows. Vulnerability scans must cover both families. DDoS mitigation must understand both. Customer allowlists must be maintained in formats that old enterprise tools accept. Incident reports must be intelligible to customers, regulators, insurers and sometimes law enforcement. Each item creates labour.

IPv6's abundance does not eliminate evidence requirements. If anything, it changes them. Address space is plentiful, but accountability still needs structure. Which customer used which prefix? Which device was delegated which address? How long is the assignment retained? How does privacy interact with logging? How do abuse desks treat IPv6 reports compared with IPv4? How do internal tools avoid missing one family? The cost is not scarcity alone; it is responsibility.

IPv4 scarcity, however, raises the stakes. Shared exits require port logs and precise timestamps. Public IPv4 addresses with poor reputation require remediation. Transferred blocks need history checks. Leased space may need clearer operational delegation. Reverse-DNS and route-origin state can affect trust. A compliance team reviewing a network supplier may ask not only whether the supplier supports IPv6, but whether its IPv4 compatibility layer can produce evidence under pressure. That evidence has a cost.

In Asia-Pacific, compliance expectations can cross jurisdictions. A service may operate in one economy, host in another, use address resources registered through APNIC or an NIR, serve users across borders and answer requests from multiple legal systems. Dual-stack does not simplify that world. It adds more records, more paths and more proof burdens. The party closest to the customer may be expected to answer even when the technical cause sits elsewhere.

Security therefore keeps coexistence alive in a way that protocol optimism underestimates. A clean cutover is not only a traffic decision. It is an evidence decision. If an enterprise, public body, insurer or regulator still expects IPv4-compatible evidence, the supplier must maintain it. If a network cannot trust that all counterparties are IPv6-ready under stress, it preserves IPv4. The dual-stack bill becomes a risk premium.

NIR seams shape who feels APNIC's region

APNIC's region includes National Internet Registry relationships in several economies. NIRs can reduce local language, documentation and service friction, but they also create seams. For dual-stack cost incidence, the seam matters because local registry arrangements can affect timing, documentation, transfer experience, member communication, policy interpretation and support expectations.

The seam is not inherently bad. Local registry functions can make number-resource administration more accessible in large economies with distinct language, legal and operator communities. A provider may find it easier to engage through a familiar local institution than through a regional office. Local support can lower search costs and help smaller operators understand registry requirements. In a region as varied as Asia-Pacific, that can be valuable.

But seams can also create uneven incidence. A network operating across borders may face different documentation expectations, transfer norms, timelines or service channels depending on where resources sit. A cloud or enterprise buyer may prefer address assets with clearer transfer histories or more predictable registry treatment. A small operator may experience local help as support or as another compliance layer. Where the seam adds delay or uncertainty, the cost is paid by the party needing compatibility now.

This is especially relevant to dual-stack because coexistence often depends on timing. A customer contract begins next month. A public-service deployment needs static reachability by a fixed date. A cloud migration requires predictable source addresses. A fintech integration cannot wait for a philosophical argument about protocol futures. If public IPv4 evidence, transfer state or routing readiness is delayed, the supplier may use more expensive alternatives, retain old architecture, lease temporary addresses, buy cloud public IPs, or absorb the risk. Registry timing becomes a cost input.

APNIC's best discipline is therefore not to pretend that a uniform region exists where it does not. It is to keep the regional ledger and related records as predictable, portable and low-friction as possible while respecting local service realities. The narrower the registry function, the less it distorts cost incidence. The broader the registry discretion, the more it becomes another variable that weaker operators must price.

This is the ledger-not-gatekeeper point in practical form. A registry should make it easier to know who controls a resource and how continuity is preserved. It should not use scarcity or transition rhetoric to decide whether a network's dual-stack cost is morally acceptable. The NIR seam should reduce friction, not become a local veto over capital or compatibility.

End users pay when the market hides the line item

End users rarely see the dual-stack invoice. They see service quality, price, product tiers and unexplained limitations. A residential customer may be told that a public IPv4 address requires a business plan. A gamer may blame the network for shared-address problems. A small shop may pay for a static address because its payment or camera system needs it. An enterprise user may pay a cloud bill with separate public IP charges. A public-service user may suffer slow issue resolution because the supplier cannot easily identify which layer failed.

Hidden incidence is still incidence. When an access provider buys CGNAT equipment and support tools, the cost enters monthly prices or margin. When a hosting firm charges for IPv4, the user pays directly. When a cloud platform prices public IPv4, the customer sees a line item. When a provider cannot afford enough compatibility, the user pays through degraded service. When a public procurement rule forces suppliers to maintain old compatibility without extra budget, taxpayers may pay through higher bids later or reduced supplier quality now.

The unfairness is not always visible. Wealthier users can buy out of shared-address friction. They can pay for static IPv4, enterprise support, better cloud architecture, managed security or consultants. Poorer users take the default. If the default is CGNAT with limited inbound reachability, longer support queues and occasional reputation spillover, that is their share of the dual-stack tax. The market may not call it a tax, but it functions like one when the cost is compulsory for participation and hidden in access quality.

This is why dual-stack incidence belongs in registry governance analysis even though much of the cost sits outside APNIC. The scarcity of IPv4 is not just a technical fact; it shapes service tiers. Registry recognition, transfer clarity and continuity affect the cost of public IPv4 supply. When the registry layer is uncertain, the premium rises. When it is thin and predictable, the premium can fall. End users experience the result indirectly.

Yet APNIC should not be asked to become a consumer regulator. That would confuse layers. The user's problem may be real, but the remedy is not to turn a number registry into a pricing authority, help-desk supervisor or product-quality agency. The registry's contribution is more modest and more important: keep the public record trustworthy enough that markets can price scarcity honestly and operators can acquire, hold, transfer and document resources without unnecessary institutional risk.

Honest pricing is not the same as cheap pricing. IPv4 may become more visibly expensive as scarcity is recognised. That visibility can feel uncomfortable. But hidden cost is not fairness. It merely assigns the bill to those least able to negotiate.

The APNIC boundary: reduce uncertainty, do not allocate the bill

The temptation in any scarcity debate is to ask the registry to decide fairness. That temptation should be resisted. APNIC's strength should be the narrowness of its role. It can record. It can coordinate. It can protect uniqueness. It can support registry accuracy, contactability, transfer legibility and routing-adjacent trust. It can publish rules, timelines and evidence expectations. It can reduce uncertainty around number resources. It cannot decide the correct retail price of public IPv4, the right cloud architecture, the proper level of CGNAT, or which customer deserves compatibility.

This boundary is not anti-governance. It is disciplined governance. When the registry expands into economic judgement, it imports costs it cannot measure and liabilities it does not bear. A registry does not pay the access provider's support staff. It does not lose the hosting customer's renewal. It does not carry the enterprise supplier's service-level penalties. It does not compensate users when an application fails behind shared IPv4. It does not finance the operator's scarce-address purchase. It should therefore be careful about policies that affect these outcomes while describing themselves as neutral stewardship.

APNIC can help most by making the scarce input less ambiguous. Transfer records should be clear. Resource-holder status should be reliable. Contact data should be useful without becoming an enforcement trap. Routing-adjacent records should be coherent. Reverse-DNS delegation should be stable. Disputes should be visible where they affect reliance. Decisions that impair continuity should be narrow, reasoned and reviewable. Fees should be tied to necessary registry functions rather than institutional sprawl. NIR relationships should reduce friction rather than create hidden discretion.

These are not minor administrative preferences. They affect cost of capital. A buyer, lender, cloud provider, lessor, public buyer or enterprise customer prices uncertainty. If registry-state uncertainty is high, the dual-stack bill rises because operators keep more safety stock, buy redundant services, avoid transfers, overpay for trusted blocks, or refuse contracts they cannot support. If registry-state uncertainty is low, the market can allocate resources with fewer buffers.

That is the proper APNIC incidence role: lower the registry-risk component of coexistence cost. Not eliminate IPv4 scarcity. Not command IPv6. Not police business models. Not choose winners among cloud platforms, access providers and users. A registry that tries to allocate the bill becomes part of the bill.

Cost incidence is capital allocation in disguise

Dual-stack cost incidence ultimately becomes capital allocation. A network with large IPv4 holdings can choose whether to reserve, lease, sell, redeploy or monetise them through premium services. A network with little IPv4 must buy, lease, share or redesign. A cloud platform can charge for public IPv4 and push customers toward architectures that preserve platform control. A hosting firm can segment products. An enterprise can pay for compatibility or push cost to suppliers. A public body can fund migration properly or bury compatibility in procurement. Each choice is capital allocation, even when described as technical operations.

The scarcity of IPv4 makes those choices consequential. If IPv4 were worthless, dual-stack incidence would be mostly an engineering labour problem. Because IPv4 is valuable, every public address consumed by a low-value use has an opportunity cost. Every address held in reserve is an option. Every lease is a revenue stream. Every transfer is a balance-sheet event. Every static-address customer is a pricing decision. Every CGNAT expansion is a trade between capital preservation and support cost. Every IPv6-only experiment is a bet on customer tolerance.

APNIC's region is full of operators facing different versions of that trade. Mature incumbents may have legacy depth and patience. New entrants may face high acquisition costs before revenue is secure. Fast-growing mobile providers may need scale faster than public IPv4 can be acquired. Small island networks may value continuity more than theoretical efficiency. Cloud and data-centre firms may treat public IPv4 as product differentiation. Public-sector suppliers may need compatibility to satisfy old systems while being judged on modernisation rhetoric.

This is why simplistic transition narratives fail. They ask the market to behave as if the scarce asset should be voluntarily depreciated before a fully equivalent substitute exists for all revenue-relevant uses. Operators do not make that decision in speeches. They make it in budgets. If IPv4 enables revenue, contracts, reputation and customer continuity, it remains capital. IPv6 can grow beside it, but growth does not erase the capital logic until counterparties stop paying for compatibility.

The phrase "dual-stack tax" captures the burden, but incidence analysis asks the next question: who writes the cheque? Sometimes the operator. Sometimes the cloud customer. Sometimes the hosting user. Sometimes the taxpayer. Sometimes the support worker. Sometimes the low-income household receiving a worse default. Sometimes the shareholder, through lower margin. Sometimes the buyer of a network, through a higher or lower valuation depending on address inventory. The tax is real because the cost is real; the distribution is political economy.

IPv6 success does not decide IPv4 incidence

One of the easiest mistakes is to treat IPv6 success as evidence that IPv4 costs should disappear. The APNIC region shows why this is wrong. IPv6 can be very successful in measured traffic while IPv4 remains economically decisive for particular transactions, customers and institutions. A network may carry a majority of some traffic over IPv6 and still need scarce public IPv4 for the minority of cases that carry high revenue, high risk or high complaint potential.

This is a common feature of infrastructure. The average path is not the whole business. A railway may move most passengers smoothly while a few bottlenecks determine investment. A power grid may have abundant generation while a small transmission constraint sets local prices. A payment network may process most transactions automatically while compliance exceptions consume expensive labour. In dual-stack networks, the troublesome minority can set the cost structure.

The minority also changes over time. As consumer content, mobile platforms and large clouds improve IPv6 support, ordinary traffic may shift. But enterprise allowlists, legacy appliances, public tenders, customer support habits, small-business devices, industrial systems and reputation systems can lag. Some will modernise. Some will be replaced slowly. Some will be hidden inside contracts for years. The result is not a clean transition curve but a layered coexistence economy.

APNIC should be judged against that reality, not against a slogan. A useful registry does not need to prove that IPv6 will save the region from scarcity. It needs to keep the number-resource layer reliable while markets discover the real price of compatibility. If APNIC's records, transfer practices, NIR relationships and continuity rules reduce uncertainty, they lower the cost of coexistence. If they add discretion, delay or capital-control language, they raise it.

For operators, the sensible approach is similarly unsentimental. Deploy IPv6 where it reduces cost, improves reachability or satisfies customers. Preserve IPv4 where it protects revenue, reputation or continuity. Price public IPv4 honestly. Treat CGNAT as a costed compression tool, not a free miracle. Train support teams for the cases that actually arrive. Make procurement exceptions visible. Use registry evidence as a confidence layer. Do not pretend the second stack is free because the first is scarce, or that the first stack is obsolete because the second is abundant.

The economic end state may be less dramatic than either side of the debate wants. IPv6 grows. IPv4 remains capital. Dual-stack persists where contracts require it. Costs move toward the parties with the least bargaining power unless institutions make them visible. That is not a failure of engineering. It is the normal behaviour of markets under scarcity.

A narrow discipline for APNIC-era coexistence

The discipline APNIC needs for dual-stack cost incidence is modest and strict. Keep the ledger accurate. Keep transfers legible. Keep resource-holder recognition predictable. Keep routing-adjacent evidence stable. Keep NIR seams service-oriented. Keep adverse actions narrow. Keep registry fees and duties tied to essential functions. Keep public language honest about scarcity. Above all, do not use IPv6 transition rhetoric to expand registry discretion over IPv4 capital.

This discipline would not make dual-stack cheap. It would make the cost more honestly placed. Operators would still decide how much public IPv4 to hold, lease, buy or reserve. Cloud platforms would still price public reachability. Enterprises would still decide whether old allowlists are worth maintaining. Public bodies would still need to fund compatibility when they require it. Users would still face product tiers. But the registry-risk premium would be lower because the number-resource layer would be less mysterious.

That is the realistic ambition. A registry cannot abolish scarcity. It cannot make every application modern. It cannot force every buyer to rewrite procurement. It cannot remove every CGNAT support ticket. It cannot make public IPv4 free without destroying the signal that scarcity creates. It can, however, avoid making the scarce input more expensive through uncertainty, discretionary language, slow transfers, weak continuity or institutional self-expansion.

The lesson for APNIC is therefore not that it should become the champion of IPv6 or the defender of IPv4. Both framings are too broad. The registry should be the reliable address book for a region in which both address families matter for different reasons. IPv6 is a reachability expansion. IPv4 is scarce productive capital. Dual-stack is the coexistence contract between them. The cost of that contract belongs in the market, in procurement, in support budgets, in cloud architecture and in public-service funding. APNIC's duty is to prevent the registry layer from adding unnecessary rent to the contract.

The bill is already being paid. The only question is whether it remains hidden in defaults, delays, support queues and weak bargaining positions, or becomes visible enough for networks and customers to make rational decisions. In Asia-Pacific, where the same registry region contains advanced cloud economies, vast mobile markets, small islands, low-income access networks and national registry seams, that visibility is not a luxury. It is the condition for fairer cost allocation.

Dual-stack will not be settled by a declaration that one protocol won. It will be settled by incentives. The parties that need compatibility will pay for it directly, force suppliers to include it, or accept lower quality when they refuse. The parties that hold scarce IPv4 will price it, reserve it or deploy it where returns justify the cost. The parties that build IPv6 will do so where it reduces friction or opens reachability. APNIC should make those choices safer to record, not harder to make.

That is the economics of dual-stack cost incidence: not a tutorial about addresses, not a sermon about transition, but a map of the bill. The map shows a simple truth. Running two reachability systems is expensive because the market still values both. Until that changes, the honest governance question is not how to make operators say the right thing about IPv6. It is how to keep the registry layer narrow enough that the people who actually pay the bill can see it, price it and control it.