Summary

  • IPv6 readiness is not production readiness. A service can support IPv6 and still be pinned to IPv4 by DNS, reverse DNS, firewall rules, partner allowlists, route authorization, geolocation and reputation.
  • LARUS's IPv4 leasing guide draws a useful distinction: capacity is having enough addresses today; continuity is keeping the identity built around them usable when a workload grows, renews or changes providers.

The production problem is not the protocol label

A /22 contains 1,024 IPv4 addresses. On paper, that is a capacity decision. In production, LARUS's IPv4 leasing guide notes, those addresses can become connected to DNS, customer configurations, firewall policies, API allowlists, PTR records, routing, geolocation databases, monitoring systems and IP reputation. The change owner is no longer just swapping an address; they are coordinating dependencies across security, procurement, customer operations and partner management.

That is the practical tension behind IPv4 and IPv6 coexistence. IPv6 deployment continues, but it does not automatically update the systems that made the old address valuable. LARUS's guide draws a useful distinction between IPv4 capacity and IPv4 continuity. Capacity is having enough addresses for a workload today. Continuity is keeping the operational identity built around those addresses usable as the workload grows, renews or changes providers. The distinction matters because it names the governance question: which dependencies can move, which cannot, and who is accountable when they do not.

Why coexistence persists in real networks

An IPv4 address begins as a numerical identifier. After deployment, LARUS's guide notes, it can become part of a network's operational identity: customer relationships, application endpoints, DNS, security policies, reputation databases, external integrations, routing and business processes. The longer the same address space remains in production, the more systems may remember or depend on it.

That is why a network may run IPv6 where it can and retain IPv4 where it must. The balance is not ideological. It depends on the workload's exposure. A temporary test environment with no external users can be renumbered with limited coordination. A customer-facing API with partner allowlists, a mail service with reverse-DNS requirements, or a routed prefix announced from the operator's own ASN has a different risk profile. The first may tolerate replacement; the second may not.

Three operational scenarios

Consider a partner-facing API. The application may support IPv6, but partners may still restrict access by source address. LARUS's guide names API allowlists and customer configurations among the places IPv4 becomes embedded. Moving the endpoint without coordinating those allowlists can break connectivity even when the network path is technically available. The governance response is not to ban IPv6; it is to map which external parties must act before the old address can be retired.

Consider mail or logging infrastructure that depends on reverse DNS. LARUS's guide says leased IPv4 can support PTR records when the provider and address structure allow management or delegation, but that capability is not automatic. If the workload requires reverse lookups and the lease does not provide a workable PTR path, the addresses are not production-ready for that use. The decision should be tested before migration, not discovered after cutover.

Consider a prefix announced from the operator's own ASN. Routing authorization is separate from commercial availability. LARUS's guide notes that a transit provider may request a letter of authorization before accepting a BGP announcement, and that an RPKI route-origin authorization must match the intended origin and maximum prefix length. A mismatch can affect reachability even if the lease itself is valid. The operational lesson is that leased capacity becomes usable capacity only when the route, authorization and operational contacts line up.

Lease, buy, retain or renumber as a progression

The four options are not equal choices on a menu. They represent different answers to the same question: how long will this workload depend on this address identity? LARUS's guide compares lease and buy on upfront capital, payment structure, fit for temporary requirements, scaling flexibility, renewal dependency and typical use. Retaining existing space preserves continuity but still requires utilization review and documentation. Buying may provide longer-term control but commits capital and administrative effort. Leasing can add capacity without permanent acquisition, but introduces renewal dependency and requires clear terms.

Renumbering can reduce exposure to scarce space, yet shifts cost into DNS, reverse DNS, firewalls, allowlists, routing authorization, geolocation and reputation.

LARUS's guide warns that a lower-priced prefix that later needs to be unexpectedly replaced may create a substantially larger operational cost. That is why a headline lease rate is a poor decision unit. Compare total operational cost over the period the addresses are needed, not a single price line. The point is not that leasing is always better or worse; it is that the cheapest prefix is not necessarily the lowest-risk prefix once production depends on it.

Governance controls that make coexistence real

A workable plan starts with a dependency map, not a protocol preference. The map should show where addresses appear in DNS, reverse DNS, firewalls, customer configurations, partner allowlists, VPNs, monitoring and reputation systems. It should also show which of those dependencies are under the operator's control and which require a third party to act. That determines whether renumbering is a maintenance task or a cross-organizational project.

The second control is routing identity. Before production, the operator should know which ASN will originate the prefix, who controls the ROA, what maximum prefix length applies, who can change routing, and what happens at lease end. LARUS's guide frames these as deployment questions, not sales extras. The third is operational readiness: reverse DNS management, geolocation correction where location matters, abuse-handling contacts and a named escalation path. These conditions turn address capacity into deployable capacity.

Renewal belongs in the same discussion. The longer a prefix stays in production, the more systems remember it. A renewal conversation that starts only after expiration is a continuity risk, not a commercial negotiation. LARUS's guide recommends discussing renewal well before deployment when customers or systems will depend on the addresses. That is a governance recommendation, and it follows from the embedding problem rather than from any market forecast.

From capacity to continuity: an engineering acceptance test

A leased prefix should not be treated as production-ready when the contract is signed. It becomes deployable only after four deployment conditions are checked. First, the route: confirm whether the prefix is already announced, which ASN originates it, and whether prior routing must be withdrawn. Second, authorization: establish who supplies the letter of authorization, which ASN is authorized, and who controls the ROA and maximum prefix length. Third, identity services: confirm whether reverse DNS can be managed or delegated, and whether geolocation and abuse contacts match the deployment.

Fourth, renewal: identify notice periods, availability at renewal, substitution rights and exit obligations before the prefix is embedded.

Those checks are not interchangeable with price comparison. They determine whether the prefix can be used by the workload at all. A route that is commercially leased but not correctly authorized is not operational capacity. A prefix without a workable PTR path is not ready for a mail workload. A renewal term that ignores embedding is not a continuity plan. The engineering acceptance test therefore belongs before migration, not after cutover.

What this article can and cannot settle

This article does not establish market-wide adoption rates, price direction or investment returns. It should not be used to claim that every scarce block will appreciate or that every lease will deliver a fixed yield. LARUS's guide is useful as a map of deployment and continuity controls, not as a forecast. Scarcity makes governance more important; it does not make every IPv4 holding a financial winner.

The operational consequence is straightforward: treat the guidance as a checklist for capacity, routing, identity and renewal. For a production network, receiving the addresses is only the first step. They must also be routable, correctly authorized, operationally usable and appropriate for the intended workload.

Conclusion

IPv4 remains operationally relevant because production networks are layered systems, not clean protocol migrations. IPv6 deployment can continue, but compatibility, installed dependencies and lifecycle risk keep IPv4 in the design for many workloads. The defensible position is conditional: retain or acquire where continuity and control justify it; lease where flexible capacity fits the requirement; and renumber where the dependency map allows. The question is not whether IPv6 is better. It is which service can move without breaking the systems that make it work.