Summary
- Dual-stack is not a transitional slogan. It is a duplicated operating budget in which IPv4 scarcity and IPv6 deployment coexist across routing, firewalls, monitoring, help desks, logging, procurement, software support and customer contracts.
- The cost does not fall on the party that most loudly supports or delays transition. It lands where compatibility is least avoidable: ISPs running CGNAT, hosting firms maintaining public IPv4 products, enterprises with old systems, security teams validating two address families, support desks interpreting failures, and customers buying public IPv4 exceptions.
- ARIN's constructive role is not architectural morality. It is ledger-quality evidence: accurate public records, transfer clarity, reverse-DNS continuity, routing-security support, contactability, and portability-friendly restraint while the market discovers the true price of coexistence.
Dual-stack is a second operating budget, not a bridge painted as progress
Dual-stack sounds temporary because the phrase is usually spoken from the destination backwards. IPv6 is the long-run abundance path; IPv4 is finite; therefore networks run both until the older protocol can be retired. The engineering logic is tidy. The income statement is not. In the ARIN region, dual-stack has become less a bridge than a duplicated operating budget. It keeps two address families alive in routers, firewalls, access networks, cloud products, monitoring tools, compliance files, application tests, help desks, sales terms and customer exceptions.
The relevant question is not whether IPv6 is technically useful. It is who pays while IPv4 remains commercially necessary and IPv6 remains operationally incomplete. That is the question of cost incidence. A cost is not fully understood when the industry names the activity that creates it. It is understood when the industry can see where the invoice settles. A standards body can recommend IPv6. A vendor can claim support. A registry can publish guidance. A cloud provider can expose a configuration toggle. But the cost may land on the access provider that must store NAT logs, the enterprise security team that must rewrite controls, the small hosting company that must buy or lease scarce IPv4, the customer support desk that must explain strict NAT, or the buyer that discovers that a product's IPv6 support stops at the data plane and not at audit reporting.
That makes dual-stack a political-economy problem at a narrower level than the broad IPv6 transition debate. The broad debate asks why the world has not moved faster. The cost-incidence debate asks who is carrying the coexistence bill today. The answer is rarely the actor whose delay created the burden. An enterprise that keeps an old IPv4-only supplier portal may not pay the full cost of access networks maintaining IPv4 reachability. A vendor that ships uneven IPv6 support may not pay the cost of customer test labs and exception handling. A cloud platform that charges separately for public IPv4 may make the scarcity visible, while the customer still pays for refactoring, logging and compliance review. A public body that writes IPv6 goals into policy may still procure systems that keep IPv4 allowlists alive for years.
ARIN sits near this problem because the public number-resource record is part of the evidence environment in which costs are assigned. ARIN does not design an ISP's CGNAT ratio, decide a hospital's firewall rules, choose a cloud customer's architecture or rewrite software that assumes an IPv4 literal. Its position is narrower and more durable. It maintains the recognised public record for number resources in its service region, including the United States, Canada and parts of the Caribbean and North Atlantic. Its records, contact roles, reverse-DNS support, routing-security services, transfer recognition and public status signals affect whether scarce IPv4 can be treated as dependable operating capital while IPv6 expands.
The official registry exhibit is useful but not sufficient. ARIN's public materials record the depletion of its free IPv4 pool in September 2015, the remaining waiting-list and transfer paths for IPv4, the availability of IPv6 resources, and the importance of route-origin evidence and reverse-DNS continuity. Those facts show the institutional setting. They do not answer the incidence question. The cost of coexistence is discovered in the places where a packet, a log line, a customer ticket and a contract meet.
This article therefore treats dual-stack as a cost-allocation system. It does not retell the general transition story. It follows the bill: into NAT gateways, support queues, security dashboards, procurement language, vendor roadmaps, cloud products, hosting margins, compliance evidence and registry records. In that view, IPv4 scarcity does not simply make old addresses expensive. It makes every incomplete IPv6 deployment an accounting event. Someone must pay for the layer that keeps the old world reachable while the new one is only partly useful.
Packets are cheap; evidence around packets is expensive
The first mistake is to price dual-stack by the packet. A packet moving across IPv4 and a packet moving across IPv6 may not appear very different in the largest cost categories of a modern network. The expensive part is the evidence, control and interpretation around the packet. Which customer used this public IPv4 address and source port at this second? Which firewall policy applied to the IPv6 path? Which SIEM parser normalised the address? Which reverse-DNS name was expected by the mail system? Which allowlist did the partner maintain? Which monitoring alert actually identified the failing family? Which support script told the customer what to do?
Dual-stack duplicates the operational surface because the two protocols are not interchangeable from the perspective of every tool and contract around them. A router may support both. A business process may not. A firewall rule set may include IPv6, but old application documentation may not. A monitoring product may display both families, but the on-call engineer may not have the same historical baselines for IPv6. A log pipeline may store IPv6 addresses, but a fraud tool may still cluster risk around IPv4. A procurement clause may require IPv6, but the acceptance test may only prove web reachability and not operational parity.
This is why the duplicated budget is hard to see. It is spread across departments that do not label it as dual-stack. The network team pays through address planning, routing policy, DNS, gateway capacity and change windows. The security team pays through rule conversion, log retention, detection engineering, incident-response procedures and vendor exceptions. The help desk pays through training and ticket volume. The compliance team pays through evidence collection and audit language. Procurement pays through specification writing and supplier challenge. Finance pays through public IPv4 purchases, leases, cloud surcharges and the opportunity cost of holding address reserves. Customers pay through premium public IPv4 options, broken applications, stricter NAT, or the labour of changing their own systems.
The cost is often triggered by the weakest link. A network can deploy IPv6 well and still carry IPv4 because a major customer, bank, government service, gaming platform, industrial device, payment system or partner VPN expects IPv4 behaviour. A cloud workload can be IPv6-capable and still require public IPv4 because a managed security appliance, support vendor, SaaS integration or audit checker is not ready. A hosting provider can give customers IPv6 and still maintain IPv4 products because customers measure service quality by whether old visitors can reach them. In each case, the cost falls on the integrator rather than on the laggard.
This is a familiar institutional pattern. The party best placed to fix the dependency is not always the party closest to the customer pain. A software vendor can postpone full IPv6 parity, but the managed-service provider must support the enterprise that bought the software. A customer can keep IPv4-only allowlists, but the cloud provider must continue selling public IPv4 addresses. A device manufacturer can ship years of equipment with uneven IPv6 behaviour, but the broadband provider must answer the phone when the home camera fails. The bill is passed along the chain until it reaches the actor with a service-level promise.
IPv4 scarcity makes that pass-through more visible. When public IPv4 was administratively easier to obtain, coexistence cost could be hidden inside network growth. After depletion, each public address has an opportunity cost. The access provider choosing between a consumer CGNAT pool, a fixed-wireless public-IP add-on and an enterprise APN is allocating scarce capital. The hosting firm deciding whether to include public IPv4 in a basic VPS package is deciding whether to absorb scarcity or expose it as a charge. The cloud customer seeing a public IPv4 line item is being shown a cost that previously looked like a default.
The packet remains cheap compared with the operating assumptions around it. Dual-stack incidence therefore has to be measured in support time, compliance work, exception processing, address inventory, reputation repair, log storage, security-tool gaps, vendor remediation and customer friction. The network that only counts routed traffic will undercount the bill. The network that counts the evidence around routed traffic will see why coexistence persists even when everyone says the future is IPv6.
Access providers pay through CGNAT, logs, exceptions and reputation
The access provider is the first visible bearer of the dual-stack bill because it has to keep ordinary customers connected to a mixed Internet. Broadband subscribers, mobile users, fixed-wireless homes, small businesses, public-safety devices, roaming users and connected vehicles do not buy a protocol plan. They buy working service. If a bank, game, video platform, camera, VPN, tax portal or payment terminal requires IPv4 somewhere in the path, the provider must carry that compatibility regardless of how strongly it supports IPv6.
In a post-exhaustion region, the usual answer is a mixture of IPv6 deployment and IPv4 sharing. Carrier-grade NAT lets many customers use fewer public IPv4 addresses. It is economically rational and often unavoidable. But it converts address scarcity into other costs. The provider must size NAT gateways, manage port allocation, maintain mapping logs, keep clocks aligned, segment pools, preserve lawful-response evidence, repair reputation damage and explain failures to customers who cannot see the translation layer. The public IPv4 address becomes shared public identity, and shared identity requires evidence to interpret.
Logging is the most obvious hidden tax. When many customers share one public IPv4 address, an outside complaint or lawful request that names only the address is weak. A responsible answer may require source port, precise timestamp, time zone, protocol, gateway identifier, public pool and subscriber mapping. Storing that information at scale is not merely a disk problem. It requires retention rules, access controls, audit trails, legal procedures, privacy safeguards and staff able to distinguish usable evidence from vague accusations. A network that saves IPv4 addresses by sharing them buys an evidentiary system around that sharing.
Ports become rationed units inside the translator. A casual smartphone session may consume little. A household fixed-wireless router with game consoles, cameras, video calls, remote-work tools and VPNs may consume more. Enterprise devices may need stable behaviour. Public-safety or payment systems may have stricter expectations. The provider must decide how densely to share addresses, when to reserve cleaner pools, which customers deserve static public IPv4, and how to price exceptions. These decisions are not technical tidying. They are scarcity allocation inside a retail network.
Support desks make the cost visible before finance does. Customers complain about strict NAT warnings, broken inbound connections, camera access, VPN instability, geolocation mistakes, repeated bank verification, game matchmaking failures and blocked logins. Many of those tickets begin as application problems in the customer's mind. They become network problems when the customer expects the provider to fix them. The desk needs scripts that distinguish CGNAT limits, IPv6 path issues, NAT64 behaviour, device faults, remote-platform blocks and true outages. Training that desk is part of the dual-stack budget.
Reputation spillover is another incidence channel. If one compromised device or malicious user sends abusive traffic through a shared public address, external systems may penalise the address and affect many innocent users behind it. A mail receiver, bank, streaming service, fraud platform or security vendor may not immediately distinguish the translation crowd. The access provider then spends time segmenting pools, contacting reputation services, moving affected customers, adjusting NAT density or selling cleaner public IPv4 products. The party that caused the abuse may be one customer; the cost lands on the provider and on unrelated customers sharing the pool.
IPv6 helps the access provider when real traffic moves. Modern mobile and broadband networks can offload large volumes to IPv6 and reduce pressure on public IPv4 egress. Yet that progress does not remove the coexistence bill while important services remain IPv4-dependent. NAT64 and related translation approaches reduce one category of cost and create another set of diagnostics. A support desk still has to explain why an IPv6-capable customer cannot reach an IPv4-only destination or why an application using literal IPv4 addresses behaves differently.
The access provider therefore pays twice: once to deploy IPv6 and again to preserve IPv4 compatibility. It may pass some of the second bill to customers through static public IPv4 fees, business-tier pricing or fixed-wireless premium options. But the underlying incidence remains with the provider because it owns the retail promise that access works. ARIN's record does not change the CGNAT ratio. It matters because the public pools used for CGNAT need accurate holder records, contactability, reverse-DNS support and route-origin evidence. A stale or ambiguous public record makes every abuse complaint, lawful request and reputation repair more expensive.
Hosting and cloud providers turn coexistence into product segmentation
Hosting and cloud businesses experience dual-stack as product design. They must decide whether public IPv4 is included, charged separately, reserved for premium tiers, recycled aggressively, leased, bought, or hidden inside managed services. They also must decide how much IPv6 parity to deliver across load balancers, object storage, databases, firewalls, Kubernetes ingress, managed VPN, monitoring, identity integrations, control planes and support tools. A product can advertise IPv6 support and still leave customers paying for the remaining IPv4 dependencies.
The cloud market has made public IPv4 scarcity unusually visible because public IPv4 can appear as a line item. That is economically clarifying. It tells customers that compatibility is no longer free. But the charge is only the most visible part of the bill. A customer that wants to reduce public IPv4 exposure may need to redesign application endpoints, change partner allowlists, alter DNS, revise firewall policy, update monitoring, rewrite Terraform modules, review compliance evidence, educate support teams and test failover. The cloud platform exposes a price; the customer pays the migration labour.
Hosting firms face a harsher version because their customers may be smaller, less prepared and more price-sensitive. A low-cost VPS buyer may expect a public IPv4 address because that is how hosting has long been sold. A small business may not understand why an IPv6-only service loses visitors or why an email server needs address reputation. A developer may prefer IPv6 in principle but still require IPv4 because package repositories, webhook targets, corporate networks or customers remain mixed. The hoster must decide whether to absorb scarce IPv4 costs in a competitive price or make the cost explicit and risk churn.
Public IPv4 becomes a differentiator. A provider with deep legacy inventory can include addresses more easily, reserve clean ranges for higher-value customers, or offer static IPv4 products with confidence. A newer or smaller provider may lease addresses, buy at market prices, run tighter allocation rules, or push customers toward shared load balancers and IPv6-first designs. The customer sees product packaging. The operator sees capital structure.
Dual-stack also affects platform assurance. A cloud or hosting provider may support customer-owned address space, but the acceptance file around that space must be coherent. The provider may ask who is recognised in the public registry, which autonomous system is authorised to originate the prefix, whether route-origin evidence is current, whether reverse DNS can move, and which contact can approve changes. These checks are not philosophical questions about address ownership. They are risk controls around accepting a customer's network identity into the provider's infrastructure.
That creates another incidence problem. A customer that brings its own IPv4 or IPv6 space benefits from portability, but the provider pays in verification, support and exception handling. If the provider hides that work inside a generic support plan, it underprices a service that can be central to customer continuity. If it prices the work explicitly, the customer may see it as a nuisance fee rather than evidence assurance. The same pattern appears in IPv6 migration support: customers want the benefit of future readiness, but they often resist paying for the engineering required to make it operationally boring.
Managed services can conceal the bill. A customer buying a managed firewall, CDN, WAF, database or application platform may believe protocol support is the provider's problem. The provider may indeed absorb much of it. But the customer still pays indirectly through product price, feature limitations, separate public IPv4 charges, restricted regions, slower availability of IPv6 on some products, or paid support engagements. Dual-stack cost is rarely eliminated. It is bundled.
For ARIN, the hosting and cloud problem reinforces a narrow registry function. Transfers, public records, reverse DNS and routing-security services make scarce address capacity easier to use in a product economy. If a hosting firm buys or leases IPv4, it needs a record that counterparties can trust. If a cloud imports customer space, it needs evidence that reduces false authority and route confusion. If customers price public IPv4, they need to know that the scarcity is real and not merely a vendor margin story. ARIN should make that evidence reliable, not decide whether a cloud product should charge for a public address.
Enterprises and public buyers often export their delay to suppliers
Enterprises are both victims and causes of dual-stack cost. They inherit old applications, audit controls, device fleets, supplier integrations, remote-access systems, industrial equipment, payment paths, identity tools, firewall rules and partner allowlists built around IPv4. Moving them to IPv6 is rarely a single project. It is a long sequence of discovery, testing, exception retirement, supplier negotiation, policy rewrite and user support. Because the work crosses departments, the cost often gets exported to suppliers.
The export begins with procurement. A buyer may require IPv6 support in a request for proposals while awarding points for price, schedule and familiar functionality that favour the incumbent IPv4-heavy product. A supplier may check the IPv6 box because the product's front-end endpoint supports it, while logging, management APIs, backup services, alerting, audit exports or partner integrations remain uneven. The buyer records a compliant procurement. The integrator later pays when the product must be operated in a dual-stack estate.
Firewalls expose the gap. An enterprise with mature IPv4 policy may have years of rule history, naming conventions, exception approvals, change windows and audit evidence. IPv6 forces a review of assumptions: address length, grouping, neighbour discovery, extension headers, dual-path monitoring, VPN design, segmentation and threat detection. The enterprise may delay because the existing IPv4 policy works well enough. Its cloud provider, managed-security supplier or access network then continues to support IPv4 compatibility. The cost moves outward.
Allowlists are one of the most persistent exports. Banks, logistics firms, payment processors, public-sector portals and supplier systems often identify partners by public IPv4 egress addresses. Those allowlists become business memory. A customer that wants to move to IPv6 or change public IPv4 sources must coordinate with many counterparties that may not have modernised. The cost of renumbering or adding IPv6 is not the address; it is partner coordination, ticketing, test windows, audit sign-off and the fear that one forgotten integration will break revenue.
Public-sector buyers intensify the problem because public services must remain reachable by diverse users. A government portal, court system, benefits platform, tax interface, emergency service, school system or health exchange cannot break users merely to accelerate protocol purity. That obligation is real. It also keeps IPv4 compatibility alive through supplier contracts. A public body can publish an IPv6 goal and still require suppliers to maintain IPv4 reachability because citizens, contractors, agencies and legacy systems remain mixed. The cost lands on the contractor or network provider that must meet the service promise.
Enterprise monitoring adds another bill. Asset inventories must represent both address families. Vulnerability scanners must cover IPv6 without overwhelming teams with duplicate or misunderstood findings. SIEM rules must normalise IPv6. Incident responders must know which logs identify a host when IPv4 and IPv6 paths both exist. Endpoint and network teams must agree on what constitutes ownership of an IPv6 address in privacy-sensitive environments. The enterprise can postpone this work, but postponement does not make the risk disappear. It shifts the cost to suppliers asked to maintain IPv4 paths and to security teams asked to accept blind spots.
Customers inside enterprises also pay through friction. Remote workers discover VPN differences. Developers face environment-specific failures. Application owners learn that hard-coded IPv4 assumptions remain. Business units find that "IPv6 supported" does not mean "IPv6 accepted by every partner." These frictions lead to requests for public IPv4 exceptions, static egress, dedicated NAT, private connectivity or managed translation. Each request is a small tax on the coexistence budget.
ARIN cannot force enterprise procurement to become honest. It can, however, make number-resource evidence strong enough that procurement and audit teams can ask better questions. Does the supplier have accurate public records for the ranges it relies on? Are contact roles current? Can reverse DNS be maintained? Is route-origin evidence aligned with the service design? Are public IPv4 charges explicit? Can the supplier explain how IPv6 support reaches logging, security and customer support, not merely packet forwarding? Registry evidence does not answer all of those questions, but it anchors the ones that depend on number resources.
Security and compliance teams pay for the laggard's ambiguity
Security teams are where dual-stack optimism often meets operational suspicion. A network can route IPv6; a security team must monitor it, investigate it, explain it to auditors, prove control over it and respond when it behaves differently from IPv4. If the tools, people and policies are not ready, IPv6 is seen as a new attack surface rather than a transition benefit. That perception is sometimes unfair. It is also often rational because incomplete visibility creates real risk.
The duplicated bill begins with logging. Systems must store IPv6 addresses correctly, search them efficiently, normalise them consistently, and correlate them with users, devices, workloads and events. A field length assumption that worked for IPv4 can break a parser. A dashboard that groups IPv4 subnets intuitively may be less useful for IPv6 without new conventions. A fraud tool may weight IPv4 reputation heavily and treat IPv6 signals weakly. A lawful or compliance request may include an IPv4 address and source port from a NAT environment, while another incident path uses IPv6 without translation. The team needs both skills.
Incident response is similarly doubled. Analysts must know whether a connection used IPv4, native IPv6, IPv6 through a tunnel, NAT64, a proxy, a cloud load balancer or a private network path. They must understand whether an IPv6 address identifies a stable server, a temporary privacy address, a customer device, or a shared service endpoint. They must ask whether a firewall allowed IPv6 because policy intended it or because nobody reviewed the default. They must decide whether blocking an IPv4 address is meaningful when the attacker also has IPv6 reachability.
Compliance adds another layer because auditors often lag technical reality. A compliance checklist written for IPv4-shaped controls may ask for network ranges, allowlists, log retention and access restrictions in ways that do not map cleanly to IPv6. The security team then becomes translator between protocol reality and audit language. It may maintain IPv4 controls because auditors understand them, while slowly building IPv6 evidence. That split becomes part of the dual-stack bill.
The laggard often does not pay. If a vendor's product cannot log IPv6 properly, the customer's security team writes compensating controls. If a partner cannot accept IPv6 allowlists, the customer's network team maintains IPv4 egress. If an auditor's evidence request is IPv4-centric, the compliance team prepares an explanation. If a public authority or private complainant sends an address-only request for a CGNAT pool, the provider must ask for ports and timestamps. The party with the weak assumption sends the cost to the party trying to operate responsibly.
Security vendors are particularly important because they can either reduce or amplify cost incidence. A firewall, vulnerability scanner, SIEM, SOAR tool, EDR product, WAF, DDoS service or identity platform that treats IPv6 as first-class lowers transition cost for every customer. A product that supports IPv6 in marketing but not in reporting, automation or support raises the customer's cost. The gap between "supports IPv6" and "operates IPv6 with evidentiary parity" is where much of the security bill hides.
CGNAT makes the compliance problem sharper for access providers and platforms. Attribution from shared IPv4 requires precise evidence. A weak request can implicate a crowd. A strong request needs public address, source port, timestamp, protocol and context. Privacy obligations require retention discipline and access control. Security obligations require enough evidence to act. The provider is asked to hold both sides: do not over-disclose, but be ready to identify a translation event when lawful or contractual process is adequate.
ARIN's part is not to certify every security tool. It is to maintain evidence that security teams can use as a reliable starting point: holder records, contact roles, public status, reverse-DNS delegation and route-origin support. A security team investigating an incident should not waste hours discovering whether a public record is stale. A compliance team reviewing a supplier should not find registry ambiguity where a clear record should exist. The registry's evidentiary quality lowers the security cost of coexistence by reducing uncertainty around the public number layer.
Software vendors sell support claims; integrators buy the missing parity
Software vendors have a powerful role in dual-stack cost incidence because their product boundaries decide where operational parity stops. A vendor can claim IPv6 support because the core service listens on IPv6, while leaving gaps in licensing servers, management consoles, telemetry, logging, high-availability clustering, backup, update mechanisms, API clients, documentation or customer support. The customer then pays for the missing pieces through integration labour.
This is not always bad faith. Old products carry old assumptions. Test matrices are expensive. Customers do not always demand IPv6 parity strongly enough to change vendor priorities. Some features depend on third-party libraries, appliances or partner services. But the economic effect is clear. A vendor that treats IPv6 as a feature rather than as full operating parity pushes cost to customers and managed-service providers.
Procurement language can make the problem worse. A buyer may ask whether a product is IPv6-ready. The answer may be yes. The better question is whether the product can be operated, monitored, upgraded, backed up, audited, supported and retired in a dual-stack or IPv6-first environment without hidden exceptions. Does the support team accept IPv6 evidence in tickets? Do logs preserve full addresses? Do dashboards group IPv6 correctly? Do access policies work with IPv6? Do APIs validate IPv6 without brittle formatting? Does the product documentation explain NAT64 or dual-path failure? Does the vendor's own cloud service have IPv6 parity?
The difference matters because integrators sit between vendor claims and customer outcomes. A managed-security provider, system integrator, cloud consultant or network outsourcer must make the product work in the customer's environment. If the vendor's support is partial, the integrator creates workarounds, preserves IPv4, writes exceptions, builds translation layers or tells the customer to delay. The vendor sold the licence. The integrator bought the burden.
Customers often reinforce this pattern by rewarding visible features over operational readiness. A cheaper product with partial IPv6 support may win the bid. Later, the security team discovers that audit exports are weak or that IPv6 alerts cannot be correlated cleanly. The customer then pays through professional services, delayed migration, public IPv4 dependence or acceptance of risk. The cost did not disappear from the purchase price. It moved into operations.
Software-as-a-service changes the form but not the problem. A SaaS provider may handle much of the network complexity internally. Yet enterprise customers still ask about egress addresses, allowlists, logs, security event formats, identity integrations, regional availability, support access and compliance evidence. If the SaaS provider supports IPv6 for user access but still relies on IPv4 for webhooks or partner integrations, customers must maintain both. If the provider changes public IPv4 ranges, customers must update allowlists. If IPv6 is not available in every region or feature, global customers pay for exceptions.
This is where IPv4 scarcity creates discipline. As public IPv4 charges become more explicit, customers have stronger reasons to demand true IPv6 parity from vendors. But discipline works only if procurement teams can distinguish parity from marketing. A vendor's statement should be treated as the start of due diligence, not the end. In a dual-stack economy, the buyer should require operational evidence: test results, log examples, support runbooks, API behaviour, monitoring integration and incident handling.
ARIN's relevance is indirect. It does not approve software. Its records help the market ask whether vendor and supplier claims about public number use are coherent. A vendor that sells managed connectivity or cloud service should be able to explain which public ranges it uses, who is recognised for them, how contactability works, whether reverse DNS is maintained and how route-origin evidence supports continuity. The evidence layer will not fix weak software, but it can prevent weak software from hiding behind vague network claims.
IPv4 scarcity converts coexistence from prudence into accounting
Dual-stack once looked like prudent engineering: run the old and new protocols until enough of the world moves. Scarcity changes the accounting. The old protocol is no longer a free compatibility blanket. It is a scarce input with market value, carrying cost and opportunity cost. Every public IPv4 address used for low-value compatibility is an address not used for a static business service, a hosting customer, an enterprise APN, a clean reputation pool, a transfer, a lease or a reserve.
That opportunity cost changes behaviour. A provider with abundant IPv4 can package compatibility as default service. A provider without it must price, ration or share. A cloud platform can charge for public IPv4 and encourage customers to redesign. A small hoster may reduce margins to remain competitive. An enterprise may buy public IPv4 from a provider rather than fix old systems because the address charge is easier to approve than an application remediation programme. A customer may pay for a static IPv4 add-on because the cost of changing partner allowlists is higher.
The important point is that scarcity does not fall equally. Large incumbents with historical holdings, mature address management and buying power can absorb or monetise the coexistence period. New entrants and smaller providers face higher relative costs. They may need to lease addresses, buy small blocks at unfavourable terms, run denser CGNAT, limit public-IP products, or persuade customers to accept IPv6-first designs before customers are ready. A dual-stack requirement that looks neutral on paper can therefore favour incumbents.
Scarcity also changes customer bargaining. A customer that needs IPv4 compatibility may choose the provider with the cleanest inventory rather than the provider with the best IPv6 design. A bank or enterprise may maintain IPv4 allowlists because changing them requires many approvals. A public-sector buyer may require IPv4 reachability because citizen access cannot be narrowed. These decisions keep IPv4 valuable. The actors making them may still publicly endorse IPv6. The budget reveals the binding constraint.
NAT and public IPv4 add-ons are hidden dual-stack taxes. They let providers continue service in a mixed world, but they expose the cost differently. A consumer behind CGNAT pays through limitations and support friction rather than an explicit line item. A small business buying static public IPv4 pays directly. A provider maintaining NAT logs pays through systems and staff. A hosting customer buying public IPv4 pays through monthly charges. A cloud customer paying for public IPv4 pays through a labelled surcharge. Each is the same broad phenomenon: the market is pricing compatibility with a finite resource.
The "tax" language should be used carefully. Not every charge is abusive. Scarcity is real, and someone must pay for scarce inputs. The problem is not that IPv4 has a price. The problem is that the price is often hidden from the actor whose behaviour sustains it. When a software vendor delays parity, the access provider may pay. When a customer refuses to modernise allowlists, the cloud provider or supplier may pay. When a public body procures old systems, citizens and contractors may pay. Clear pricing can improve behaviour by showing where delay costs money.
This is why cost incidence matters more than slogans. If the industry treats dual-stack as a noble transition expense, the bill remains foggy. If it treats dual-stack as duplicated operations with measurable incidence, budgets can change. Providers can charge public IPv4 where scarcity is real. Customers can see the cost of old dependencies. Vendors can be required to prove operational parity. Enterprises can price exceptions. Public bodies can align procurement with their stated goals. IPv6 adoption becomes a business case grounded in savings, not a sermon.
ARIN's posture should support that accounting by keeping the IPv4 record reliable and IPv6 access clear. Making IPv4 records unreliable would not accelerate good accounting. It would increase defensive hoarding and raise the risk premium. Making IPv6 easy to obtain and document reduces excuses. Keeping transfer and public-record evidence clean lets the market price scarcity honestly. The registry should not hide the bill; it should make the underlying public evidence boring enough that the bill can be assigned to the right party.
Registry evidence is the incidence ledger behind the market
The public number-resource record is not a balance sheet, but it behaves like an incidence ledger behind many coexistence costs. It tells counterparties who is recognised for a resource, which contacts exist, whether reverse-DNS arrangements can be maintained, how routing-security evidence begins, and whether a transfer or organisational change has a public basis. In a dual-stack world, this evidence supports both IPv4 scarcity management and IPv6 deployment confidence.
ARIN's post-depletion facts matter here. Its free IPv4 pool was depleted in 2015. Meaningful IPv4 capacity in the region now commonly comes through waiting-list fragments, transfers, mergers, acquisitions, legacy holdings, leases and provider arrangements. ARIN's public materials also record later operating signals: continuing waiting-list distributions, transfer-market relevance, route-security updates, fee changes and governance activity. These signals show a registry environment where IPv4 remains active capital rather than a retired protocol footnote.
Waiting-list evidence is one incidence signal. A limited recovered-space distribution can help some applicants, but it cannot serve as elastic supply for a growing hosting, cloud, broadband or enterprise market. When a provider cannot rely on routine registry issuance, it turns to transfer, lease, NAT, public-IP pricing or IPv6 redesign. The cost moves from administrative allocation into commercial planning. The waiting list is useful. It is not a substitute for address abundance.
Transfer evidence is another signal. A block that can be transferred with predictable recognition, clean contacts, reverse-DNS continuity and routing-security alignment has higher economic utility. A block with old corporate history, stale contacts, uncertain authority or broken publication state carries remediation cost. The buyer, seller, broker, lender, hosting customer or cloud platform prices that cost. The registry's role is to reduce avoidable uncertainty around recognition and public state.
RDAP and Whois-style public records are evidence for counterparties. They help abuse desks, upstream providers, transfer buyers, lenders, journalists, compliance teams and customers form a first view. In dual-stack incidence terms, they lower the search cost of assigning responsibility. If a CGNAT pool produces complaints, the public record should identify the responsible network and contact route. If a hosting provider sells public IPv4 service, counterparties should not have to guess whether the address space is coherently recorded. If an enterprise brings its own space to a cloud, the cloud should be able to compare the customer's claim with public evidence.
Reverse DNS is a quieter but important incidence line. Mail systems, security tools, customer assurance processes and operational diagnostics may rely on reverse naming. During transfers, leases, cloud migrations and product segmentation, stale reverse DNS can create avoidable friction. A provider may spend support time explaining why old names remain. A customer may face reputation or compliance questions. A registry that supports clear reverse-DNS delegation and handover reduces the cost of public identity continuity.
Routing-security evidence also matters. Route-origin authorisation, registry-linked security services and routing-registry data help counterparties decide whether a scarce address resource can be accepted safely. In a dual-stack environment, a provider may be changing origins, moving workloads into cloud, importing customer space, splitting pools between IPv4 and IPv6 products, or retiring old paths. Coherent evidence lowers the cost of these movements. Incoherent evidence raises support, audit and settlement costs.
Contactability is the last mile of the incidence ledger. Abuse reports, lawful requests, operational notices and customer escalations need a door. A broken contact shifts cost to victims, upstreams, reputation systems and innocent users. A working contact narrows punishment and improves evidence flow. But the contact field should not become a general verdict on a holder's business model or customer behaviour. It should route notices. That narrowness protects both accountability and market confidence.
ARIN is most useful when it treats these evidence functions as infrastructure. It should preserve the ledger, not convert every cost of coexistence into a claim for broader authority. Accurate public records, clear service states, defined transfer recognition, reverse-DNS continuity, route-origin support, validated contacts and accessible IPv6 registration are enough to make a serious contribution. Architectural morality is not required.
The fair assignment of cost is not the same as forcing IPv6
Cost incidence analysis can be mistaken for a demand that someone force IPv6 faster. That is not the conclusion. The better conclusion is that the coexistence bill should become visible and better assigned. Networks should move to IPv6 when it reduces real cost, improves reachability, supports growth or meets customer need. They should not be pushed by making IPv4 evidence unreliable or by pretending that registry discretion can replace market accounting.
Forcing the wrong party can produce perverse results. If a registry makes IPv4 transfers more uncertain in the name of transition, holders may hoard addresses and customers may prefer incumbents with existing inventory. If providers hide public IPv4 costs to appear customer-friendly, customers may keep old dependencies because delay seems free. If vendors face no procurement pressure for operational IPv6 parity, they will continue selling partial support. If auditors keep asking only IPv4-shaped questions, security teams will preserve IPv4 controls even while networks deploy IPv6. If public bodies publish transition goals but buy IPv4-centric systems, suppliers will price the contradiction.
Fair assignment begins by pricing exceptions. A customer that needs static public IPv4 for a genuine compatibility reason should be able to buy it, but the charge should signal scarcity. A customer that keeps an old allowlist should see the cost of maintaining it. A vendor that claims IPv6 readiness should be tested against operational parity. A managed-service provider that supports customer-owned prefixes should charge for evidence assurance rather than burying it in support. A public buyer should make IPv6 acceptance real in procurement, not symbolic.
Fair assignment also means recognising when IPv4 remains economically justified. Some services still need public IPv4 because counterparties are not ready. Some public services must preserve broad reachability. Some enterprise systems cannot be changed quickly without disproportionate risk. Some static public IPv4 products create genuine customer value. Treating all IPv4 spending as moral failure would conceal the real transition path. The useful test is whether the spending is explicit, justified and attached to a plan, or hidden inside inertia.
IPv6 benefits from honest IPv4 pricing. When public IPv4 is visibly scarce, customers have reason to modernise. When CGNAT tickets are counted, providers can justify IPv6 work with support savings. When security teams measure duplicate monitoring burden, they can prioritise tools that reduce it. When procurement teams demand true parity, vendors have revenue reasons to improve. When registry evidence makes address scarcity clear, the market can see that compatibility has a price.
ARIN's role should be compatible with this discipline. It should provide IPv6 resources with low friction and useful guidance. It should maintain IPv4 records because the old layer remains commercially active. It should avoid implying that continued IPv4 use is itself suspicious. It should support transfer clarity because scarce resources should move to higher-valued uses rather than sit idle. It should keep contactability and routing-security evidence clean because coexistence needs trust. It should treat portability and continuity as safeguards, not threats.
The restraint matters because the cost of dual-stack already falls unevenly. A broad discretionary registry posture would add another uneven cost: fear of record-layer uncertainty. Small providers would be most exposed. They have less staff to manage registry ambiguity, less inventory to absorb mistakes, less bargaining power with vendors and fewer ways to pass costs to customers. A narrow, evidence-focused registry lowers fixed costs for the small operator and reduces incumbent advantage.
The fair assignment of cost therefore requires three boundaries. Operators should pay for the address resources, logging and support their products consume. Customers should pay for exceptional compatibility when they choose to preserve old dependencies. Vendors should pay, through lost bids or remediation demands, when they sell incomplete parity. The registry should pay attention to evidence quality and service predictability, not to becoming the planner of architecture. That is how dual-stack cost can guide behaviour without becoming coercion.
Watchpoints for the next 12 to 24 months
The next 12 to 24 months will not settle the final fate of IPv4 or IPv6. They will reveal where the coexistence bill is becoming too visible to hide. The most important watchpoints are not speeches about transition. They are invoices, support metrics, procurement clauses, cloud product changes, address-market behaviour and public-record quality.
The first watchpoint is public IPv4 pricing. Cloud, hosting, broadband and managed-service providers will continue deciding whether to include public IPv4, charge separately, reserve it for higher tiers or replace it with shared egress. The key signal is not whether prices rise in one product. It is whether pricing becomes specific enough to change customer behaviour. A line item that says public IPv4 has a cost is more useful than a bundle that hides scarcity.
The second watchpoint is CGNAT support burden. Providers should track tickets tied to strict NAT, inbound reachability, gaming, VPNs, cameras, geolocation, blocked logins, reputation spillover and public-IP add-ons. If these tickets rise with fixed-wireless growth, mobile broadband, small-business products or consumer devices, then CGNAT is not only conserving addresses. It is generating measurable operating cost. That cost should influence product design and IPv6 investment.
The third watchpoint is log and attribution discipline. Access networks and platforms should be judged by whether they can answer translation-related requests responsibly without over-identifying users or rejecting valid evidence. Requests lacking source ports or precise timestamps should be treated as weak. Requests with sufficient detail should move through controlled processes. The cost of getting this wrong is paid in privacy risk, false attribution, support time and reputation damage.
The fourth watchpoint is vendor parity. Procurement teams should stop accepting vague IPv6-readiness claims. They should require proof across management, logging, monitoring, APIs, support, documentation, high availability, backup, security policy and audit output. Vendors that cannot show parity should be priced accordingly. The industry should watch whether buyers reward parity or continue buying products that export transition cost to integrators.
The fifth watchpoint is enterprise allowlist retirement. The persistence of IPv4-only partner allowlists is one of the strongest anchors of dual-stack cost. Organisations should count how many customer, supplier, bank, government and SaaS integrations still depend on IPv4 egress identity. The count should become a remediation backlog with owner, cost and risk. If the backlog remains invisible, the cost will continue landing on networks and cloud providers.
The sixth watchpoint is public-sector procurement. Government and public-service buyers in the ARIN region can reduce dual-stack cost by making IPv6 acceptance real across citizen-facing portals, supplier interfaces, logging, monitoring and support. If they require IPv4 compatibility indefinitely while describing themselves as transition leaders, suppliers will price the contradiction and the public will pay.
The seventh watchpoint is address-transfer and leasing evidence. As IPv4 remains valuable, buyers and users will demand cleaner public records, contact roles, reverse-DNS continuity and route-origin evidence. Blocks with weak evidence will face discounts or delays. The market should distinguish legitimate scarcity pricing from uncertainty premiums created by poor records. ARIN can reduce the latter.
The eighth watchpoint is registry contactability. Abuse and operational contacts should be role-based, durable, validated and connected to real desks. Broken contacts shift cost outward and contaminate reputation. But validation should stop at contactability, not become a judgment on every complaint. The quality of this boundary will affect small providers, lessors, hosters and mobile networks.
The ninth watchpoint is portability. Networks investing in dual-stack, IPv6 deployment, address purchases, cloud import or customer-owned prefix support need confidence that their number-resource identity can survive provider changes, organisational changes and institutional stress. Portability is not disorder. It is a continuity safeguard. The more expensive coexistence becomes, the more valuable portability becomes as protection against being trapped by a single gate.
The tenth watchpoint is ARIN's own discipline. The registry will face pressure from every side: IPv6 advocates wanting stronger transition signals, IPv4 holders wanting certainty, entrants wanting access, security actors wanting better evidence, customers wanting lower cost and vendors wanting simple stories. ARIN's legitimacy will come from resisting theatrical answers. Make the record accurate. Make IPv6 easy. Make transfers predictable. Make reverse DNS and route-origin evidence coherent. Make contacts useful. Make status language narrow. Do not turn dual-stack frustration into a mandate to govern business models.
The incidence conclusion is simple enough to be uncomfortable. Dual-stack persists because the cost of ending it is not borne by the same actors in the same period. IPv4 scarcity makes that mismatch financially visible. The mature response is not to pretend the bill is temporary, nor to moralise every actor still using IPv4. It is to put the bill where the dependency sits, make exceptions explicit, reward true IPv6 parity, and keep the registry record trustworthy enough that markets can price reality. In the ARIN region, the next phase of transition will be less about proving that IPv6 is the future and more about deciding who still pays for IPv4 to remain the present.