RIPE NCC and the economics of dual-stack cost incidence

Summary

• Dual stack is not a neutral technical interval. It is a cost-incidence mechanism in which the expense of keeping IPv4 and IPv6 alive together lands across access networks, small operators, hosting providers, enterprise IT, public-service suppliers, support teams and customers.
• The cost is not limited to routers. It includes duplicated address planning, CPE and firewall support, software parity, help-desk scripts, logging, security monitoring, route-origin evidence, reverse DNS, abuse handling, procurement exceptions, cloud compatibility, BYOIP assurance, IPv4 lease or transfer checks and fallback capacity.
• The party most able to accelerate migration is often not the party paying the bill. A vendor with weak IPv6 parity can export cost to integrators. A public buyer with old suppliers can export cost to contractors. An enterprise with IPv4 allowlists can export cost to cloud and access providers. A customer with old CPE can export cost to the help desk.
• IPv6 adoption can lower long-run scarcity pressure, but the coexistence period still has a balance sheet. A network may deploy IPv6 while paying for scarce public IPv4, shared addressing, translation logs, reputation repair and exceptions for customers whose counterparties remain IPv4-shaped.
• CGNAT is a cost-management tool in this essay, not the centre of the story. It can stretch scarce IPv4 and avoid some public-address purchases, but it creates support, attribution, reputation and compliance costs that somebody else must finance.
• IPv4 leasing and transfers are also cost items, not the main market story here. They give operators a way to buy compatibility or avoid heavier shared-address complexity, while adding diligence, documentation, reputation and counterparty costs to the dual-stack budget.
• Low-ARPU markets face tight pass-through limits, but this is not mainly a low-income essay. The sharper point is that every market contains actors whose ability to impose costs differs from their willingness to pay: suppliers, platforms, public bodies, enterprise customers, device makers and end users.
• Growth can intensify cost incidence, but growth is only one setting. A mature access network, a public-service supplier, a university, a cloud platform, a regional hoster and a small enterprise managed-service firm can all run the same coexistence bill without being in a simple expansion story.
• RIPE NCC should not become a dual-stack cost arbitrator, equipment-policy authority, subsidy body, telecom regulator, price-control institution, forced-migration office or judge of which actor deserves relief from transition costs.
• RIPE NCC's legitimate role is narrower and more valuable: maintain clear IPv4 and IPv6 registration status, accurate holder evidence, stable route-security services, reverse-delegation continuity, transfer and holder records, contactability and predictable registry operations.
• The registry layer matters because cost uncertainty compounds operational uncertainty. When the public record is clear, operators can price equipment, support, IPv4 capacity, logging, routing and customer exceptions on their own terms. When registry evidence is ambiguous, every dual-stack decision carries an avoidable uncertainty premium.
• The policy test is not whether RIPE NCC can make dual stack cheap. It cannot. The test is whether it can keep the common ledger and service layer boring, bounded and reliable while the market decides who pays for duplicated operations.

The meeting where one network becomes two budgets

The dual-stack budget meeting rarely begins with doctrine. It begins with a spreadsheet and a service desk report. The network team explains that IPv6 is enabled in the backbone, supported across new access nodes and available for major content flows. The finance team asks why public IPv4 still appears in lease quotes, transfer diligence, cloud invoices and premium customer options. The security team brings a list of firewall controls that must be checked in two address families. The support lead brings tickets about old routers, blocked games, business VPNs, cloud allowlists, public-sector portals and customers who do not know what protocol their application uses.

The room is not resisting the future. It is discovering that the future and the present must be financed together. One network has become two operating budgets. Address plans must cover IPv4 conservation and IPv6 allocation. Customer equipment must be tested for both. Monitoring must distinguish an IPv6 reachability issue from an IPv4 translation problem. Logging must store the evidence needed for shared IPv4 and the evidence needed for direct IPv6 paths. Reverse DNS, abuse handling and route-origin authorisations have to remain coherent across resources that are scarce in one family and abundant in the other. Documentation must tell engineers, customers and auditors what is actually supported, not what the strategy slide promised.

This is the economics of dual-stack cost incidence. The relevant question is not whether IPv6 has a larger address space or whether IPv4 is finite. Those facts are settled. The question is where the coexistence bill settles while the Internet remains mixed. A public body may require citizen reachability over IPv4 because older access paths still exist. A device vendor may ship partial IPv6 support and leave the access provider to answer calls. A cloud platform may expose public IPv4 as a priced feature, while customers pay for the work of rewriting allowlists and monitoring rules. A small hosting provider may keep IPv4 in low-margin products because customers still treat it as normal. The cost falls where service promises are hardest to withdraw.

RIPE NCC sits near this problem, but not above it. It is the regional Internet number registry serving a wide region that includes Europe, the Middle East and parts of Central Asia. Its core relevance is the record layer around IPv4, IPv6 and autonomous system numbers, together with services such as the RIPE Database, RPKI, reverse DNS and related operational support. Those services do not decide who buys a firewall, who trains a help desk or who pays for public IPv4. They make the rights, status and routing evidence around number resources legible enough that operators can make those decisions without guessing at the underlying record.

That distinction is central. A registry can reduce uncertainty; it cannot fairly allocate every cost created by an incomplete protocol migration. If RIPE NCC tries to become the institution that decides who should bear the dual-stack bill, it would need to rank national circumstances, enterprise dependency, public-service expectations, vendor readiness, cloud design, access economics and customer tolerance. That would convert a registry into an industrial-policy forum. The more legitimate task is thinner: keep the common evidence layer stable while the market absorbs an expensive coexistence period.

Cost incidence is not the same as transition ideology

The broad IPv6 transition debate often asks why deployment has not moved faster. That is a useful question, but it can blur the accounting. Cost incidence asks something narrower: when IPv4 and IPv6 must be operated together, which actor actually pays for the overlap? This question avoids both moral triumphalism and nostalgia. It treats dual stack as a set of invoices, support duties and risk controls rather than as a symbolic position in a protocol argument.

The difference matters because actors can support IPv6 in public while pushing the cost of coexistence elsewhere. An enterprise may publish an IPv6 road map and still ask suppliers for stable IPv4 egress because partner allowlists remain old. A public buyer may include future-ready language in procurement and still require contractors to support citizen access over IPv4. A cloud provider may encourage IPv6 and still charge for public IPv4 because customers bring older architectures. A device vendor may claim support and still leave gaps in diagnostics, firmware updates or support scripts. A registry may promote IPv6 availability and still have no authority to make customers retire their old dependencies.

Incentives are not hypocrisy by themselves. They are the ordinary structure of a market in which each actor controls only part of the chain. The problem begins when the industry treats transition language as if it describes cost responsibility. Saying that IPv6 is the desired architecture does not answer who pays for duplicate logging. Saying that IPv4 is scarce does not answer who funds public-address exceptions. Saying that dual stack is temporary does not answer who maintains the temporary state for ten budget cycles.

The cost-incidence lens also prevents overcorrection. It does not require RIPE NCC to oppose IPv6, suppress IPv4 markets or reward delay. It asks the institution to recognise that coexistence is real and expensive. In a mixed network economy, a clean registry record lowers transaction costs for both protocol families. An accurate IPv6 allocation record helps operators deploy future capacity. An accurate IPv4 holder record helps operators lease, transfer, route and support scarce compatibility. RPKI and reverse DNS do not become less important because one address family is older. Contactability and holder evidence become more important when one family carries scarcity and the other carries migration ambition.

This is why dual stack should be priced as duplicated operations. A provider must maintain training for both families. A security team must monitor both. A help desk must identify failures in both. A cloud customer must write infrastructure code that can support both. A public-service supplier must document both. A hosting company must explain both to small customers. The total bill is not visible in a single fee. It is hidden in many departments and contracts.

RIPE NCC's legitimacy depends on resisting the temptation to turn this hidden bill into an argument for broader power. The existence of dual-stack complexity does not make a registry the proper supervisor of equipment refresh, retail pricing, procurement standards or public subsidies. It makes registry clarity more valuable precisely because the rest of the cost stack is too complex for the registry to govern.

Access providers carry the retail promise

Access providers are the most exposed cost bearers because they sell the simplest promise: the Internet works. Residential users, mobile customers, fixed-wireless households, small firms, schools, clinics, shops and remote workers do not buy a theory of protocol transition. They buy connectivity. If a bank, game, tax portal, supplier VPN, streaming service, security camera, payment terminal or public-service page fails, the first complaint often goes to the access provider even when the root cause sits elsewhere.

That retail promise turns dual stack into daily overhead. The provider must plan scarce IPv4 carefully while assigning IPv6 at scale. It must test customer-premises equipment, firmware, home routers, business gateways and managed Wi-Fi across both families. It must train support staff to distinguish IPv6 reachability from DNS failure, NAT exhaustion, geolocation error, remote-platform blocking, CPE misconfiguration or an old endpoint that only understands IPv4. It must keep documentation useful to customers who may not know the difference between an address family and a Wi-Fi password.

When IPv4 is scarce, access networks often conserve it through shared addressing and translation. This can be rational, but it moves cost into systems that customers do not see. The operator must maintain gateways, ports, logs, timestamps, retention rules, access controls, lawful-response procedures and evidence quality. A complaint naming only a shared IPv4 address may be weak without source port and precise time. A serious request requires mapping from public address and port to subscriber session. That mapping is expensive not because the database is glamorous, but because it must be complete, secure, auditable and available when needed.

Shared IPv4 also creates reputation incidence. If abusive traffic emerges from a shared public address, security services, banks, mail receivers or streaming platforms may penalise the address. Innocent customers behind the same address may then see blocked logins, extra verification, failed mail delivery or degraded trust. The provider must investigate, segment pools, respond to outside complaints, update reputation channels and explain the issue to customers. The actor causing the abuse may be one compromised device; the actor paying the repair bill is the access provider and, indirectly, the other customers sharing the public identity.

IPv6 lowers some pressure when real traffic moves to IPv6. Major content paths can reduce translation load. Mobile and broadband networks can deliver cleaner end-to-end reachability where devices and platforms cooperate. Yet the access provider cannot retire the old layer merely because a meaningful share of traffic is modern. The support burden is controlled by the stubborn exception: the household device, remote employer, game service, bank, government site or small business tool that still requires IPv4 behaviour.

This is why cost incidence often lands on operators that did not create the delay. An old device vendor can leave customers with poor IPv6 behaviour. A public portal can require IPv4 reachability. A remote employer can require an IPv4 VPN path. A content service can run uneven support. The access network takes the call. It is the visible counterparty even when the dependency sits upstream or downstream.

RIPE NCC cannot set the provider's translation ratio, customer-support script or static-address price. Its contribution is narrower. The public ranges used by the provider need accurate holder records, contact data, route-origin authorisations where used, reverse-delegation continuity and a clear status history. If those records are stale, every complaint and exception becomes harder. If those records are clear, the provider still pays the coexistence bill, but it does not pay an additional uncertainty premium at the registry layer.

Small operators face lower bargaining power

Small operators are not merely smaller versions of incumbents. Their cost incidence differs because they have less inventory, less staff redundancy, less supplier leverage and less room to hide mistakes. A large carrier can spread dual-stack costs across many product lines, negotiate vendor support, reserve IPv4 for premium customers and maintain specialist teams for routing, security, regulatory response and registry administration. A small access network or regional hoster may have the same categories of work but only a handful of people to carry them.

For the small operator, duplicated operations are often personal rather than departmental. The same engineer may manage IPv6 addressing, IPv4 conservation, firewall rules, RPKI checks, reverse DNS, abuse mail, customer escalations and procurement advice. The same finance lead may review IPv4 lease quotes, equipment upgrades and customer pricing. The same support staff may explain home-router behaviour in the morning and a business static-address issue in the afternoon. The cost is not only money. It is scarce attention.

This scarcity of attention changes the economics of mistakes. A stale reverse-DNS delegation can harm a hosting customer. A weak contact record can slow an abuse response. A misunderstood route-origin setting can create reachability friction. An IPv4 lease with unclear counterparty terms can expose the operator to sudden change. A vendor's partial IPv6 support can generate tickets the operator cannot easily escalate. Larger firms can absorb some of this as ordinary overhead. Small firms experience it as service risk.

Small operators also have weaker bargaining positions with vendors and platforms. They may be told that a router, firewall, customer gateway or billing system supports IPv6, only to discover that diagnostics, reporting, automation or support tooling is incomplete. They may lack the purchasing power to force a roadmap. They may have to work around defects, delay customer offers or keep more IPv4 compatibility than their architecture would otherwise require. The vendor's incomplete support becomes the operator's local cost.

Public procurement can intensify the problem. A municipal or education buyer may ask for IPv6 readiness while keeping old application suppliers, IPv4 allowlists and strict continuity requirements. The small operator must bid against larger firms with deeper IPv4 reserves and larger support benches. If it prices the true dual-stack cost, it may look expensive. If it underprices the cost, it inherits a long support burden. The buyer's mixed requirement becomes a margin squeeze.

Low customer willingness to pay can limit pass-through, but this is not only a low-income-market issue. A small operator in a wealthy area may still lack bargaining power. A regional hoster serving local firms may compete with large cloud providers. A managed-service firm may support many small enterprises that expect traditional IPv4 behaviour while asking for modern security. The imbalance lies in control: small operators are often close to customers but far from the upstream decisions that create coexistence costs.

The registry layer can help by being predictable. A small operator should not need a specialist in institutional culture to understand holder status, transfer evidence, route-security service, reverse delegation, or the documentation needed for a resource change. Clear records and clear procedures reduce the fixed administrative component of dual stack. They do not make IPv4 cheap or IPv6 easy. They keep a necessary public service from becoming another variable that favours large incumbents.

Hosting and cloud turn the bill into product design

Hosting and cloud providers experience dual stack as product segmentation. They decide whether public IPv4 is bundled, charged separately, reserved for higher tiers, leased externally, recovered aggressively or hidden behind shared front ends. They decide whether IPv6 parity exists across compute, load balancing, storage, databases, firewalls, private connectivity, logging, identity integrations, monitoring and support. Customers see a catalogue. The provider sees a cost-allocation model.

Public IPv4 is the clearest signal. Where it appears as a separate charge, the price tells customers that compatibility has a cost. That can be healthy. A labelled charge makes scarcity visible and encourages redesign. But it does not include the whole bill. A customer reducing public IPv4 dependence may need to change DNS, partner allowlists, firewall policy, monitoring rules, infrastructure code, audit evidence, incident-response playbooks and support scripts. The platform can expose the price of the address; the customer still pays for the labour of changing the service around it.

Smaller hosters face a different problem. Many customers still expect a virtual server, mail service, web host or managed application to include public IPv4 because that was the commercial norm for years. The hoster may want to make IPv6 the default and public IPv4 an exception. Yet customers may lose visitors, face mail reputation issues, fail partner checks or struggle with old corporate networks. If the hoster absorbs public IPv4 cost, margins shrink. If it charges separately, customers may churn. If it relies on leases, counterparty and reputation risks enter the product.

Cloud platforms can move faster because they control more of the stack. They can build portals, automation and documentation around IPv6. They can guide developers. They can price public IPv4. They can operate large-scale address management. Yet platform scale does not erase partial readiness. Some services may support IPv6 more fully than others. Some third-party marketplace tools may remain uneven. Some customer-owned address arrangements require careful evidence. A product family can be modern at the edge and still old in the control plane, billing path, security report or partner integration.

BYOIP illustrates the evidence cost. When a customer brings its own number resources into a cloud or hosting environment, the provider must verify public records, route-authorisation status, holder identity, reverse-DNS control, contactability and the operational authority to announce or delegate. That verification is not free. It is the price of allowing customer network identity to move into a platform. If the evidence is clean, portability becomes a competitive feature. If the evidence is unclear, support and risk teams bear the cost.

The same pattern applies to IPv6 adoption. A cloud customer may want to run IPv6-first, but if a supplier integration, security tool or public endpoint still expects IPv4, the cloud design remains dual. The platform may support the modern path and still sell the old path because customers need it. Product teams then decide which cost to show and which cost to bundle. Public IPv4 line items, managed NAT, load balancers, private connectivity and support plans become instruments for distributing the coexistence bill.

RIPE NCC's role is not to decide whether a platform should charge for public IPv4 or how a hoster should package service. Its role is to maintain the evidence environment that makes these products trustworthy: accurate holder records, clear resource status, reliable reverse DNS, RPKI services and understandable transfer or holder history. A product economy built around scarce compatibility cannot function well if the public record behind the scarce input is ambiguous.

Enterprise IT exports delay through allowlists and firewalls

Enterprise IT teams often pay dual-stack cost directly, but they also export it. They maintain application estates, supplier integrations, firewalls, VPNs, identity systems, monitoring tools, audit files and partner allowlists that were designed around IPv4. Moving those systems to IPv6 is not a single network change. It is a negotiation among security, application, procurement, risk, legal, support and business units. When that negotiation is delayed, suppliers are asked to preserve IPv4 compatibility.

Allowlists are the classic example. Banks, logistics companies, software vendors, public bodies and industrial firms often identify counterparties by stable IPv4 egress addresses. That practice becomes business memory. A change requires tickets, approvals, tests, audit updates and sometimes contract amendments. Even where IPv6 is technically possible, the institutional work may be slow. The enterprise may therefore pay for static IPv4 from a cloud provider, ask an access network for a clean public address, maintain a dedicated NAT gateway or require a supplier to keep old reachability.

Firewalls create a second cost channel. An enterprise may have mature IPv4 rules, naming conventions, change boards and evidence routines. IPv6 forces review: address grouping, segmentation, neighbour discovery, extension headers, dual-path monitoring, logging, asset attribution and incident response. Security teams may prefer to move slowly because a blind spot is harder to defend than an old control. That caution is rational, but it leaves suppliers carrying IPv4 support during the review.

Monitoring and compliance add another layer. A vulnerability scanner may cover IPv6 but produce reports that the team has not learned to interpret. A SIEM may store IPv6 addresses but lack mature correlation rules. An audit template may ask for IP ranges in a format shaped by IPv4 history. A fraud system may weight IPv4 reputation more heavily than IPv6. Each gap turns a protocol migration into an evidence project. Until the evidence project is complete, the enterprise preserves familiar IPv4 paths.

Enterprises also export cost through procurement. A request may require "IPv6 support" without defining operational parity. A supplier can satisfy the phrase while leaving gaps in support tooling, logging, management APIs or third-party integrations. Later, the managed-service provider, hoster or access network must operate the customer's real environment, not the procurement phrase. The cost of ambiguous procurement lands in exception handling.

Public-service suppliers face a stricter version because failure can affect citizens. A tax portal, health appointment system, court filing service, education platform or emergency communications supplier cannot assume every user and every agency path is modern. It may need to run IPv4 and IPv6 because exclusion is unacceptable. That obligation is legitimate, but it must be priced honestly. Public procurement that demands both future readiness and old compatibility is buying two service layers.

The registry does not solve enterprise inertia. It does not rewrite allowlists, approve firewall rules or modernise audit language. It can, however, prevent the number-resource evidence from adding confusion. When an enterprise asks a supplier to use public addresses, route customer-owned space or support IPv6, the records should make holder status, route-origin evidence, reverse DNS and contactability clear. That clarity helps procurement and security teams ask better questions. It does not let RIPE NCC become the judge of enterprise transition.

Vendors sell partial support; users buy the missing work

Device and software vendors shape dual-stack cost more than their marketing suggests. A router, firewall, CPE, billing platform, monitoring tool, SaaS product or industrial device can claim IPv6 support while leaving weak spots in diagnostics, automation, firmware updates, documentation, logging, support escalation, reporting or integration. The missing parity does not remain with the vendor. It moves to operators, managed-service providers, enterprise IT teams and customers.

Customer-premises equipment is one visible path. A new router may handle IPv6 well. An older device may need firmware that the customer never installs. A low-cost gateway may support IPv6 on paper but expose poor controls. A business firewall may pass IPv6 traffic but lack the reporting clarity that the customer expects for IPv4. A consumer support desk then receives complaints about video calls, remote cameras, VPNs, games or public-service pages. The cost of vendor unevenness lands on the party with the customer relationship.

Software behaves similarly. A product may listen on IPv6 but still use IPv4 assumptions in licence checks, update servers, backup targets, webhooks, API validation, access lists or audit exports. A SaaS platform may support IPv6 for user access but not every integration. A security product may inspect IPv6 but report it less clearly. A monitoring tool may store addresses but make searching and grouping cumbersome. The buyer discovers that "supported" is not the same as "operationally equal."

Integrators buy the missing work. They write exceptions, preserve IPv4 egress, maintain translation, tune firewalls, educate users, document limitations and answer tickets. They may not be able to recover the full cost because the customer sees the vendor as compliant. The gap between feature support and operating parity becomes an unpriced service burden.

End users are cost bearers too, though usually in indirect ways. A household behind shared IPv4 may lose inbound connectivity or face stricter remote-access limits. A small business may pay for a static public address because a payment device or partner portal requires it. A developer may spend time diagnosing a webhook that fails only on one path. A school or clinic may accept a managed service with old compatibility because the alternative would require retraining and supplier change. These are not protocol choices in the abstract. They are small payments of time, money and inconvenience.

The unfairness is structural: the actor best placed to remove a dependency may not feel the full cost of leaving it in place. A vendor that delays operational parity can still sell the product. A customer that maintains old allowlists can still demand service. A public buyer that writes broad compatibility into a contract can still call it risk management. The support chain absorbs the cost because it is closer to the failure.

RIPE NCC cannot police vendor truthfulness or consumer device quality. It should not become an equipment-certification body. Its proper role is to make sure that number-resource services are not another partial-support problem. IPv4 and IPv6 registration data, route-security services, reverse DNS, contact records and transfer evidence should work clearly enough that operators do not need workaround culture at the registry layer too.

Security, logging and abuse handling are duplicated evidence systems

The most expensive part of dual stack is often not packet forwarding. It is evidence. Security and abuse teams need to know who used an address, which path was taken, which control applied, which alert fired, which customer was affected and which external complaint is reliable. Running two address families means running two evidence systems, with different failure modes and different histories.

For IPv4, scarcity creates sharing and translation. Evidence must identify a subscriber, device, workload or customer behind a public address and source port at a particular time. This requires accurate clocks, gateway records, retention rules, privacy controls, staff procedures and the ability to reject weak complaints that lack enough detail. The cost is continuous. It exists because shared public identity is ambiguous without supporting logs.

For IPv6, the evidence problem is different. Addresses may be abundant and more directly assigned, but security tools must parse, store, group and correlate them well. Temporary addresses, delegated prefixes, customer routers, cloud subnets and privacy behaviours require interpretation. A firewall policy that was obvious in IPv4 may need new grouping logic. A monitoring alert may need new baselines. A help-desk note may need to explain why a device has several addresses. Abundance does not remove evidence work; it changes the shape of the work.

Abuse handling sits between the two. External reporters may send IPv4 complaints that require port and timestamp enrichment. They may send IPv6 complaints that assume an address identifies a stable endpoint when it may identify a prefix delegation or temporary state. Mail reputation, geolocation, fraud controls and platform risk signals may be much more mature for IPv4. A provider must answer the complaint in the language the reporter uses, while maintaining internal evidence that respects privacy and operational reality.

RPKI and route-origin authorisations add another evidence layer. They help route origin claims become more machine-checkable, but they do not maintain themselves. Operators must create, review, update and retire authorisations when resources move, when customer space is imported, when a route changes, or when a service migrates between providers. In a dual-stack environment, the routing-security file must remain coherent across both scarce legacy ranges and newer IPv6 deployments.

Reverse DNS is similarly mundane and consequential. It affects mail, enterprise trust, diagnostics, incident handling and customer expectations. IPv4 reverse delegation may be tied to scarce public-address products, lease arrangements or transfers. IPv6 reverse delegation may expose new naming and operational habits. Broken reverse DNS can make a technical deployment look unprofessional. Maintaining it across both families is part of the duplicated service burden.

Security monitoring turns all of this into staff time. Analysts need to search both address forms, understand translation, interpret route-origin signals, verify holder records, decide whether an abuse contact is current and distinguish a registry fact from a customer support claim. If the registry evidence is weak, the security team wastes time before it even reaches the local network evidence.

This is where RIPE NCC's narrow role has high leverage. It can make public records, RPKI services, reverse DNS and contactability reliable. It can maintain clear holder and transfer evidence. It can avoid adding ambiguity when resources are disputed or moved. It cannot make every operator's logs good, but it can prevent the common evidence layer from becoming another source of doubt.

Public procurement turns compatibility into a contract

Public procurement is one of the strongest mechanisms by which dual-stack costs become durable. Governments and public-service institutions have good reasons to demand continuity. A citizen should not be excluded from a tax portal, court service, health appointment system, school platform or emergency notice because a protocol path is not available. That public obligation makes IPv4 compatibility hard to withdraw, even when IPv6 goals are stated clearly.

The procurement file often tries to have both outcomes. It may require IPv6 readiness, modern security, cloud compatibility and future-proof design. It may also require support for existing agencies, old supplier systems, citizens on older networks, partner portals and audit procedures that still assume IPv4. The supplier is asked to provide transition and continuity at once. That is not wrong, but it is expensive.

The cost can hide in exceptions. A public system may be mostly modern, but a legacy department keeps an IPv4 allowlist. A contractor may deploy IPv6, but a downstream supplier lacks support. A citizen-facing service may need IPv4 because some access networks remain mixed. A security audit may require evidence shaped by old controls. Each exception appears small. Together they preserve a second operating layer.

Public buyers can also export cost through unclear acceptance tests. A tender may ask whether IPv6 is supported but test only website reachability. It may ask for security evidence but not specify parity across both families. It may require public IPv4 without admitting that scarce addresses have market value. It may penalise suppliers for charging explicit compatibility costs while rewarding vague bundled offers. The result is a market where suppliers hide the dual-stack bill to win contracts and later recover it through change requests, support limitations or margin pressure.

Public-service suppliers then carry a difficult risk. If they underinvest in IPv4 compatibility, users may be excluded. If they underinvest in IPv6, the service becomes stale and fails future goals. If they price both honestly, they may look expensive. The public buyer's social obligation is real, but the incidence still has to be recognised. A continuity requirement is a purchase of duplicated operations.

This matters in the RIPE NCC region because the service area includes many legal systems, procurement cultures, income levels and administrative traditions. A single procurement slogan will not describe them. Some public buyers have sophisticated digital teams. Others rely on vendors to interpret requirements. Some can mandate IPv6 strongly. Others must preserve older supplier chains. The cost of coexistence will therefore vary widely even when the protocol words look similar.

RIPE NCC should not become a public-procurement referee. It should not decide whether a ministry, municipality, school network or health supplier bought the right equipment. Its contribution is the public-number evidence those contracts rely on: recognised holder status, route-security services, reverse-delegation continuity, contactability and reliable records for transfers or changed operational control. Procurement can then price continuity honestly without asking the registry to arbitrate the contract.

Transfers, leases and shared addressing are cost choices

When an operator needs IPv4 compatibility, it usually has three broad choices: obtain more public IPv4, share existing IPv4 more heavily, or push customers harder toward IPv6 and exceptions. In practice these choices are mixed. A provider may lease addresses for business products, buy a block for strategic reserve, use shared addressing for residential users, support IPv6 widely and still maintain special public-address pools for customers who need them.

IPv4 leases and transfers are cost items in the dual-stack budget. They buy time, compatibility and reduced operational friction. A clean public block may be cheaper than dense translation once support, logging and reputation costs are counted. A lease may let a hoster preserve product expectations while a customer base modernises. A transfer may provide long-term certainty for enterprise services. These decisions are not simply speculation in scarce numbers. They are purchases of operational simplicity.

Yet leases and transfers carry their own costs. Diligence must check holder authority, reputation history, route-origin implications, reverse-DNS control, contract terms, abuse responsibility, termination risk, payment conditions and compatibility with the operator's architecture. A cheap block with poor reputation may be expensive after mail trouble or platform blocks. A lease with weak control terms may become risky for a public-service customer. A transfer with unclear documentation can delay launch. Scarce compatibility is never just the address; it is the evidence around the address.

Shared addressing is the other cost choice. It avoids some public-address acquisition, but it creates gateway capacity, attribution logs, support friction, port limits, customer education, lawful-response procedures and reputation pooling. In some retail markets this is the only viable method. In some business contexts it is unacceptable. The operator is not choosing between cost and no cost. It is choosing which cost category is more manageable.

IPv6-first service can reduce both categories when customers and counterparties cooperate. A new product designed for IPv6 from the start may need fewer public IPv4 exceptions. A content-heavy access network may offload large traffic volumes. A private enterprise application may be modernised. But there remains an outside world of banks, suppliers, older devices, public portals, fraud tools and partner networks. The operator cannot capture all the savings until the surrounding market changes too.

The cost-incidence problem is therefore partly contractual. If customers demand public IPv4, they should see the cost. If vendors create IPv6 gaps, procurement should price remediation. If public buyers require universal compatibility, tenders should pay for two layers. If access providers choose shared IPv4, customers should understand limitations. Clear pricing makes the cost visible to the actors sustaining it.

RIPE NCC should not set those prices. It should not decide whether leasing is virtuous, whether a transfer price is too high, whether a static IPv4 add-on is fair or whether CGNAT is acceptable in a retail plan. Its role is to keep the registration and service layer clear enough that each cost choice can be evaluated on its real operational merits.

Pass-through does not follow responsibility

Cost incidence would be easier if every actor could pass the bill to the party that created the dependency. That is rarely how network markets work. The actor with the service promise usually pays first. The actor with the old dependency may pay later, indirectly or not at all. This gap between responsibility and pass-through explains why dual stack persists even when most technical staff would prefer a cleaner end state.

An access provider cannot send a household a detailed invoice for the fact that a remote game, bank, camera platform or employer VPN still expects IPv4 behaviour. It may charge for static public IPv4, but most compatibility cost is hidden inside retail service. A hosting firm cannot always tell a small customer that the real price increase comes from address scarcity, mail reputation and partner reachability. It may expose a public IPv4 fee, but the customer compares the headline package against competitors. A managed-service provider cannot easily charge an enterprise every time an old allowlist prevents IPv6-first operation. It must preserve service while arguing for future remediation.

The same pass-through failure appears inside enterprises. A security team may keep IPv4 controls because audit evidence is familiar. An application team may delay remediation because the application still earns revenue. A procurement team may accept vague vendor claims because the bid is cheaper. The network team then funds gateways, exceptions and monitoring. The department causing the delay is not always the department that loses budget. In that setting, technical rationality alone will not retire old dependencies.

Public services make pass-through even harder. A ministry, school network, court platform or health supplier may know that dual operation costs more, but charging users for compatibility is usually impossible. Citizens experience failure, not protocol design. Contractors therefore price continuity into bids or absorb it when tenders understate the requirement. The public buyer may be right to demand reachability, yet the economic effect is still a transfer of cost to suppliers, taxpayers or other budget lines.

Cloud pricing makes the hidden bill more visible, but visibility is not the same as responsibility. A customer can see a public IPv4 charge and still keep paying it because changing the surrounding architecture is harder than paying the fee. The visible line item may even make the platform look like the source of the cost, when the deeper cause is a set of customer, partner and vendor dependencies that the platform did not create. Clear pricing helps, but it does not solve collective delay.

Small operators face the weakest pass-through power. If they raise prices to recover dual-stack support, customers may leave. If they bundle the cost, margins fall. If they rely on shared addressing, support calls rise. If they lease more IPv4, cash is tied to a scarce input. If they push IPv6 too strongly, customers with older equipment or counterparties blame them for broken service. The operator is not choosing a cost-free path. It is choosing which stakeholder will notice the cost first.

This is why the word "neutral" misleads. Dual stack may be neutral in the sense that both protocol families are offered. It is not neutral in the sense of cost distribution. It favours actors with inventory, scale, bargaining power, patient customers and better procurement language. It burdens actors near the support edge, where service failure is visible and bargaining power is weak. The same technical architecture can therefore have different economic effects depending on who can pass costs onward.

RIPE NCC cannot repair that bargaining map. It can only avoid worsening it. If the registry layer is slow, ambiguous or culturally hard to navigate, the actors with less pass-through power pay again through delay and uncertainty. If the registry layer is clear, those actors still face the market's unfairness, but they are not forced to finance institutional fog on top of duplicated operations.

The registry should reduce uncertainty, not allocate pain

The temptation in any costly transition is to look for a central institution to allocate pain. Dual stack makes that temptation stronger because the bill is dispersed. Access providers pay support and translation costs. Hosters pay address and reputation costs. Enterprises pay firewall and integration costs. Public-service suppliers pay continuity costs. Customers pay through fees, restrictions or inconvenience. Vendors and procurement teams can create costs that they do not fully bear. A central arbiter sounds attractive.

RIPE NCC should resist that role. It is not a subsidy institution. It is not an equipment standards authority. It is not a telecom regulator. It is not a price-control body. It is not a migration police force. It is not a court for deciding whether an enterprise, cloud platform, access provider, vendor or public buyer should pay more of the coexistence bill. If it accepted those functions, it would exceed the narrow legitimacy that makes a registry useful.

The registry's proper contribution is uncertainty reduction. It should make the status of IPv4 and IPv6 resources clear. It should maintain accurate holder evidence. It should support RPKI and route-origin authorisations predictably. It should keep reverse DNS stable. It should ensure contact data and abuse-handling records are usable within the limits of registry service. It should make transfer and holder changes intelligible. It should publish service states and procedural requirements in a way operators can plan around.

Uncertainty reduction has real economic value. A hosting firm deciding whether to lease IPv4 can price counterparty risk more accurately when holder records are clear. A cloud provider accepting customer-owned resources can lower verification cost when route-origin evidence and records align. An access network responding to abuse complaints can save time when public records are accurate. An enterprise evaluating a supplier can ask sharper questions when the registry layer is legible. A small operator can avoid hiring unnecessary intermediaries when procedures are understandable.

This is not a minor administrative virtue. In a dual-stack economy, uncertainty multiplies. The operator already faces uncertain customer demand, uncertain vendor parity, uncertain public procurement, uncertain IPv4 reputation, uncertain platform support and uncertain timing for retirements. The registry should not add another uncertainty. It should be the layer whose reliability lets others carry their own risks.

The boundary also protects RIPE NCC. If it confines itself to registry certainty, it can be judged on service quality: accuracy, continuity, transparency, contactability, predictable procedures, security of changes and resilience of publication. If it tries to allocate transition costs, it will be drawn into political economy disputes it cannot resolve legitimately. Every decision would favour one cost bearer over another. Every intervention would invite a claim that the registry has become a market governor.

The better institutional posture is modest and firm. RIPE NCC should support both protocol families in the registry record because both are operationally real. It should encourage clarity without turning encouragement into compulsion. It should keep IPv6 paths easy and IPv4 records reliable. It should not use the desirability of future IPv6 adoption to justify present ambiguity over scarce IPv4 records. The ledger must serve the mixed network as it exists, not only the network as advocates wish it to become.

The watchpoints are where the bill is hidden

Dual-stack cost incidence becomes visible when the hidden bill is itemised. The first watchpoint is duplicated address planning. Operators must manage IPv4 scarcity and IPv6 abundance at the same time. One family requires conservation, acquisition, lease control and exception pricing. The other requires prefix planning, customer delegation, firewall design and operational education. Treating this as one address plan understates the labour.

The second watchpoint is customer equipment. CPE, routers, firewalls, industrial gateways, cameras, payment devices, printers, medical systems and old appliances do not modernise evenly. Support claims by vendors are not enough. The relevant question is whether ordinary users and support teams can operate the device without creating recurring tickets. A low-cost device that exports cost to the help desk is not cheap in the full budget.

The third watchpoint is software parity. IPv6 support should mean more than packet acceptance. It should include logs, dashboards, APIs, support tickets, documentation, audits, high availability, updates and third-party integrations. Every missing piece preserves IPv4 and shifts work to integrators.

The fourth watchpoint is evidence. Logging, security monitoring, abuse response, lawful process, route-origin authorisations and reverse DNS must all function in a mixed world. A provider that saves money on addresses through shared IPv4 may spend more on evidence. A provider that deploys IPv6 may need new evidence conventions. Both costs are real.

The fifth watchpoint is procurement language. Public and enterprise buyers often buy continuity and transition at the same time without admitting the double purchase. Contracts should distinguish readiness from parity and ordinary support from exception support. Otherwise suppliers underprice the coexistence bill and later recover it through friction.

The sixth watchpoint is cloud and BYOIP compatibility. Platforms can make public IPv4 scarcity visible, but customers still carry migration labour. Customer-owned resources require evidence checks. Cloud features may not reach full parity at once. The price of the address is only one part of the cost.

The seventh watchpoint is IPv4 market dependence. Leasing and transfers can lower operational complexity, but they add diligence and reputation costs. Shared addressing can avoid lease cost, but it adds logs and support. There is no free path through coexistence.

The final watchpoint is registry ambition. The more expensive dual stack becomes, the easier it is for institutions to claim wider authority in the name of coordination. That should be resisted. The cost of coexistence is a reason to demand a clearer registry, not a larger gatekeeper. RIPE NCC's value is highest when it keeps the common record reliable and lowest when it is tempted to arbitrate the market above it.

A limited mandate is not a weak mandate

The right conclusion is not that RIPE NCC is irrelevant to dual stack. It is that its relevance is specific. The institution cannot make a vendor finish IPv6 parity, a public buyer retire old systems, an enterprise rewrite allowlists, a cloud customer redesign applications or an access provider abandon shared IPv4. It can make the number-resource layer less ambiguous while those actors face their own costs.

That limited mandate is stronger than it sounds. A clear registry record reduces transaction cost. Stable RPKI services reduce routing uncertainty. Reliable reverse DNS supports mail, diagnostics and trust. Accurate contact data helps abuse handling. Predictable transfer and holder evidence lowers market friction. Good documentation reduces small-operator burden. Service continuity protects running networks from administrative turbulence. These are not glamorous functions, but they are exactly the functions that matter when the rest of the industry is paying for duplicated operations.

The cost-incidence lens also gives RIPE NCC a disciplined way to speak about transition. It can acknowledge IPv6's long-run importance without pretending that IPv4 compatibility has vanished. It can support IPv6 deployment without treating IPv4 holders as a problem to be managed away. It can maintain IPv4 records without endorsing every market claim around scarce addresses. It can improve registry services without becoming a regulator. It can reduce uncertainty without deciding who deserves compensation.

The dual-stack period will not be experienced as one clean technical migration. It will be experienced as thousands of cost decisions: a public IPv4 add-on, a firewall review, a support call, a router replacement, a cloud line item, a lease contract, a route-origin update, a reverse-DNS correction, a procurement exception, a logging system and a customer complaint. Each decision has a payer. Often the payer is not the actor that created the delay.

That is why the economics matter. The industry does not need another slogan about transition. It needs a clearer view of who pays for the overlap and which institutions can reduce the avoidable part of the bill. RIPE NCC's contribution is not to make dual stack painless. It is to ensure that the registry ledger and service layer do not make a costly coexistence period more uncertain than it has to be.

In that sense, a limited mandate is not weakness. It is the condition of trust. The registry should record, publish, secure and clarify. Operators, customers, vendors, platforms and public buyers should bear the costs of the choices they control. Dual stack is a cost-allocation table. RIPE NCC's job is not to fill in every line of that table. Its job is to keep the common numbers legible enough that the table can be read.