IPv4 Scarcity: Plan Address Costs for Hosting

IPv4 availability and pricing are important constraints when planning a new project, sizing a VPS cluster, or reviewing server invoices. IANA exhausted its original free pool in 2011, while the five regional internet registries (RIRs) now apply different remaining-pool or waiting-list policies, and obtaining addresses on the secondary transfer market can add substantial costs. In this article, we will unpack what IPv4 address exhaustion means, what affects prices, and how hosting and network design can reduce your exposure to IPv4 costs. We will examine design options across shared hosting, VPS, dedicated servers and colocation, including ways to use fewer IPv4 addresses while accounting for performance, uptime and email deliverability.

What Is IPv4 and Why Did It Run Out?

A quick refresher on IPv4

IPv4 (Internet Protocol version 4) is the addressing system that has powered the internet since the early days. An IPv4 address is a 32-bit number, usually written in dotted decimal format like 203.0.113.45. With 32 bits, you get about 4.3 billion theoretical addresses. That sounds huge, until you consider that we now connect billions of smartphones, laptops, servers, IoT devices, routers and virtual machines.

Those 4.3 billion addresses are not all usable as public internet addresses. Large ranges are reserved for private networks (like 10.0.0.0/8 or 192.168.0.0/16) and special purposes (multicast, loopback, documentation, etc.). Hosting providers, ISPs and enterprises must plan their use of the remaining public address space.

How IPv4 addresses are allocated

Five Regional Internet Registries (RIRs) administer resources in their service regions: RIPE NCC, ARIN, APNIC, LACNIC and AFRINIC. Historically, IANA (Internet Assigned Numbers Authority) allocated large blocks from its free pool to the RIRs, which distributed smaller allocations under regional policies. This historical model must be distinguished from later distributions of recovered addresses and from each registry’s current request process.

For years, allocations were relatively generous. Enterprises could receive /16 or even larger blocks (tens of thousands of IPs) when the internet was much smaller. Many of those early allocations are still in place today, even if the organisations do not use every address. Unused legacy allocations can limit the supply available to other organisations, although the underlying constraint is IPv4’s finite address space.

The exhaustion timeline in practice

On 3 February 2011, IANA distributed the final five /8 blocks from its original free pool, one to each RIR. Recovered address space was distributed later. On 1 March 2019, IANA allocated two /24 blocks to each RIR and announced that this effectively exhausted what it could distribute under the recovered-pool policy. Neither date means all RIRs stopped allocating addresses under identical rules. See the 2011 final /8 announcement and IANA’s 2019 recovered-pool announcement.

Sources: RIPE NCC waiting list, ARIN waiting list, APNIC resource policy, LACNIC exhaustion phases and AFRINIC policy manual. These policies do not establish a hosting plan’s included addresses or current stock. Check the relevant registry’s current terms when applying.

As RIR free pools became constrained, options for obtaining or making room within sizable IPv4 allocations included:

• Reclaiming and reusing underutilised internal space
• Transferring addresses between organisations on the secondary market
• Leasing addresses where the relevant registry policy and the holder’s rights permit it

These options introduce acquisition, leasing and administration costs that can affect hosting invoices.

What Drives IPv4 Address Prices

Basic economics: finite supply and continued demand

IPv4 has a finite address space. Transfers and reuse can change how much space is available on the market, but cannot expand the protocol’s address capacity. New data centers, SaaS platforms, microservices, VPS instances and dedicated servers can add demand where they need public IPv4 connectivity; they do not necessarily need one public address per workload.

When demand increases relative to available supply, prices can rise. That does not establish a continuous upward trend: prices also depend on how much space holders release and what buyers need. Organisations with unused legacy IPv4 blocks may sell them at negotiated market prices rather than their original allocation cost.

Secondary markets and transaction costs

IPv4 blocks can be sold or leased through brokers and marketplaces. Due diligence should cover applicable registry policies, the holder’s authority to transfer or lease the space, and reputation risks such as spam history; a listing alone does not establish that these checks have been completed. Potential overhead includes:

• Broker fees and legal costs for contracts and due diligence
• Engineering time for renumbering, RPKI, routing and security checks
• Applicable registry fees for transfers or record updates, depending on the RIR and transaction

These costs can contribute to the price per IP or to a provider’s monthly IPv4 surcharge. A specific surcharge also reflects the provider’s pricing policy; market overhead alone does not establish why an individual bill increased.

Reputation, abuse and the cost of maintaining addresses

Not all IPv4 addresses are equal. For web and email hosting, reputation matters a lot. An IP that has been used for spamming, DDoS attacks or malware hosting can be listed on blocklists or carry a bad history with major email providers. Cleaning that up takes time and is not always fully successful.

Because of this, IPv4 ranges with minimal known abuse history and well-maintained routing/security may be more attractive to buyers than tainted ranges. Abuse monitoring, incident response and reputation maintenance also require ongoing work. A “clean” label is not a guarantee of future reputation or email delivery.

Data center growth, AI and IoT

New data halls, AI/ML clusters and edge infrastructure can add IPv4 demand when APIs, VPN endpoints, customer workloads or legacy integrations need IPv4 connectivity. Internal management and cluster traffic need not each have public addresses. The effect on public IPv4 demand depends on the architecture, including NAT and IPv6 use.

IoT devices and mobile connections may still need to reach IPv4-only services. Carrier-grade NAT (CGNAT) helps mobile and broadband operators share public addresses among users. Public-facing services may also share IPv4 addresses through gateways or proxies, so device counts alone do not establish address demand or price changes.

How IPv4 Exhaustion Impacts Your Hosting and Network Design

Documenting a new IP request

When requesting additional IPv4 addresses, be prepared to document their intended use. Requirements vary by provider and RIR policy, but useful capacity-planning questions include:

• What will each IP be used for?
• Can some workloads share an IP via name-based virtual hosting or SNI?
• Are there services that can move to IPv6-only? Dual-stack can support a transition, but still uses IPv4.
• How long will the allocation be needed?

This type of capacity planning helps identify which workloads genuinely need separate addresses and which can share them. For VPS, dedicated servers or colocation, compare that inventory with the chosen plan’s allocation rules and per-IP charges.

When a dedicated IPv4 address is justified

Multiple HTTPS websites can share one IPv4 address and port 443 using correctly configured virtual hosts and Server Name Indication (SNI). The client supplies the intended server name during the TLS handshake so the server can select the appropriate SSL certificate. SNI does not itself provide tenant isolation or guarantee the security of hosted applications.

A dedicated IPv4 address may be useful or required in specific cases, but the service type alone does not establish the need:

• Outbound email services where sending volume and reputation management justify a dedicated IP rather than a managed shared pool
• Services requiring legacy clients without SNI support
• Custom network setups where VPN endpoints, reverse proxies or routing requirements cannot be met with shared addressing
• Regulatory or contractual requirements demanding IP isolation

Name-based sharing is an option for many shared-hosting and VPS websites. Check client compatibility, application routing and any contractual isolation requirement before deciding whether an address can be shared.

Email deliverability and IPv4 scarcity

Email infrastructure is one area where IPv4 scarcity is felt strongly. Each sending IP builds its own reputation. If many customers share one outbound IPv4 and one of them sends spam, everyone may suffer. On the other hand, a dedicated sending IP per small mailbox is usually unnecessary and adds cost without guaranteeing better delivery.

The right arrangement depends on your risk profile and sending volume. For important transactional or marketing email, consider:

• A managed shared sending pool for low or irregular volume, or a dedicated IPv4 address or pool when sustained volume and operational capacity justify managing a separate reputation; neither guarantees delivery
• Correct DNS configuration with SPF, DKIM, DMARC and PTR records – see our guide on SPF, DKIM, DMARC and rDNS for practical steps
• Conservative warm-up of new sending IPs to avoid sudden spikes

This kind of planning uses IPv4 addresses where they add real value, not just out of habit.

Budgeting and long-term contracts

Treat IPv4 as a separate line item in your infrastructure budget. Prices can change in either direction and a provider’s tariff depends on its contract and operating model. When negotiating dedicated servers, colocation or VPS clusters, ask about:

• Per-IP monthly or annual charges
• Included baseline of IPv4 addresses per server
• Discounts or stability on longer-term contracts
• Policies for adding, removing or renumbering IPs later

Model both the current workload and growth scenarios. Compare compute, address charges, proxy or gateway capacity, redundancy and administration together. For example, if one IPv4 is included and every additional address has the same monthly fee, a VPS using eight addresses adds seven times that fee. This is illustrative arithmetic, not a market quote. Our guide to cutting hosting costs by right‑sizing VPS, bandwidth and storage provides further budgeting context.

Technical Strategies to Reduce Your IPv4 Footprint

Adopt IPv6 wherever possible

IPv6 expands the address size from 32 to 128 bits, providing much more space for network design. Usable prefixes still depend on allocation policy, provider routing and your addressing plan. IPv6 can support end-to-end connectivity without using NAT to conserve addresses, but firewall rules, access controls and application compatibility remain necessary.

In a dual-stack deployment, IPv4 remains available while IPv6 is enabled alongside it. Serving more traffic over IPv6 does not by itself release any assigned IPv4 addresses. A staged rollout should:

• Confirm provider prefixes and routing, then test applications, DNS, firewall rules and monitoring over IPv6.
• Verify external IPv6 reachability before publishing AAAA records; monitor both protocols and keep a rollback plan for DNS and network settings.
• Move compatible internal services separately, and release IPv4 only after its DNS, routing, firewall and external dependencies are no longer needed.

A server or network refresh is a useful point to assess IPv6 requirements. The guide to rising IPv6 adoption rates and infrastructure planning covers rollout context, while the IPv6 setup guide for your VPS server discusses configuration. Adapt settings to the actual provider and operating system.

Consider IPv6‑first and IPv6‑only segments

Internal services can be IPv6-first or IPv6-only when their clients and dependencies support it. Direction matters at the network edge: stateful NAT64 with DNS64 typically lets an IPv6-only client connect to an IPv4 server. DNS64 synthesises AAAA answers from A records for this purpose. This is not a general mechanism for IPv4-only visitors to reach an IPv6-only website.

For inbound IPv4 visitors, an IPv6-only web origin needs an edge service that accepts IPv4 and can reach the origin over IPv6, such as a suitably configured dual-stack reverse proxy, CDN or load balancer. That edge still consumes IPv4 and must be sized for capacity and redundancy. Read the guide to publishing a website on an IPv6-only VPS with this distinction between outbound translation and inbound publishing in mind.

Use name-based virtual hosting and SNI correctly

For HTTP/HTTPS websites, name-based virtual hosting can serve multiple domains on one IPv4 address. SNI carries the requested server name during TLS setup and allows the server to choose a certificate. Correct routing, certificates, application permissions and resource limits must still be configured independently.

Key points to do this safely and efficiently:

• Check that the selected web server and clients support SNI; configure and test the certificate served for each hostname.
• Use separate virtual-host configurations, suitable logs, access permissions and resource controls.
• Automate certificate issuance and renewal where supported, for example with Let’s Encrypt, and monitor renewal failures.

This design can consolidate the public web entry point while retaining per-domain certificates and logs. For a VPS hosting multiple sites, assess total load, tenant isolation and the effect of an outage at the shared entry point before reducing addresses.

Design NAT and private addressing with care

Private IPv4 ranges from RFC1918—10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16—can be used for internal databases, caches and management interfaces. Plan for overlapping ranges when connecting networks. Private addressing or NAT is not an access-control policy: firewall rules, authentication and segmentation are still required.

For a layered VPS or dedicated deployment, consider the following design:

• Assign public IPv4 to the ingress or egress gateways that actually require it, allowing for redundancy and connection capacity.
• Use private IPv4 or suitable IPv6 addresses between internal containers, VMs and services; each node need not have a public IPv4.
• Expose required applications through reverse proxies or load balancers, and provide controlled VPN or bastion access for administration.

This can reduce separate public-address requirements, but gateways become capacity and availability dependencies. Check port requirements, NAT connection limits, external allowlists and failover before consolidating services.

Clean up unused and underutilised IPs

An IP inventory may reveal retired test servers, unused services or old certificate migrations whose addresses remain assigned. Confirm actual usage before classifying an address as unnecessary; lack of recent traffic alone does not prove it can be released.

We recommend a periodic IP audit:

• List assigned IPv4 addresses per server, VLAN or customer account and identify their owners.
• Document purpose, fees, DNS records, NAT/firewall rules, external allowlists and monitoring dependencies.
• Consolidate compatible services, then test access, certificates and failover over the replacement path.
• Remove obsolete dependencies and return genuinely unused addresses through the provider’s process, confirming when billing stops.

This is especially important if you manage many client sites as an agency or via reseller hosting. Our guide on managing multiple websites on shared and reseller hosting covers practical patterns for safe consolidation without confusing DNS or breaking SSL.

Planning IPv4 in Practical Hosting Scenarios

Scenario 1: A new small business website

In this illustrative scenario, a brochure site or simple blog has no requirement for an exclusive public address. A shared-hosting plan or an appropriately sized VPS may serve it through a shared IPv4 entry point, provided that:

• The server supports SNI for HTTPS
• You have valid SSL certificates for your domain
• Email is handled by a provider with good IP reputation or via well‑configured hosting mail

Assess application response time, resource limits, storage performance, backups and availability alongside IP requirements. NVMe storage alone does not determine website performance. The guide to how much CPU, RAM and bandwidth a new website needs helps frame the workload-sizing questions.

Scenario 2: WooCommerce or SaaS with critical email

For an online store or SaaS product, confirmations, invoices and password resets require careful delivery operations. A dedicated sending IPv4 is an option when sustained volume and operating capacity justify managing its reputation. Low or irregular volume may be better suited to a managed shared pool. Neither model guarantees inbox placement, and domain reputation remains relevant alongside IP reputation.

For this hypothetical workload, compare these options:

• A managed shared sending pool for low or irregular transactional volume, including mail sent by app@example.com.
• A dedicated IP or pool for sustained volume with capacity to manage authentication, warm-up, rate limits and monitoring.
• Separate transactional and bulk-marketing streams where justified by volume and operating policy; do not add IPs merely to bypass reputation problems.

The web frontend and APIs may share an entry point when their routing requirements permit it; administrative interfaces still need restricted access. Budget mail-service fees and management work as well as addresses. Investigate compromised accounts, consent and sending behaviour before changing an IP with reputation problems.

Scenario 3: Agency or hosting reseller with many client sites

Agencies and resellers can host multiple client domains on shared addresses when their application and contractual requirements permit it. A separate IPv4 per client is not inherently required to present that client’s TLS certificate with SNI. For this planning scenario, consider:

• Use shared IPv4 with SNI where client sites support it.
• Reserve separate addresses for verified mail, legacy-client, routing or contractual requirements.
• Assess IPv6 support and test dual-stack reachability before enabling it for client sites.

This model keeps your IPv4 footprint tight, especially if you combine it with well‑organised DNS and access management. For DNS best practices in agency setups, see our article on DNS and domain access management for agencies.

Scenario 4: Colocation and custom network designs

In colocation, using your own address space requires provider acceptance, valid rights to use and announce the prefix, and compatible routing arrangements. Check route-origin authorisations (RPKI), relevant IRR records and who maintains them. Leasing provider space is another option where policy and contract permit it. An addressing plan should aim to:

• Use only the public IPv4 interfaces needed for actual connectivity and routing requirements.
• Use private IPv4 or suitable IPv6 for internal server-to-server communication.
• Size ingress/egress devices for workload, redundancy and failover rather than merely minimising address count.

As a hypothetical design, an AI/ML or container cluster could use IPv6 internally and retain IPv4 at necessary edges. This depends on application, orchestration and external-service support. Inventory those dependencies and test gateway capacity and failover before adoption.

What to Confirm in a DCHost Hosting Quote

Address allocation, charges and operational responsibilities

When comparing a DCHost quote or another provider’s offer, confirm these items for the actual product and location:

• Included IPv4 count, justification required for extras and the applicable price.
• Procedures for adding, returning, renumbering or moving addresses, including notice and billing dates.
• Responsibility for PTR changes, abuse reports and blocklist-remediation requests.
• Contract term, renewal pricing and any separately charged networking support.

Record these terms alongside the IP inventory and budget. Confirm availability before deployment, and keep renewal dates and address-return procedures with the service documentation.

IPv6 support for the selected plan and location

Confirm whether IPv6 is available for the chosen service, what prefix and route are provided, whether activation is needed and what fees apply. Then verify the operating system, control panel and application requirements. Plan dual-stack or IPv6-only segments according to tested reachability, not an assumed universal hosting feature.

Adoption rates depend on the measurement source, country, network and date. Use your own audience’s reachability when prioritising rollout. The related article on global IPv6 adoption and infrastructure planning provides context; its headline percentage should not be treated as a current universal traffic share.

Guidance on right‑sizing your infrastructure

IPv4 availability and costs are part of the overall hosting and network budget. When choosing shared hosting, VPS, dedicated servers or colocation, evaluate:

• CPU, RAM and disk needs for the workload
• Expected traffic and bandwidth
• Number and type of IP addresses truly required
• Security, compliance and growth expectations

The guide to choosing between a dedicated server and a VPS provides context for these trade-offs. Compare actual quotes and test the proposed architecture against workload, access and recovery requirements before committing to it.

Summary: Turning IPv4 Scarcity Into a Manageable Constraint

IPv4 has a finite address space, but available market supply, prices and regional allocation paths change. Keep an inventory of every required address, its purpose and its cost. Use SNI, proxies and private networks where they fit the workload, and introduce IPv6 through tested rollout stages. Release IPv4 only after its dependencies have been removed and the provider’s return process is complete.

For a new project or consolidation, share the service inventory and access requirements when requesting a quote. Confirm included addresses, extra-IP charges, IPv6 support and operational responsibilities in writing. Judge the design by total cost, capacity and availability; fewer addresses alone do not establish a better hosting architecture.