Summary

  • LACNIC IPv6-transition political economy separates technical carriage from a commercially exercisable exit from revenue-critical IPv4 dependencies.
  • Counterparty compatibility, procurement, allowlists, installed systems, platform incentives and asset optionality keep the promised endpoint open long after adoption metrics rise.
  • A narrow ledger should preserve operator choice during coexistence; Number Resource Society provides a future-facing holder-rights architecture without turning transition rhetoric into control.

A network manager in Medellin can complete an IPv6 programme and still be unable to close the IPv4 file. The backbone accepts the new prefixes. The access equipment has been refreshed. The cloud front end has a modern address plan. The security team can show that packets move across both families. Then a payments processor asks whether the old IPv4 source range will remain stable for fraud controls. A public buyer says its tender requires IPv6 readiness, but its installed monitoring estate still records IPv4 evidence. A logistics customer has allowlists maintained by another supplier. A hotel group depends on booking, banking and support systems whose change windows are controlled elsewhere. The technical bridge has been built, yet the revenue still depends on the older identifier.

That is the useful unit for LACNIC and IPv6 transition political economy. The question is not whether IPv6 works. It does. Nor is it whether operators in Latin America and the Caribbean can deploy it. Many can. The economic question is narrower: how much time remains before the final revenue-critical IPv4 dependency can be retired without losing contracts, customers, security recognition, recoverability, supplier acceptance or asset value? The endpoint is not a percentage in an adoption chart. It is the point at which an operator can remove the last commercially necessary IPv4 obligation and leave no material contract, application, procurement file, route of recovery or balance-sheet option exposed.

Lu Heng's attack on the IPv6 escape-from-scarcity narrative is useful only if it is translated into this accounting discipline. His related note on who IPv6 actually serves identifies the incentive alignment among registry process, large vendors and the language of inevitability. The point should not become a slogan. It should become a test: who benefits from extending the interval between IPv6 capability and IPv4 exit, and who pays while that interval remains open?

In LACNIC's region the answer is uneven. Urban enterprise customers, Caribbean tourism systems, public agencies, exporters, regional clouds, small access providers, hosting firms and banks do not sit on the same migration clock. Some can move quickly. Others depend on customers and vendors beyond their control. The political economy of transition sits in that mismatch. IPv6 availability creates a new reachability path. It does not automatically cancel the commercial value of IPv4 identity.

The distinction is important because a polemical transition debate can obscure the hard managerial problem. The useful question is not whether IPv6 is good or bad in the abstract. It is whether the operator can remove the remaining IPv4 identity from a revenue process without shifting unpriced risk to a customer, shareholder, lender or public-service user. If the answer is no, the transition is unfinished in the only sense that matters to the firm.

The economic clock starts when the last dependency can be retired

The common transition story treats the network as the decision-maker. If the network can carry IPv6, the story says, the old system should fade. The operator's accounts do not work that way. A network is wrapped in contracts, procurement rules, support obligations, security conventions, customer habits, vendor roadmaps, lender assumptions and asset files. Each can preserve an IPv4 dependency after IPv6 carriage is technically available.

The real clock therefore starts with the last dependency, not the average packet. A high proportion of traffic may move over IPv6 while a small set of profitable services still require stable IPv4. The dependency may be a payment system, an enterprise allowlist, a remote-support tool, a government portal, an email reputation chain, a supplier VPN, an inbound customer endpoint, a disaster-recovery procedure or a route-recognition convention. Its traffic share may be small. Its economic share may be large.

The last dependency also has a different owner from the first deployment milestone. Engineering can create reachability. Sales, legal, finance, procurement, compliance and customers decide whether the old reachability can be removed. The sales team worries about churn and renewal language. Legal worries about service descriptions and accepted performance. Compliance worries about evidence and attribution. Finance worries about whether a resource still protects future cash flow. Customers worry about whether an invisible change will break a visible service. A transition plan that stops at network readiness has not reached the actors with the veto.

The distinction matters for management. "IPv6-ready" means that a path exists. "IPv4-retired" means that the old identity can be removed without an unacceptable commercial loss. The first is an engineering achievement. The second is a commercial event. A treasurer, risk owner or customer director will not treat the first as proof of the second unless the contracts and counterparties follow.

Earlier BTW analysis of LACNIC interconnection dependency treated route acceptance and record reliability as bargaining infrastructure. Transition has the same structure. The customer does not buy a protocol preference. It buys continuity across other parties' expectations. If those parties still recognise IPv4 identity as the dependable form of reachability, the provider must preserve it even while expanding IPv6.

This is why the word "transition" can mislead. It implies a bridge whose far end is known and whose removal is scheduled. In many real networks the bridge has become an operating regime. Lu Heng's permanent dual-stack tax formulation is intentionally severe. The quieter institutional point is that a transition without an exercisable exit is not merely an interval. It is a continuing allocation of cost and power.

The exit clock should therefore be recorded as a register of obligations. Which contracts require IPv4? Which counterparties recognise only a known source range? Which support tools or vendor systems fail silently when the old identity disappears? Which customers pay enough to justify preservation? Which dependencies are temporary, and which are open-ended because the counterparty has no incentive to change? The answers create a map of the remaining political economy.

Adoption curves do not retire revenue obligations

Adoption curves are useful for describing capability. They are weak evidence for retirement. A country, carrier or platform can report strong IPv6 use while important customers still require IPv4 for business continuity. The curve says the new path works somewhere. It does not say the old path can be removed everywhere that revenue depends on it.

The problem is not ignorance. Network engineers understand fallbacks, split behaviour and customer exceptions. The issue is that public language often compresses those distinctions into a single sign of progress. Once progress is expressed as adoption, the residual IPv4 obligation becomes an embarrassment rather than an asset-management question. Operators then face pressure to speak as if the endpoint is close even when their contracts say otherwise.

Mobile networks show the tension clearly without settling it. IPv6 can reduce pressure on scarce public IPv4 where applications and content support it well. Shared IPv4 can keep ordinary consumer traffic working. Yet a minority of applications, business customers and support cases can still dominate the commercial risk because failure is concentrated where recognition matters. A small number of exceptions can keep an entire compatibility system alive if those exceptions protect high-value accounts or regulated services.

LACNIC's environment makes that compression expensive. A Brazilian software supplier may be modern in its own estate but serve a public agency whose outsourced security environment is slower. A Caribbean hotel-connectivity provider may support IPv6 while depending on foreign booking systems, payment processors and support desks. A regional bank may modernise customer-facing systems but keep conservative partner controls. A small host may offer IPv6-only experiments yet still find that paying customers expect a public IPv4 endpoint.

The last obligation survives because no single actor controls the whole chain. The access provider cannot force a bank to rewrite fraud rules. The local integrator cannot force a foreign platform to accept a new identity convention. The cloud customer cannot make every enterprise buyer remove IPv4 allowlists. The procurement officer cannot know every hidden application dependency and therefore demands compatibility as insurance. The result is not a simple failure to modernise. It is a coordination problem with liability attached.

This is also why institutional transition language should be treated as a claim by an interested party, not as controlling evidence. The agency-problem analysis is relevant because the parties that gain prestige, revenue or authority from a continuing migration are not always the parties that carry the balance-sheet risk of incomplete exit. A registry process, vendor campaign or standards forum can encourage progress without paying the customer's churn, SLA loss or asset impairment.

The operator's test is plainer. Which customers would leave if IPv4 disappeared? Which counterparties would reject the service? Which applications would fail audit or support? Which recovery plan would no longer work? Which address assets would still produce option value if retained? Until those questions have acceptable answers, an adoption curve is evidence of coexistence, not completion.

This is why transition politics should be separated from deployment celebration. A country-level or network-level adoption signal can be true and still incomplete. It may show that ordinary user traffic is moving in a better direction. It may also hide the fact that the last ten per cent of contractual dependence carries most of the economic consequence. The clock that matters is not average usage. It is the time until the last commercially binding exception can be removed.

Procurement buys continuity while speaking the language of modernisation

Procurement is one of the most durable sources of incomplete exit. Buyers rarely say they want to preserve IPv4 scarcity. They say the service must work with existing firewalls, audit systems, fraud tools, vendor support, branch equipment, public-service processes and disaster-recovery plans. That language is prudent. It also writes IPv4 into the commercial baseline.

An enterprise procurement committee is rewarded for avoiding embarrassment. It is punished for interruption, failed audit, supplier ambiguity and customer complaints. If an IPv6-only supplier requires multiple teams to change allowlists, rewrite incident runbooks and retrain support staff, the modern offer becomes risky. If another supplier offers IPv6 while keeping stable IPv4 identity, the second supplier looks safer even if it is less pure.

Public procurement sharpens the effect. Ministries, municipalities, universities, hospitals, ports and public banks often write tenders that combine aspirational modernisation with conservative continuity. A file can require IPv6 support and still insist on compatibility with existing IPv4-centred systems. A bidder that offers only IPv6 may be progressive in engineering terms and disqualified in commercial terms.

The point is not that procurement officers are irrational. They manage incomplete contracts. They do not know which legacy supplier portal, monitoring system, remote camera, payment connection or audit tool will fail. They therefore push the uncertainty down to the supplier. The supplier retains IPv4 because the buyer pays for avoided uncertainty more readily than for protocol purity.

Procurement also favours proofs that are easy to recognise. Stable IPv4 source identity is a simple object to place in a security list, supplier file or audit pack. IPv6 can be equally capable in engineering terms, but the institutional evidence around it may be less familiar to the buyer's outsourced auditors, support vendors and legacy documentation. The buyer's conservatism is often less about protocol preference than about the cost of changing an evidence routine across several organisations that do not report to the same budget.

This differs from the growth-financing problem in neighbouring work on LACNIC emerging-market pressure. Here the issue is not whether signed demand can be matched with deployable public identity quickly enough. It is whether existing and future buyers will let the provider withdraw the old identity at all. Procurement does not merely delay revenue. It prevents retirement by making compatibility part of dependable service.

The memory effect is powerful. Once a provider has supplied stable IPv4 identity for a contract, renewal negotiations begin from that state. The buyer asks why a risk should be introduced now when the previous arrangement worked. The supplier must show a saving or necessity large enough to overcome the buyer's preference for continuity. IPv6 offers a technical case. It often does not offer a commercial reward large enough to compensate the buyer for the perceived risk of change.

Foreign counterparties make the memory stickier. A LACNIC-region exporter, call-centre operator, tourism business, logistics provider or cloud service may serve customers whose security processes are written elsewhere. The local firm can modernise faster than its counterparties but cannot force them to rewrite their acceptance tests. It preserves IPv4 not because the local network lacks capability, but because revenue depends on being legible to parties outside its control.

Platform menus turn unfinished exit into priced discretion

Cloud and hosting platforms have learned to present IPv4 as a menu item. Public IPv4 may be included, charged separately, attached to managed gateways, placed behind a load balancer, replaced by private addressing, avoided through IPv6-only designs or sold as a static egress feature. The customer is told it has options. In many cases those options are constrained by its own customers' expectations.

If a service must be reachable from IPv4-only or IPv4-preferential environments, the "optional" public address is no longer optional. It is a priced exception created by the gap between technical possibility and commercial acceptance. A Chilean fintech, Colombian SaaS firm, Peruvian public-service contractor, Caribbean tourism platform or Central American reseller may deploy modern architecture and still pay for IPv4 because its counterparties have not moved.

This is not the detailed annual bill that belongs in dual-stack cost-incidence analysis. The point here is institutional. Platforms can endorse IPv6 and monetise the residual IPv4 dependency at the same time. They do not need to oppose transition. They can make transition a set of architecture choices in which incomplete exit becomes a chargeable product.

The platform is not necessarily doing anything improper. Scarce inputs should be priced, and managed compatibility has real cost. The economic issue is that the platform often has stronger pricing power than the regional customer. A global cloud can publish a menu and let customers self-select. A local supplier must translate that menu into a contract with a buyer that still expects old compatibility. The supplier's IPv4 charge may be visible upstream and invisible downstream.

The hosting layer has a harsher retail version. Customers trained on inexpensive virtual servers or simple business hosting often expect public IPv4 by default. If the host charges separately, the headline offer worsens. If it bundles the address, margin falls. If it shares addresses, support and reputation problems rise. If it offers IPv6-only service, the reachable customer base may be narrower than the technology suggests. The host becomes the retail carrier of the exit gap.

The commercial logic behind LARUS One is relevant because it treats network identity as a continuity asset rather than a decorative address choice. The broader lesson is not that every operator needs a particular product. It is that stable identity has value when infrastructure can change behind it. A platform that sells managed continuity can capture part of the value created by the fact that IPv4 exit is not yet commercially safe.

Platform pricing also feeds asset decisions. A customer facing visible public-IPv4 charges may bring addresses, lease them, remain with a regional host, redesign around private networks, accept managed front doors or keep workloads where the old identity is cheaper to preserve. Each choice moves dependency rather than eliminating it. IPv6 capability becomes one input in a portfolio decision: which path preserves revenue with the least avoidable risk?

That portfolio logic helps explain why regional hosts and address holders remain relevant even as global platforms expand. If a firm can preserve customer recognition through its own public identity, it may avoid part of the platform's exception pricing or reduce dependence on one architecture. If it cannot, the platform becomes the place where unfinished exit is monetised. The transition argument then becomes a bargaining question: who owns the scarce continuity input when compatibility still matters?

Vendor roadmaps move the endpoint outside the operator

Vendors win when complexity becomes normal. A universally completed migration would reduce the long tail of consulting, support, testing, certification, appliance refresh, monitoring adaptation and managed reassurance. A long coexistence regime expands that tail. Every device, security product, logging system, licensing mechanism and service desk must ask how two address families behave under ordinary fault.

That does not make IPv6 illegitimate. It makes the endpoint political. A product brochure may say IPv6 is supported. The buyer's risk team asks whether all logs, rules, plugins, escalation scripts, support evidence and compliance reports behave equivalently. A procurement file may say dual-stack. The operations team discovers that one feature remains more reliable when stable IPv4 is retained. A vendor may announce a future direction. The customer signs a renewal because the present must not break.

Many LACNIC-region operators inherit these decisions. They buy global equipment, security appliances, enterprise software, cloud services and customer devices whose roadmaps are set elsewhere. If a product has uneven IPv6 support, partial logging, IPv4-centred licensing or support scripts that assume a public IPv4 view of the customer, the local operator cannot simply declare the dependency obsolete. It works around the vendor. The workaround becomes another reason to retain IPv4.

Vendor dependence is especially awkward because it can appear after purchase. A buyer may run a proof of concept, confirm that IPv6 passes ordinary traffic and sign the renewal. Only later does a support escalation reveal that a forensic report, licence check, remote-maintenance tool or partner integration still assumes IPv4. By then the cost of replacement may exceed the cost of retaining IPv4 identity. The endpoint has moved from a network configuration to a procurement-cycle problem.

The endpoint can therefore sit outside the operator's routing plan. It may sit in a firewall vendor's support matrix, a fraud provider's evidence convention, a monitoring platform's data model, a payment gateway's allowlist process or a remote-support appliance. IPv6 can be present across the network while the commercially decisive dependency hides in a purchased product.

The political economy is subtle because everyone can claim prudence. Vendors sell support and migration services. Buyers reduce operational risk. Platforms sell compatibility. Registry institutions retain transition relevance. Operators keep customers. No conspiracy is required. Each actor responds rationally to a system in which exit has no single owner and liability is diffuse.

The question for management is whether each vendor shortens the exit clock or sells complexity around it. A vendor that makes IPv6-only service operationally safe across logs, support, monitoring, security and customer evidence reduces the old dependency. A vendor that merely advertises support while keeping critical features more reliable on IPv4 extends the dependency. The distinction should decide renewal and procurement far more than abstract claims about being future-ready.

That distinction also protects operators from tutorial drift. The issue is not to list every protocol feature that vendors should support. The issue is to ask whether the vendor's product lets the business remove a revenue-critical IPv4 obligation sooner. If not, the vendor belongs on the same dependency register as a conservative customer or platform charge.

IPv4 remains an option because it protects bargaining power

Once IPv4 is treated as an operating asset rather than a nuisance, the persistence of the old system looks less mysterious. A holder with usable IPv4 owns an option over customers, contracts, recoverability, product segmentation, leasing revenue, platform bargaining, acquisition value and supplier independence. Retiring the asset means surrendering that option. Rational holders do so only when the option's remaining value falls below its carrying cost and risk.

Lu Heng's note on Internet number resources not being political property shifts the frame from institutional vocabulary to operator reliance. The address matters because it is embedded in running networks, customer contracts and service continuity. The note on thick governance and double extraction adds the capital point: if registry discretion suppresses full asset recognition while operators still bear dependency risk, value is distorted rather than abolished.

In LACNIC's region the option appears in several forms. A large carrier may hold IPv4 for enterprise services, acquisitions, public-sector accounts, cloud-facing customers or restructuring. A small ISP may reserve stable addresses for higher-assurance business products while serving households through shared arrangements where appropriate. A hosting firm may price public IPv4 because the market still pays for it. A bank may hold addresses not for resale but as continuity insurance. A Caribbean operator may value portable identity because it reduces dependence on one supplier path.

The option is contractual as well as financial. If a provider can keep the same public identity while changing upstreams, platforms or physical routes, it owns more freedom. If every supplier change requires renumbering, new allowlists and customer education, the provider's relationship is partly hostage to the old delivery arrangement. IPv4 identity can therefore protect switching power even as IPv6 grows.

This is why a balance sheet can tell a different story from a transition presentation. An operator may regard IPv4 as a strategic reserve because it protects future deals whose exact shape is unknown. A potential buyer may value the same reserve because it lowers integration risk. A lender may not treat address value as clean collateral, yet still recognise that customers attached to stable identity are more durable. The accounting language may be cautious; the commercial behaviour reveals the option value.

This connects to the salvage-value logic in BTW's analysis of LACNIC rural-connectivity scarcity. A low-density service becomes more financeable when its public identity can survive a changed plan. The same applies to transition. A network may deploy IPv6 to reduce pressure while retaining IPv4 because future customers, acquisitions, public contracts or recovery procedures remain uncertain. Retention is not nostalgia. It is portfolio management.

Market behaviour reinforces the case. Platforms charge for public IPv4. Customers still request static reachability. Lessors and brokers find demand. Security systems still recognise stable IPv4 sources. If the market continues to pay for the asset, institutional language cannot make it economically dead. Retiring it prematurely would transfer value to the parties that still price the old dependency.

The stronger conclusion is that IPv6 deployment and IPv4 retention can both be rational. Deployment expands future reachability and may reduce pressure in suitable segments. Retention preserves a scarce option while the installed base continues to value it. A board does not have to choose an identity camp. It has to decide when one option has become cheap enough, risky enough or irrelevant enough to surrender.

LACNIC's region makes the exit clock uneven

Latin America and the Caribbean should not be treated as one migration curve. The region contains dense metropolitan enterprise markets, public-sector buyers, tourism economies, offshore and border services, low-income access areas, rural networks, island systems, data-centre demand, sophisticated banks, and small providers carrying older equipment and imported vendor assumptions. The exit clock runs at different speeds across those settings.

In large cities, the delay often comes from enterprise complexity. Banks, insurers, retailers, logistics platforms, media firms, data centres and government contractors may have strong engineering teams and dense webs of counterparties. They can support IPv6 while keeping IPv4 because a small set of valuable customer or partner systems still expects it. The dependency is expensive because the customers are valuable.

In smaller access markets, the delay often comes from support and expectations. Households may not know which protocol they use, but they know whether services fail. Small businesses discover public identity through practical problems: a camera cannot be reached, a payment terminal misbehaves, a supplier portal blocks access or a VPN becomes unreliable. The provider must either charge for assurance, provide a workaround or explain why a cheaper product cannot satisfy a business expectation.

Island markets add the restoration clock. BTW's treatment of LACNIC island network dependency shows that redundancy has value only when identity survives the interval between failure and recovery. During a cable fault, power event or supplier disruption, the relevant question is not whether IPv6 exists somewhere. It is whether the same economic identity can move quickly enough to preserve ports, hotels, banks, public services and external counterparties.

Lower-income markets add incidence. BTW's LACNIC low-income market burden explains how fixed obligations become heavier when divided by fragile revenue. Transition has a parallel effect: the customer segment least able to fund duplicate assurance may still depend on services that treat IPv4 as normal compatibility. The old dependency then appears as price pressure, rationed support, shared-address defaults or slower improvement.

Border and export-facing services add another layer. A regional supplier may sell into North American, European or Asian customer bases whose security conventions differ from the local access network's capability. A logistics operator may link port systems, customs documents, shipping platforms and payment flows with different migration speeds. A tourism operator may depend on reservation systems and foreign banks. A software provider may need to pass a corporate customer's security review written for a global template. The local IPv6 success case does not outrun the slowest revenue-critical counterparty.

This variation should discipline LACNIC's institutional posture. A registry cannot know which operator should retire IPv4 first. It cannot convert regional adoption language into firm-level exit readiness. It cannot price the customer risk of a public hospital, hotel chain, bank integrator or rural anchor tenant. Its useful role is narrower: preserve accurate, portable, auditable number-resource state so that operators can manage the exit clock with less uncertainty.

The same variation also explains why broad moral frames fail. A scarce IPv4 asset can be a rent source for one actor, a continuity hedge for another, a working-capital problem for a third and a recoverability tool for a fourth. IPv6 can be a genuine operational improvement in one product and a weak substitute in another. Regional policy language that ignores those differences will either overclaim or misallocate blame.

Risk is transferred down the contract chain

The party that demands compatibility is not always the party that pays for it. A bank asks a supplier for stable IPv4 source identity. The supplier pays a cloud platform or retains address inventory. The platform captures a charge. The supplier attempts to recover the cost in the contract. The bank resists because it regards compatibility as normal. The supplier absorbs margin loss or reduces service elsewhere. The end user never sees the chain.

Public projects can behave the same way. A municipality requires continuity with legacy applications. A systems integrator preserves IPv4. A regional connectivity provider maintains public identity and route recognition. A subcontractor handles support exceptions. If the budget treats compatibility as ordinary rather than as a funded requirement, the burden moves to the weakest party capable of keeping the project alive.

The contractual vocabulary often hides this movement. "Compatibility", "business continuity", "existing systems", "secure access" and "no disruption" sound neutral. In practice they decide who carries the last IPv4 obligation. If the buyer does not pay separately, the supplier must either price the risk into the whole contract, absorb it, lower service quality or avoid bidding. The dependency survives because it is cheaper for the powerful party to define it as normal.

This is not merely an affordability story. The mechanism is incidence through bargaining power. A foreign platform, enterprise customer, vendor or public buyer may be able to insist on compatibility without recognising the full cost. A smaller LACNIC-region supplier may have little power to force migration or recover the cost cleanly. It accepts the burden because losing the contract is worse.

Transition language helps the burden remain hidden. A procurement committee can say it supports IPv6 while retaining IPv4 acceptance criteria. A platform can advertise IPv6 while charging for public IPv4. A vendor can say both families are supported while selling support for the edge cases. A registry can promote transition while avoiding responsibility for the commercial inability to retire IPv4. Each actor occupies the modern side of the debate while preserving the old dependency.

The liability question follows. Lu Heng's argument about registry power detached from liability applies beyond registries. A party that can lengthen the exit clock without bearing the cost of delay will underprice delay. A buyer that demands IPv4 compatibility without funding it, a platform that turns exception handling into margin, or a vendor that leaves parity gaps in critical features all contributes to an endpoint that remains undefined.

The slow equilibrium is therefore rational but costly. Nobody is forced to name the full dependency. Many actors are protected by leaving it vague. Operators continue to carry IPv4 because forcing every counterparty to reveal and fund its hidden reliance would be more disruptive than retaining the asset. Political economy begins when that hidden reliance becomes a permanent background condition.

The remedy is not to make every contract a protocol manual. It is to make material dependencies visible enough that risk follows control. If a buyer's legacy system requires IPv4, the buyer should know that it is buying compatibility. If a vendor gap prevents exit, the vendor should face renewal pressure. If a platform prices public IPv4, the customer should understand whether the charge reflects genuine residual demand or avoidable architecture. Visibility does not end the dependency, but it stops the weakest party from carrying it silently.

The registry function should narrow as the clock lengthens

If transition remains unfinished, the registry's temptation is to expand its relevance. It can speak about adoption, stewardship, training, community leadership, policy progress and regional modernisation. Some of that work may be useful. The danger is mission creep. A prolonged transition does not justify broader registry authority over business models, customer geography, leasing, asset treatment or capital allocation. It justifies a more disciplined ledger.

The boundary is expressed clearly in the Bill of Rights of Uniqueness Coordination: the registry may record, coordinate and protect uniqueness; it may not rule. The Registry Continuity Fallacy makes the same separation through continuity. Protect the record, services, security chain and running networks; do not treat those necessities as proof that every authority claim of the gatekeeper must also be preserved.

During coexistence, legitimate registry functions remain important. Accurate holder records matter. Transfer history matters. Contactability matters. Reverse-DNS continuity and routing-adjacent evidence matter. Security assertions matter. Dispute flags matter. Fraud resistance matters. These functions reduce uncertainty around scarce resources and help operators prove continuity to counterparties.

But the registry should not decide whether a customer's IPv4 dependency is morally acceptable, whether a provider has moved fast enough towards IPv6, whether leasing is ideologically attractive, whether address value should be capitalised, or whether a local market deserves public identity. Those decisions belong closer to operators, customers, courts, contracts, lenders and public law.

The practical safeguard is reversibility. A holder should be able to prove control, record a transfer, preserve security assertions, update reverse DNS, mark a dispute, document a temporary operational state and later return to a normal state without turning every movement into a judgement on the holder's business model. Transition is full of temporary arrangements: a customer-notice period, a cloud migration, a public-sector renewal, an emergency route, a merger integration or a supplier replacement. If the ledger makes such states dangerous to record, operators will hide them. If it makes them safe, reality becomes more visible.

The design principle in Running-Code Primacy is practical here. Coordination should be judged by what running networks need. During transition they need uniqueness, proof of control, portability, security evidence, operational continuity and reversible correction. They do not need a regional institution to turn unfinished exit into permission over ordinary business decisions.

The companion principle in Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption points in the same direction. Common rules should be limited to invariants that must be shared. Commercial timing, customer mix, platform choice, asset retention, leasing and product design should remain local unless they threaten uniqueness or security. The longer the exit clock runs, the more important that restraint becomes.

This boundary protects the registry as well as holders. A registry that tries to own transition economics will be blamed for costs it cannot control and tempted to control choices it cannot price. A registry that remains a narrow, reliable ledger can reduce uncertainty without becoming a hidden actor in every procurement and asset decision. In a heterogeneous region, that humility is not a retreat. It is institutional risk control.

NRS is useful only as holder-side exit coordination

Number Resource Society belongs in the future-facing part of the analysis, but only in proportion. NRS is not a replacement registry, an access network, a pricing authority, a public-address pool or a central command over transition. Its positive value lies in holder-side coordination around rights, exit, portability, redundancy and accountability.

The need appears because individual operators have limited leverage. A small ISP cannot force global platforms to make IPv6-only service commercially safe. A regional host cannot make every enterprise buyer update allowlists. A Caribbean operator cannot redesign foreign booking systems or payment controls. A public-service supplier cannot make legacy procurement disappear. Holders can, however, coordinate expectations: proof should be portable, records should be accurate, disputes should not destroy the last verified operational state, leasing should be transparent, and no registry should convert transition language into capital control.

The value of a holder-side institution is therefore defensive and architectural. It lets otherwise isolated operators describe common risks without asking a registry or platform to define the problem for them. It can turn a scattered set of grievances into a structured demand for exit, portability and accountable records. It should not pretend that advocacy alone will make customers rewrite systems or vendors repair parity gaps.

Lu Heng's note on why NRS exists frames decentralisation as systems engineering rather than ideology. That is the right public reading. The value is not that every institution disappears. The value is that exit becomes credible, single-point discretion becomes easier to test, and holders are less isolated when registry-side or counterparty-side risk is pushed onto them.

The NRS case archive is useful because hidden harms survive by remaining isolated: one delayed correction, one route-recognition problem, one disputed control state, one business unable to carry identity through a supplier change. Aggregated, those events show where the exit clock is lengthened by institutional or contractual friction. Tools such as NRS Shield matter only if they make proof, continuity and holder bargaining more credible without becoming another centre of discretion.

The test for NRS is concrete. Does it lower the cost of proving control? Does it make registry discretion more reviewable? Does it improve the outside option of a holder negotiating with a wholesaler, platform or buyer? Does it reduce fear that recording commercial reality will trigger institutional suspicion? Does it support voluntary adoption rather than imposing another mandatory layer? If yes, it belongs in the cost-reduction column. If not, it is another governance brand.

That restraint is essential. If NRS were presented as the new central authority that decides when every operator must retire IPv4 or how every buyer must modernise, it would reproduce the problem. Its proper role is narrower: strengthen rights, portability, redundancy and accountability so that the old dependency can be managed honestly while the new path grows where it is actually useful.

For a LACNIC-region operator, the practical NRS question is not ideological. Would stronger holder coordination improve the firm's outside option in a platform negotiation, a registry dispute, a transfer, a leasing arrangement or a customer continuity problem? Would it make proof easier to rely on during a migration? Would it make exit credible enough that counterparties behave differently? If not, it should remain peripheral. If yes, it is part of the transition economics.

The retirement model is an avoided-cost schedule

The serious transition test should be an avoided-cost schedule. What costs can the operator stop paying once IPv4 is genuinely retired? What risks disappear? Which customers remain? Which counterparties accept the change? Which recovery procedures still work? Which assets can be sold, written down or reclassified without impairing service, revenue or bargaining power?

The schedule should be built by dependency, not by rhetoric. Identify each customer, counterparty, product, application, support convention or recovery procedure that still requires IPv4 identity. Estimate the revenue protected by that dependency, the cost of maintaining it, the cost of migrating or abandoning it, the probability of failure during migration, the notice period required and the option value of retaining it. The endpoint arrives only when the remaining dependencies are cheaper to migrate, replace or abandon than to preserve.

The schedule should also record who can act. Some dependencies can be solved by the operator through product design, customer notice or architecture. Some require a customer to change procurement or allowlists. Some require a vendor release. Some require a platform feature or price change. Some require only a better evidence file. The classification matters because an operator can retire a dependency it controls faster than one held by a bank, public buyer, global platform or foreign supplier.

This analysis will produce uncomfortable findings. A network may discover that most traffic can use IPv6 while much of the margin still sits with customers that expect IPv4. A public-service supplier may find that one old acceptance clause preserves a material obligation. A host may find that a visible public-IPv4 add-on is less profitable than the churn it prevents. An access provider may find that the customers most able to pay for assurance are also the customers least willing to give up stable public identity.

The findings should not be used to shame operators for failing to complete a migration. They should make the endpoint honest. If a buyer wants compatibility, the buyer should see the cost. If a platform prices the exception, the customer should understand why the exception is needed. If a vendor's support gap preserves IPv4, renewal should recognise that dependence. If registry uncertainty raises the risk premium, the premium should be named.

The schedule also distinguishes annoying dependencies from decisive ones. A low-margin residential exception may be handled through product design, notice and support. A payment-system exception attached to a large merchant, a regulated customer or a public-service supplier cannot be treated the same way. Management should rank each dependency by revenue protected, switching cost, counterparty bargaining power, migration notice and failure severity. The stubborn case is often not the one with the most traffic. It is the one with the strongest claim on continuity.

The output should be managerial rather than decorative: a list of dependencies, responsible parties, costs avoided if retired, risks created if removed too early, and dates on which a new test can be run. The value lies in making the old obligation falsifiable. If the dependency remains, it should have a named reason. If it disappears, the asset file should be updated. Transition then becomes an audit trail of economic exit rather than a mood.

This is where adoption theatre ends. A chart can show that IPv6 is growing. The retirement model asks whether the old asset has lost economic purpose. The two questions can diverge for years. When they do, the books, contracts and customer-risk files should outrank public ceremony.

The avoided-cost schedule also prevents overreaction. It may show that some IPv4 should be sold, some leased, some retained for strategic customers, and some retired from low-value uses. It may show that IPv6-only products are commercially safe for one segment and reckless for another. It may show that a procurement change would save more than a network redesign. The answer is unlikely to be a single institutional slogan because the dependencies are not single.

The write-down meeting is the final proof

The final scene is not another registry discussion. It is an asset committee at a regional operator. The treasurer, network head, customer-risk owner, corporate-development lead and external auditor are deciding whether IPv4 can be impaired, derecognised, sold, retained or treated as a strategic reserve. The IPv6 programme has succeeded technically. More traffic uses it. New services prefer it where they can. The board would like lower complexity. The auditor asks a narrower question: can management honestly say the last revenue-critical IPv4 dependency is gone?

The network head lists services that could operate without IPv4 tomorrow. The treasurer lists customers still paying, directly or indirectly, for stable public identity. The risk owner lists allowlists, payment relationships, vendor support paths, public-sector contracts and recovery procedures that still assume IPv4. The corporate-development lead notes that address inventory affects acquisition value and supplier bargaining. The auditor is not interested in whether transition language sounds modern. The auditor wants to know whether the asset still contributes to revenue protection, continuity or option value.

At that table, adoption percentages are secondary evidence. They show that the new path works. They do not prove that the old economic dependency has disappeared. If the company still wins contracts because it can provide stable IPv4 egress, still avoids churn because customers do not have to change allowlists, still negotiates better with platforms because it controls scarce identity, and still carries recovery plans that depend on recognised IPv4, the asset is not dead. It is unfashionable capital.

This is the endpoint LACNIC's transition politics must face. A commercially exercisable exit requires more than deployment, education or moral pressure. It requires customers, counterparties, vendors, platforms, procurement rules and recovery procedures to stop making IPv4 identity valuable. Until that happens, transition remains a coexistence regime with distributional consequences.

The registry should respond with narrower excellence, not broader authority: accurate records, proof of control, transfer clarity, security continuity, dispute isolation, portability and restraint. Operators should measure the real gap and price it honestly. Buyers should fund compatibility when they require it. Platforms should not pretend priced IPv4 exceptions are merely optional when customer contracts make them mandatory. Vendors should be judged by whether they shorten the exit clock or sell complexity around it. Holder coordination through NRS should strengthen rights and exit, not replace one centre with another.

The committee's conclusion may be undramatic. IPv6 will keep growing. IPv4 will be retired where commercial dependency has truly ended. Elsewhere it will remain because it protects revenue, continuity and optionality. The political economy lies in that unevenness. The endpoint is not a date in an institutional slide deck. It is the moment a responsible treasurer can remove the last IPv4-dependent obligation from the business without misleading the auditor, the customer or the balance sheet.

For many LACNIC-region operators, that moment has not arrived. The honest task is not to deny IPv6 or romanticise IPv4. It is to measure the non-exercisable exit and ask who benefits from keeping it that way. If the answer is installed-base safety, platform pricing, vendor complexity, asset optionality and institutional relevance, the region is not living through a simple technology swap. It is living through a negotiation over who pays for the old identity until the new one is safe enough to stand alone.

Sources and further reading

These references provide the article's public doctrine and background context. They are used for institutional-economic framing, not for adopting any registry or official-sector narrative.