Consider a hypothetical team paying an IPv4 fee for each server. Adding applications, regions and staging environments can turn a modest per-address charge into a substantial recurring expense. The useful question is which addresses the services actually need, and what it would cost to change that architecture.
This guide connects IPv4 exhaustion with pricing, address reputation, transfer requirements and practical hosting decisions. It covers shared web entry points, outbound connectivity, email and gradual IPv6 adoption. It is a planning framework, not a current price list or a promise that the market will keep moving in one direction.
Separate three costs from the outset: an extra address supplied with hosting, a block leased from another organization, and a registry-approved transfer. They have different eligibility, routing and operating requirements. Moving traffic to IPv6 also differs from releasing a billable IPv4 allocation; only the latter directly removes that address charge.
What IPv4 Exhaustion Actually Means
A finite address pool resembles a town with a limited supply of street numbers, but not every internet device needs its own public IPv4. Private networks and shared gateways let many workloads use fewer public addresses. IANA distributed its final unallocated blocks to regional registries on 3 February 2011. Regional pools did not all become empty on that date: RIPE NCC made its final /22 allocation from its remaining pool on 25 November 2019.
Existing IPv4 addresses continued to work. Returned addresses, waiting lists and transfers remain subject to each registry’s policy. Buying or leasing existing space therefore became important options, while address sharing and IPv6 offered architectural alternatives. Scarcity affects choices, but it does not imply that every market price rises continuously.
The IANA IPv4 address-space registry records allocations and reservations; it is not an inventory of blocks available for purchase. RIPE NCC’s dated 2011 announcement and 2019 announcement establish the depletion milestones. Current eligibility must be checked separately from that history.
What Determines IPv4 Prices?
Five factors help explain a quote: supply that matches the required block size, registry eligibility and processing, address history, continued dependence on IPv4, and the timing of demand. A block with known abuse or routing problems can require remediation before use. A clean blocklist check or higher price does not guarantee future reachability or mail delivery.
New regions, customer allowlists or legacy applications can create urgent demand, but additional application instances do not automatically need additional public addresses. Check the actual protocol and isolation requirement. A dedicated address is also not equivalent to dedicated CPU, network capacity or a complete security boundary.
Prices can fall despite scarce supply. The 2025 review published by ARIN on 22 January 2026 reports renewed declines in observed transfer prices during 2025. That dated market evidence is not today’s hosting tariff or a quote for every block. Compare offers from the same period and distinguish a one-time transfer price from recurring rental and management charges.
Where Address Costs Appear in a Hosting Stack
Start with public addresses assigned to servers, load balancers, firewalls and outbound gateways. Include staging environments and support access, not just customer-facing production services. Record the owner, purpose, recurring fee and release conditions for each allocation; an address can be idle while still billable.
Private services that do not accept public connections may sit behind restricted ingress and egress layers. Consolidation can reduce public assignments, but load balancer, NAT, bandwidth and operating costs belong in the comparison. Test capacity and failure behavior before changing the address plan.
Certificate-related assumptions deserve a separate check. SNI and name-based virtual hosting allow multiple HTTPS domains to share an address when server and client support is suitable. Each hostname still needs a matching certificate and virtual-host configuration. Older clients, unusual protocols or counterpart allowlists may require a different design.
Email adds a reputation decision. A dedicated IP can separate sending streams, but needs appropriate volume and ongoing management. A well-managed shared sending service may suit low-volume or irregular senders better. Treat mail addresses as a specific operational requirement, not an automatic allocation for every application or domain. For a new sending IP, start with consistent, gradually increasing volume to recipients who have consented, and monitor temporary rejections, permanent failures and complaints. If problems increase, pause further volume increases and resolve the cause. Verify SPF, DKIM and DMARC configuration against the recipients’ current sender requirements; warming up an IP does not replace authentication or guarantee delivery.
Concentrate compatible public entry points behind a reverse proxy or load balancer and keep internal services on private networks, such as RFC 1918 ranges. Separate inbound publishing from outbound NAT: a NAT gateway does not by itself publish an internal web service, and neither NAT nor a private address replaces firewall policy.
At the web edge, combine name-based virtual hosting with SNI and test the certificate selected for each hostname. A layer 7 HTTP proxy can route on application information it actually terminates; TLS passthrough has more limited visibility. The HAProxy load balancing guide covers health checks, passthrough and updates. Do not assume that a resilient multi-region design can or should use just one address.
For outbound connections, shared NAT can serve many workloads within its connection and port limits. Check gateway capacity, timeouts and recurring charges. Preserve translation records with timestamps, address/port pairs and protocol, and correlate them with workload logs; a shared public source address alone cannot identify the originating application.
Keep email routing explicit when centralizing egress. If mail is supposed to leave through a dedicated sending address, a generic NAT rule must not silently replace it with another public IP. Verify the source seen by receiving servers, PTR/forward DNS and sender authentication before changing the egress path. An external sending service is another option when its controls and cost suit the workload.
Finally, audit assignments that were created for debugging, migration or temporary support. Check listeners, DNS, monitoring, scheduled jobs and partner allowlists before retiring one. Confirm that the private or shared replacement is reachable by the people and systems that need it, then record the provider’s billing-stop date.
Leasing or Transferring a Block: Check Feasibility First
Buying an extra IP from the hosting provider differs from bringing in a block leased or transferred from elsewhere. Before committing to an external block, obtain confirmation that the intended provider, service and region support BYOIP or customer-supplied routing. Confirm accepted prefix sizes, registration/control requirements, routing fees and lead times. Support is not universal across VPS and cloud products.
Then inspect prior use, abuse history and relevant blocklists, along with registry records and geolocation data. Confirm who may authorize the routing and who will announce the prefix. A ROA must authorize the intended origin ASN and advertised prefix length; RPKI origin validation does not validate the entire AS path or prevent every route leak. Provide the LOA or other authorization required by the operator. A clean reputation check does not prove routing authority, and valid routing records do not prove a clean mail reputation.
For resources under ARIN policy, use ARIN’s transfer process overview to verify the relevant source, recipient and inter-registry conditions. Other registries have their own rules. What the market calls “buying” remains subject to registration and resource-use agreements; a broker’s payment request is not evidence that the registry will approve the transfer.
Compare leasing and transfer over the same planning period. Include setup, renewal, registry and routing charges, reputation work and exit costs. A lease should specify termination or recall conditions, PTR control, abuse responsibilities and time to renumber. A transfer commits capital and still requires administration. BYOIP may help retain an address plan only within the provider’s supported scope; do not assume a block can be advertised freely across every region or platform at once.
Introduce IPv6 Without Hiding IPv4 Dependencies
Consider a hypothetical rollout on a low-risk web edge. Configure IPv6 routing, listeners, TLS and firewall policy first, verify connectivity, then publish AAAA records and monitor real requests. Keep the IPv4 path available while compatibility is required. Lower IPv4 connection counts alone do not reduce address charges.
Many modern clients use Happy Eyeballs to stagger connection attempts across address families, reducing delays when one path fails or is slow. This does not guarantee the fastest route or conceal every broken IPv6 configuration. Hostname certificates can serve either protocol, but application IP parsing, access lists, logging and dependency connectivity still need testing.
A CDN may offer IPv6 to visitors while reaching the origin over IPv4 or IPv6 under its own configuration. Verify those two connections separately; an IPv6-capable edge does not prove the origin supports IPv6. The IPv6 overview provides background terminology. Use measured reachability, error rates and audience support to decide which service to migrate next.
For email, check receiver and sending-provider support as well as forward/reverse DNS, authentication and actual delivery results. IPv6 address space does not remove sender-reputation requirements. Retain a working IPv4 mail path wherever the destination or delivery requirements still need it; a successful web migration is not evidence that mail can make the same change.
Operate and Renumber Addresses Safely
A restricted bastion or VPN can replace public support access on individual machines when the network design allows it. Test administrator access, automation and outbound dependencies before releasing addresses. Include the replacement’s availability, operating effort and cost in the decision, and keep a documented recovery access path.
Before renumbering, lower the relevant DNS TTL far enough ahead for the previous TTL to expire; a later change does not rewrite already cached answers. Coordinate the cutover, observe the new path, then restore suitable normal TTLs. For sending mail, each PTR hostname should resolve back to the sending IP via A for IPv4 or AAAA for IPv6. Track geolocation correction requests where dependent content or payment systems use that data; databases do not all update together.
Watch abuse reports and unusual outbound traffic. If one service is compromised, contain and fix it before reassigning or replacing its address; moving the same behavior does not solve the cause. Apply appropriate egress policy and rate limits, preserve useful incident records and identify every service that shared the affected address.
Turn the Design Into a Staged Change Plan
Choose one allocation or service with a clear owner and a documented replacement path. Record the baseline address count, fees, connection failures and latency. Define acceptance criteria and a rollback path before changing production; keep any old address required for recovery until those conditions are met.
Test the relevant failure cases in staging: a proxy node going away, NAT capacity becoming constrained, the wrong certificate being selected, or an IPv6 route becoming unreachable. For mail, include the observed public sending address and receiver responses. These tests determine whether consolidation is viable; the target is not the smallest possible pool regardless of reliability.
During rollout, record the exact allocation and DNS changes, the person responsible and the evidence needed to proceed. Allow existing connections and cached DNS users to leave the old path before retirement. External blocks also need the agreed provider and registry steps completed, rather than merely copied settings on a server.
When Keeping More IPv4 Capacity Is Justified
Some workloads require stable source addresses for customer allowlists, separate public entry points for resilience, or support for older clients and protocols. Document each exception and the requirement it meets. Sharing an address is useful only if those dependencies, capacity limits and failure domains remain acceptable.
Centralizing egress can create a shared failure point and port bottlenecks. Test gateway redundancy and failure behavior and ensure logs retain the attribution required by the service. A distributed design may cost more in addresses while meeting a reliability requirement the centralized design cannot satisfy.
IPv6-only operation is appropriate only after the service’s callers, dependencies and operational tools can reach it through the intended paths. Dual-stack is a valid intermediate state even if the IPv4 bill initially stays unchanged. Revisit an allocation when those dependencies change, not because an IPv6 traffic percentage alone crossed a threshold.
Compare Total Cost Over a Common Planning Period
Build a simple cost model from billable address count, price, duration, setup or transfer fees and continuing management costs. Add proxy, NAT, traffic and mail-service charges introduced by the alternative. Compare rising, flat and falling price scenarios and the contract’s renewal terms. After a successful change, verify when released allocations stop billing and measure the net expense difference.
Some spending buys a necessary capability: sufficiently active dedicated mail streams, a stable allowlisted source or a tested redundant edge. For each item, identify the operational requirement and an alternative cost. An extra IP alone does not guarantee inbox delivery, performance or security isolation, so attribute the benefit to the complete service design.
Keep Evidence With the Address Plan
Use the IANA registry to identify the responsible address-space context, and ARIN’s transfer guidance where its policies apply. Save the applicable policy date, provider approval, quote validity and routing responsibilities with the change record. The IPv6 primer can support shared terminology during handover; it does not replace the provider’s configuration documentation or your test evidence.
Start With One Measurable Address Decision
A useful first step is to select an allocation whose need is uncertain, identify every dependency and compare a tested replacement with the current arrangement. This turns a market concern into a concrete operating decision with an owner and a measurable cost.
If the address is still necessary, record why and when to review it again. If it can be released, retain the acceptance results and check the next invoice. If more space is required, complete provider eligibility and routing checks before choosing between a lease and a transfer.
Repeat the review at renewal, a new-region launch or a material workload change. The aim is a justified, maintainable address plan; the appropriate IPv4 count depends on the services it supports.
